Est-ce une violation du principe de substitution de Liskov?

Supposons que nous ayons une liste d'entités de tâche et un ProjectTasksous-type. Les tâches peuvent être fermées à tout moment, à l'exception des tâches ProjectTasksqui ne peuvent pas être fermées une fois qu'elles ont le statut Lancé. L’interface utilisateur doit s’assurer que l’option de fermeture d’un espace ouvert ProjectTaskn’est jamais disponible, mais certaines garanties sont présentes dans le domaine:

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

Désormais, lors de l'appel Close()d'une tâche, il est possible que l'appel échoue s'il s'agit d'un ProjectTaskétat démarré, alors que ce ne serait pas le cas s'il s'agissait d'une tâche de base. Mais ce sont les exigences commerciales. Cela devrait échouer. Cela peut-il être considéré comme une violation du principe de substitution de Liskov ?

Oui, c'est une violation du LSP. Le principe de substitution de Liskov exige que

• Les conditions préalables ne peuvent pas être renforcées dans un sous-type.
• Les post-conditions ne peuvent pas être affaiblies dans un sous-type.
• Les invariants du supertype doivent être conservés dans un sous-type.
• Contrainte d'historique (la "règle d'historique"). Les objets sont considérés comme modifiables uniquement par leurs méthodes (encapsulation). Comme les sous-types peuvent introduire des méthodes qui ne sont pas présentes dans le supertype, leur introduction peut permettre des changements d'état dans le sous-type qui ne sont pas autorisés dans le supertype. La contrainte de l'histoire l'interdit.

Votre exemple casse la première condition en renforçant une condition préalable à l'appel de la Close()méthode.

Vous pouvez résoudre ce problème en amenant la condition préalable renforcée au niveau supérieur de la hiérarchie d'héritage:

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

En stipulant qu'un appel de Close()n'est valide que dans l'état où les CanClose()retours truevous font que la condition préalable s'applique à la Taskainsi qu'à la ProjectTask, réparant la violation 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();
    }
}

Oui. Cela viole le LSP.

Ma suggestion est d'ajouter une CanCloseméthode / propriété à la tâche de base afin que toute tâche puisse indiquer si une tâche dans cet état peut être fermée. Cela peut aussi fournir une raison. Et retirez le virtuel de Close.

Basé sur mon commentaire:

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

Le principe de substitution de Liskov stipule qu'une classe de base doit pouvoir être remplacée par l'une de ses sous-classes sans modifier les propriétés souhaitables du programme. Etant donné que ne ProjectTasksoulève une exception à la fermeture, un programme devrait être modifié pour tenir compte de cela, il devrait ProjectTaskêtre utilisé à la place de Task. C'est donc une violation.

Mais si vous modifiez en Taskindiquant dans sa signature qu'il peut déclencher une exception à la fermeture, vous ne violeriez pas le principe.

Une violation de LSP nécessite trois parties. Le type T, le sous-type S et le programme P qui utilise T mais se voit attribuer une instance de S.

Votre question a fourni T (tâche) et S (tâche de projet), mais pas P. Donc, votre question est incomplète et la réponse est qualifiée: s'il existe un P qui ne s'attend pas à une exception, alors, pour ce P, vous avez un LSP violation. Si chaque P s'attend à une exception, il n'y a pas de violation LSP.

Cependant, vous n'avez une SRP violation. Le fait que l'état d'une tâche puisse être modifié et la politique selon laquelle certaines tâches dans certains États ne doivent pas être modifiées pour devenir d'autres États sont deux responsabilités très différentes.

• Responsabilité 1: Représenter une tâche.
• Responsabilité 2: Mettre en œuvre les stratégies qui modifient l'état des tâches.

Ces deux responsabilités changent pour des raisons différentes et doivent donc être réparties dans des classes distinctes. Les tâches doivent gérer le fait d'être une tâche et les données associées à une tâche. TaskStatePolicy doit gérer la manière dont les tâches passent d'un état à l'autre dans une application donnée.

Cela peut ou peut ne pas être une violation du LSP.

Sérieusement. Écoutez-moi.

Si vous suivez le LSP, les objets de type ProjectTaskdoivent se comporter comme des objets de type Taskdoivent se comporter.

