Isso é uma violação do princípio da substituição de Liskov?

Digamos que temos uma lista de entidades de tarefas e um ProjectTasksubtipo. As tarefas podem ser fechadas a qualquer momento, exceto as ProjectTasksque não podem ser fechadas uma vez que tenham o status Iniciado. A interface do usuário deve garantir que a opção de fechar uma inicialização ProjectTasknunca esteja disponível, mas algumas salvaguardas estão presentes no domínio:

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();
     }
}

Agora, ao chamar Close()uma tarefa, há uma chance de a chamada falhar se for ProjectTaskcom o status iniciado, quando não seria se fosse uma tarefa base. Mas esses são os requisitos de negócios. Deveria falhar. Isso pode ser considerado uma violação do princípio da substituição de Liskov ?

Sim, é uma violação do LSP. O princípio da substituição de Liskov exige que

• As pré-condições não podem ser reforçadas em um subtipo.
• As pós-condições não podem ser enfraquecidas em um subtipo.
• Invariantes do supertipo devem ser preservados em um subtipo.
• Restrição do histórico (a "regra do histórico"). Os objetos são considerados modificáveis ​​apenas por meio de seus métodos (encapsulamento). Como os subtipos podem introduzir métodos que não estão presentes no supertipo, a introdução desses métodos pode permitir alterações de estado no subtipo que não são permitidas no supertipo. A restrição de história proíbe isso.

Seu exemplo quebra o primeiro requisito, fortalecendo uma pré-condição para chamar o Close()método.

Você pode corrigi-lo, trazendo a pré-condição reforçada para o nível superior da hierarquia de herança:

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

Ao estipular que uma chamada de Close()é válida apenas no estado quando CanClose()retorna, truevocê aplica a pré-condição à Task, assim como à ProjectTask, corrigindo a violação do 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();
    }
}

Sim. Isso viola o LSP.

Minha sugestão é adicionar CanClosemétodo / propriedade à tarefa base, para que qualquer tarefa possa dizer se a tarefa nesse estado pode ser fechada. Também pode fornecer o motivo. E remova o virtual de Close.

Com base no meu comentário:

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);
    }
}

O princípio de substituição de Liskov afirma que uma classe base deve ser substituível por qualquer uma de suas subclasses sem alterar nenhuma das propriedades desejáveis ​​do programa. Como somente ProjectTaskgera uma exceção quando fechado, um programa teria que ser alterado para se adaptar a isso, deve ProjectTaskser usado em substituição de Task. Então é uma violação.

Mas se você modificar Taskafirmando em sua assinatura que ela pode gerar uma exceção quando fechada, não estaria violando o princípio.

Uma violação do LSP requer três partes. O tipo T, o subtipo S e o programa P que usa T, mas recebem uma instância de S.

Sua pergunta forneceu T (Task) e S (ProjectTask), mas não P. Portanto, sua pergunta está incompleta e a resposta é qualificada: Se existe um P que não espera uma exceção, então, para esse P, você tem um LSP violação. Se todo P espera uma exceção, não há violação do LSP.

No entanto, você fazer ter um SRP violação. O fato de que o estado de uma tarefa pode ser alterado e a política de que determinadas tarefas em certos estados não devem ser alteradas para outros estados são duas responsabilidades muito diferentes.

• Responsabilidade 1: Representar uma tarefa.
• Responsabilidade 2: implemente as políticas que alteram o estado das tarefas.

Essas duas responsabilidades mudam por razões diferentes e, portanto, devem estar em classes separadas. As tarefas devem lidar com o fato de serem uma tarefa e os dados associados a uma tarefa. TaskStatePolicy deve lidar com a maneira como as tarefas passam de estado para estado em um determinado aplicativo.

Isso pode ou não ser uma violação do LSP.

A sério. Me ouça.

Se você seguir o LSP, os objetos do tipo ProjectTaskdeverão se comportar como Taskse espera que os objetos do tipo se comportem.

