¿Es esto una violación del Principio de sustitución de Liskov?

Digamos que tenemos una lista de entidades de tareas y un ProjectTasksubtipo. Las tareas se pueden cerrar en cualquier momento, excepto ProjectTasksque no se pueden cerrar una vez que tienen el estado de Iniciado. La interfaz de usuario debe garantizar que la opción de cerrar un inicio ProjectTasknunca esté disponible, pero existen algunas salvaguardas en el dominio:

public class Task
{
     public Status Status { get; set; }

     public virtual void Close()
     {
         Status = Status.Closed;
     }
}

public class ProjectTask : Task
{
     public override void Close()
     {
          if (Status == Status.Started) 
              throw new Exception("Cannot close a started Project Task");

          base.Close();
     }
}

Ahora, cuando se llama Close()a una Tarea, existe la posibilidad de que la llamada falle si es ProjectTaskcon el estado iniciado, cuando no lo sería si fuera una Tarea base. Pero estos son los requisitos comerciales. Debería fallar. ¿Se puede considerar esto como una violación del principio de sustitución de Liskov ?

Sí, es una violación del LSP. El principio de sustitución de Liskov requiere que

• Las condiciones previas no pueden fortalecerse en un subtipo.
• Las condiciones posteriores no pueden debilitarse en un subtipo.
• Las invariantes del supertipo deben conservarse en un subtipo.
• Restricción del historial (la "regla del historial"). Los objetos se consideran modificables solo a través de sus métodos (encapsulación). Dado que los subtipos pueden introducir métodos que no están presentes en el supertipo, la introducción de estos métodos puede permitir cambios de estado en el subtipo que no están permitidos en el supertipo. La restricción de la historia lo prohíbe.

Su ejemplo rompe el primer requisito al fortalecer una condición previa para llamar al Close()método.

Puede solucionarlo llevando la precondición fortalecida al nivel superior de la jerarquía de herencia:

public class Task {
    public Status Status { get; set; }
    public virtual bool CanClose() {
        return true;
    }
    public virtual void Close() {
        Status = Status.Closed;
    }
}

Al estipular que una llamada de Close()es válida solo en el estado en el que se realizan CanClose()devoluciones, trueusted hace que la condición previa se aplique Tasktanto a la ProjectTaskreparación como a la violación del LSP:

public class ProjectTask : Task {
    public override bool CanClose() {
        return Status != Status.Started;
    }
    public override void Close() {
        if (Status == Status.Started) 
            throw new Exception("Cannot close a started Project Task");
        base.Close();
    }
}

Si. Esto viola el LSP.

Mi sugerencia es agregar un CanClosemétodo / propiedad a la tarea base, para que cualquier tarea pueda determinar si la tarea en este estado se puede cerrar. También puede proporcionar una razón por la cual. Y eliminar el virtual de Close.

Basado en mi comentario:

public class Task {
    public Status Status { get; private set; }

    public virtual bool CanClose(out String reason) {
        reason = null;
        return true;
    }
    public void Close() {
        String reason;
        if (!CanClose(out reason))
            throw new Exception(reason);

        Status = Status.Closed;
    }
}

public ProjectTask : Task {
    public override bool CanClose(out String reason) {
        if (Status != Status.Started)
        {
            reason = "Cannot close a started Project Task";
            return false;
        }
        return base.CanClose(out reason);
    }
}

El principio de sustitución de Liskov establece que una clase base debe ser reemplazable por cualquiera de sus subclases sin alterar ninguna de las propiedades deseables del programa. Dado que solo ProjectTaskplantea una excepción cuando se cierra, un programa tendría que cambiarse para adaptarse a eso, debe ProjectTaskutilizarse en sustitución de Task. Entonces es una violación.

Pero si modifica Taskindicando en su firma que puede generar una excepción cuando se cierra, entonces no estaría violando el principio.

Una violación de LSP requiere tres partes. El Tipo T, el Subtipo S y el programa P que usa T pero recibe una instancia de S.

Su pregunta ha proporcionado T (Tarea) y S (ProjectTask), pero no P. Por lo tanto, su pregunta está incompleta y la respuesta está calificada: si existe una P que no espera una excepción, entonces, para esa P, tiene un LSP violación. Si cada P espera una excepción, entonces no hay violación de LSP.

Sin embargo, hacer una SRP violación. El hecho de que el estado de una tarea se puede cambiar, y la política de que ciertas tareas en ciertos estados deberían no ser cambiados a otros estados, son dos responsabilidades muy diferentes.

• Responsabilidad 1: Representar una tarea.
• Responsabilidad 2: Implementar las políticas que cambian el estado de las tareas.