Le problème avec votre code est que vous n'avez pas documenté la manière dont les objets de type Taskdoivent se comporter. Vous avez écrit du code, mais pas de contrat. Je vais ajouter un contrat pour Task.Close. Selon le contrat que j'ajoute, le code ProjectTask.Closecorrespondant ou non au LSP.

Compte tenu du contrat suivant pour Task.Close, le code de ProjectTask.Close ne suit pas le 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;
     }

Étant donné le contrat suivant pour Task.Close, le code pour ProjectTask.Close ne suivre le 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;
     }

Les méthodes pouvant être remplacées doivent être documentées de deux manières:

• Le "Comportement" décrit ce sur quoi un client peut compter, sachant que l’objet destinataire est un Task, mais ne sait pas de quelle classe il est une instance directe. Il indique également aux concepteurs des sous-classes quelles substitutions sont raisonnables et lesquelles ne le sont pas.

• Le "comportement par défaut" décrit ce à quoi un client peut se fier et sait que l'objet destinataire est une instance directe de Task(ce que vous obtenez si vous l'utilisez new Task(). Il indique également aux concepteurs des sous-classes quel comportement sera hérité s'ils ne le font pas. remplacer la méthode.

Maintenant, les relations suivantes devraient tenir:

• Si S est un sous-type de T, le comportement documenté de S doit préciser le comportement documenté de T.
• Si S est un sous-type de T (ou est égal à) T, le comportement du code de S doit affiner le comportement documenté de T.
• Si S est un sous-type de T (ou est égal à) T, le comportement par défaut de S devrait préciser le comportement documenté de T.
• Le comportement réel du code pour une classe doit affiner son comportement par défaut documenté.

Ce n'est pas une violation du principe de substitution de Liskov.

Le principe de substitution de Liskov dit:

Que q (x) soit une propriété démontrable sur les objets x de type T . Soit S être un sous - type de T . Le type S viole le principe de substitution de Liskov s'il existe un objet y de type S , tel que q (y) n'est pas prouvable.

La raison pour laquelle votre implémentation du sous-type n'est pas une violation du principe de substitution de Liskov est très simple: rien ne peut être prouvé sur ce qui Task::Close()se passe réellement. Bien sûr, ProjectTask::Close()jette une exception quand Status == Status.Started, mais pourrait le faire Status = Status.Closeddans Task::Close().

Oui, c'est une violation.

Je suggérerais que vous ayez votre hiérarchie à l'envers. Si tout Taskn'est pas fermable, alors close()n'appartient pas à Task. Peut-être que vous voulez une interface, CloseableTaskque tous les non- ProjectTaskspeuvent implémenter.

En plus d'être un problème lié au fournisseur de services linguistiques, il semble qu'il utilise des exceptions pour contrôler le flux de programmes (je dois supposer que vous capturez cette exception triviale quelque part et effectuez un flux personnalisé plutôt que de le laisser bloquer votre application).

Il semble que ce soit un bon endroit pour implémenter le modèle d'état pour TaskState et laisser les objets d'état gérer les transitions valides.

Il me manque ici un élément important lié aux prestataires de services linguistiques et à la conception par contrat - dans les conditions préalables, c’est à l’appelant qui a la responsabilité de s’assurer que les conditions préalables sont remplies. Le code appelé, en théorie DbC, ne devrait pas vérifier la condition préalable. Le contrat doit spécifier quand une tâche peut être fermée (par exemple, CanClose renvoie True), puis le code appelant doit garantir que la condition préalable est remplie avant d'appeler Close ().

Oui, c'est une violation claire de LSP.

Certaines personnes soutiennent ici que rendre explicite dans la classe de base que les sous-classes peuvent renvoyer des exceptions rendrait cela acceptable, mais je ne pense pas que ce soit le cas. Peu importe ce que vous documentez dans la classe de base ou le niveau d'abstraction vers lequel vous déplacez le code, les conditions préalables seront toujours renforcées dans la sous-classe, car vous y ajoutez la partie "Impossible de fermer une tâche de projet commencée". Ce problème ne peut pas être résolu par une solution de contournement, il vous faut un modèle différent, qui ne viole pas le LSP (ou il faut relâcher la contrainte "les conditions préalables ne peuvent pas être renforcées").

Vous pouvez essayer le motif de décorateur si vous souhaitez éviter la violation LSP dans ce cas. Cela pourrait fonctionner, je ne sais pas.