O problema com o seu código é que você não documentou como os objetos do tipo Taskdevem se comportar. Você escreveu código, mas não possui contratos. Vou adicionar um contrato para Task.Close. Dependendo do contrato que eu adiciono, o código para ProjectTask.Closesegue ou não o LSP.

Dado o seguinte contrato para o Task.Close, o código para ProjectTask.Close não segue o 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 o seguinte contrato para Task.Close, o código para ProjectTask.Close não seguir o 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;
     }

Os métodos que podem ser substituídos devem ser documentados de duas maneiras:

• O "Comportamento" documenta o que pode ser invocado por um cliente que sabe que o objeto destinatário é um Task, mas não sabe de que classe é uma instância direta. Também informa aos projetistas das subclasses quais substituições são razoáveis ​​e quais não são razoáveis.

• O "comportamento padrão" documenta o que pode ser invocado por um cliente que sabe que o objeto destinatário é uma instância direta Task(ou seja, o que você obtém se usar new Task(). Também informa aos designers das subclasses que comportamento será herdado se não o fizerem) substituir o método

Agora, as seguintes relações devem ser mantidas:

• Se S é um subtipo de T, o comportamento documentado de S deve refinar o comportamento documentado de T.
• Se S é um subtipo de (ou igual a) T, o comportamento do código de S deve refinar o comportamento documentado de T.
• Se S é um subtipo de (ou igual a) T, o comportamento padrão de S deve refinar o comportamento documentado de T.
• O comportamento real do código para uma classe deve refinar seu comportamento padrão documentado.

Não é uma violação do princípio de substituição de Liskov.

O Princípio da Substituição de Liskov diz:

Vamos q (x) ser uma propriedade demonstrável sobre objetos x de tipo T . Deixe- S ser um subtipo de T . O tipo S viola o princípio de substituição de Liskov se um objeto y do tipo S existe, de forma que q (y) não é possível.

O motivo pelo qual sua implementação do subtipo não é uma violação do Princípio de Substituição de Liskov é bastante simples: nada pode ser provado sobre o que Task::Close()realmente faz. Claro, ProjectTask::Close()lança uma exceção quando Status == Status.Started, mas pode Status = Status.Closedentrar Task::Close().

Sim, é uma violação.

Eu sugiro que você tenha sua hierarquia ao contrário. Se nem tudo Taské possível fechar, então close()não pertence Task. Talvez você queira uma interface CloseableTaskque todos os que não ProjectTaskspodem implementar.

Além de ser um problema de LSP, parece que ele está usando exceções para controlar o fluxo do programa (devo presumir que você capturou essa exceção trivial em algum lugar e fez algum fluxo personalizado em vez de deixar o aplicativo travar).

Parece que este é um bom lugar para implementar o padrão State para TaskState e permitir que os objetos state gerenciem as transições válidas.

Falto aqui uma coisa importante relacionada ao LSP e ao Design by Contract - nas pré-condições, é o chamador cuja responsabilidade é garantir que as pré-condições sejam atendidas. O código chamado, na teoria DbC, não deve verificar a pré-condição. O contrato deve especificar quando uma tarefa pode ser fechada (por exemplo, CanClose retorna True) e, em seguida, o código de chamada deve garantir que a pré-condição seja atendida antes de chamar Close ().

Sim, é uma clara violação do LSP.

Algumas pessoas argumentam aqui que tornar explícito na classe base que as subclasses podem lançar exceções tornaria isso aceitável, mas não acho que isso seja verdade. Não importa o que você documenta na classe base ou para qual nível de abstração você move o código, as pré-condições ainda serão reforçadas na subclasse, porque você adiciona a parte "Não é possível fechar uma tarefa iniciada do projeto". Isso não é algo que você pode resolver com uma solução alternativa, você precisa de um modelo diferente, que não viole o LSP (ou precisamos relaxar na restrição "pré-condições não podem ser fortalecidas").

Você pode experimentar o padrão do decorador se quiser evitar a violação do LSP nesse caso. Pode funcionar, eu não sei.