Estas dos responsabilidades cambian por diferentes razones y, por lo tanto, deben estar en clases separadas. Las tareas deben manejar el hecho de ser una tarea y los datos asociados con una tarea. TaskStatePolicy debe manejar la forma en que las tareas pasan de un estado a otro en una aplicación determinada.

Esto puede o no ser una violación del LSP.

Seriamente. Escúchame.

Si sigue el LSP, los objetos de tipo ProjectTaskdeben comportarse como Taskse espera que se comporten los objetos de tipo .

El problema con su código es que no ha documentado cómo Taskse espera que se comporten los objetos de tipo . Tiene un código escrito, pero no tiene contratos. Agregaré un contrato para Task.Close. Dependiendo del contrato que agregue, el código para ProjectTask.Closeo no sigue el LSP.

Dado el siguiente contrato para Task.Close, el código para ProjectTask.Close no sigue el LSP:

     // Behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Dado el siguiente contrato para Task.Close, el código para ProjectTask.Close no seguir el camino LSP:

     // Behaviour: Moves the task to the closed status if possible.
     // If this is not possible, this method throws an Exception
     // and leaves the status unchanged.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Los métodos que pueden anularse deben documentarse de dos maneras:

• El "Comportamiento" documenta en qué puede confiar un cliente que sabe que el objeto receptor es un Task, pero no sabe de qué clase es una instancia directa. También le dice a los diseñadores de subclases qué anulaciones son razonables y cuáles no.

• El "comportamiento predeterminado" documenta en qué puede confiar un cliente que sabe que el objeto receptor es una instancia directa de Task(es decir, lo que obtienes si lo usas new Task(). También le dice a los diseñadores de subclases qué comportamiento se heredará si no lo hacen anular el método

Ahora deben tener las siguientes relaciones:

• Si S es un subtipo de T, el comportamiento documentado de S debería refinar el comportamiento documentado de T.
• Si S es un subtipo de (o igual a) T, el comportamiento del código de S debería refinar el comportamiento documentado de T.
• Si S es un subtipo de (o igual a) T, el comportamiento predeterminado de S debería refinar el comportamiento documentado de T.
• El comportamiento real del código para una clase debe refinar su comportamiento predeterminado documentado.

No es una violación del Principio de sustitución de Liskov.

El principio de sustitución de Liskov dice:

Deje que q (x) sea una propiedad comprobable sobre los objetos x de tipo T . Vamos S ser un subtipo de T . El tipo S viola el principio de sustitución de Liskov si existe un objeto y del tipo S , de modo que q (y) no sea demostrable.

La razón por la cual su implementación del subtipo no es una violación del Principio de sustitución de Liskov es bastante simple: no se puede probar nada sobre lo que Task::Close()realmente hace. Por supuesto, ProjectTask::Close()una excepción cuando Status == Status.Started, pero por lo que podría Status = Status.Closeden Task::Close().

Sí, es una violación.

Te sugiero que tengas tu jerarquía al revés. Si no todos Taskse pueden cerrar, entonces close()no pertenece Task. Quizás desee una interfaz CloseableTaskque todos los que no ProjectTaskspuedan implementar.

Además de ser un problema de LSP, parece que está usando excepciones para controlar el flujo del programa (tengo que suponer que capturas esta excepción trivial en algún lugar y haces un flujo personalizado en lugar de dejar que bloquee tu aplicación).

Parece que este es un buen lugar para implementar el patrón de estado para TaskState y dejar que los objetos de estado administren las transiciones válidas.

Aquí me falta algo importante relacionado con el LSP y el diseño por contrato: en las condiciones previas, es la persona que llama cuya responsabilidad es asegurarse de que se cumplan las condiciones previas. El código llamado, en teoría DbC, no debería verificar la condición previa. El contrato debe especificar cuándo se puede cerrar una tarea (por ejemplo, CanClose devuelve True) y luego el código de llamada debe garantizar que se cumpla la condición previa antes de llamar a Close ().

Sí, es una clara violación de LSP.

Algunas personas argumentan aquí que hacer explícito en la clase base que las subclases pueden lanzar excepciones haría esto aceptable, pero no creo que sea cierto. No importa lo que documente en la clase base o el nivel de abstracción al que mueva el código, las condiciones previas aún se fortalecerán en la subclase, porque agrega la parte "No se puede cerrar una tarea de proyecto iniciada". Esto no es algo que pueda resolver con una solución alternativa, necesita un modelo diferente, que no viole el LSP (o tenemos que aflojar la restricción "no se pueden fortalecer las condiciones previas").

Puede probar el patrón de decorador si desea evitar la violación de LSP en este caso. Podría funcionar, no lo sé.