Handelt es sich um eine Verletzung des Liskov-Substitutionsprinzips?

Angenommen, wir haben eine Liste von Aufgabenentitäten und einen ProjectTaskUntertyp. Aufgaben können jederzeit geschlossen werden, es sei denn ProjectTasks, sie können nicht geschlossen werden, sobald sie den Status Gestartet haben. Die Benutzeroberfläche sollte sicherstellen, dass die Option zum Schließen eines gestarteten ProjectTaskObjekts niemals verfügbar ist. In der Domäne sind jedoch einige Sicherheitsvorkehrungen vorhanden:

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

Wenn Sie nun Close()eine Aufgabe aufrufen , besteht die Möglichkeit, dass der Anruf fehlschlägt, wenn er ProjectTaskden Status "Gestartet" hat, während dies bei einer Basisaufgabe nicht der Fall wäre. Dies sind jedoch die geschäftlichen Anforderungen. Es sollte scheitern. Kann dies als Verstoß gegen das Liskov-Substitutionsprinzip angesehen werden ?

Ja, es ist eine Verletzung des LSP. Liskov Substitutionsprinzip erfordert , dass

• Voraussetzungen können in einem Subtyp nicht gestärkt werden.
• Nachbedingungen können in einem Subtyp nicht abgeschwächt werden.
• Invarianten des Supertyps müssen in einem Subtyp erhalten bleiben.
• Verlaufsbeschränkung (die "Verlaufsregel"). Objekte gelten nur durch ihre Methoden als veränderbar (Kapselung). Da Subtypen Methoden einführen können, die im Supertyp nicht vorhanden sind, kann die Einführung dieser Methoden Zustandsänderungen im Subtyp ermöglichen, die im Supertyp nicht zulässig sind. Die Geschichtsbedingung verbietet dies.

Ihr Beispiel unterbricht die erste Anforderung, indem es eine Voraussetzung für den Aufruf der Close()Methode verschärft .

Sie können das Problem beheben, indem Sie die verstärkte Vorbedingung auf die oberste Ebene der Vererbungshierarchie bringen:

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

Indem Sie festlegen, dass ein Aufruf von Close()nur in dem Zustand gültig ist, in dem die CanClose()Rücksendung erfolgt true, stellen Sie sicher , dass die Vorbedingung sowohl für die, Taskals auch für die ProjectTask, gilt.

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

Ja. Dies verletzt LSP.

Mein Vorschlag ist, der Basisaufgabe eine CanCloseMethode / Eigenschaft hinzuzufügen , damit jede Aufgabe erkennen kann, ob die Aufgabe in diesem Zustand geschlossen werden kann. Es kann auch einen Grund dafür liefern. Und entfernen Sie die virtuelle aus Close.

Basierend auf meinem Kommentar:

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

Das Liskov-Substitutionsprinzip besagt, dass eine Basisklasse durch eine seiner Unterklassen ersetzt werden kann, ohne dass die gewünschten Eigenschaften des Programms geändert werden. Da ProjectTaskbeim Schließen nur eine Ausnahme ausgelöst wird, müsste ein Programm geändert werden, um dem Rechnung zu tragen, ProjectTaskdas anstelle von verwendet werden sollte Task. Es ist also eine Verletzung.

Aber wenn Sie ändern Taskin seiner Unterschrift die besagt , dass es möglicherweise eine Ausnahme auslösen , wenn sie geschlossen, dann werden Sie sich nicht gegen den Grundsatz verstoßen.

Eine LSP-Verletzung erfordert drei Parteien. Der Typ T, der Subtyp S und das Programm P, das T verwendet, aber eine Instanz von S erhält.

Ihre Frage enthält T (Aufgabe) und S (Projektaufgabe), nicht jedoch P. Ihre Frage ist also unvollständig und die Antwort ist qualifiziert: Wenn ein P existiert, das keine Ausnahme erwartet, haben Sie für dieses P einen LSP Verletzung. Wenn jedes P eine Ausnahme erwartet, liegt keine LSP-Verletzung vor.

Aber Sie tun einen haben SRP Verletzung. Die Tatsache , dass der Zustand einer Aufgabe geändert werden kann, und die Politik , dass bestimmte Aufgaben in bestimmten Staaten sollen nicht auf andere Staaten, sind zwei sehr unterschiedliche Zuständigkeiten geändert werden.

• Verantwortung 1: Eine Aufgabe darstellen.
• Verantwortung 2: Implementieren Sie die Richtlinien, die den Status von Aufgaben ändern.

Diese beiden Verantwortlichkeiten ändern sich aus unterschiedlichen Gründen und sollten daher in getrennten Klassen sein. Aufgaben sollten die Tatsache behandeln, dass es sich um eine Aufgabe handelt, und die Daten, die mit einer Aufgabe verknüpft sind. TaskStatePolicy sollte den Übergang von Aufgaben von Status zu Status in einer bestimmten Anwendung behandeln.

Dies kann eine Verletzung des LSP sein oder nicht .

Ernsthaft. Lass mich ausreden.

Wenn Sie dem LSP folgen, ProjectTaskmüssen sich Objekte vom Typ Taskso verhalten, wie es von Objekten vom Typ erwartet wird.

Das Problem mit Ihrem Code ist, dass Sie nicht dokumentiert haben, wie sich Objekte des Typs Taskvoraussichtlich verhalten. Sie haben Code geschrieben, aber keine Verträge. Ich werde einen Vertrag für hinzufügen Task.Close. Abhängig vom Vertrag, den ich hinzufüge, ProjectTask.Closefolgt der Code für entweder dem LSP oder nicht.

In Anbetracht des folgenden Vertrags für Task.Close folgt der Code für ProjectTask.Close nicht dem 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;
     }

Angesichts der folgenden Auftrag für Task.Close, den Code für ProjectTask.Close sich die LSP wie folgt vor :

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

Methoden, die möglicherweise überschrieben werden, sollten auf zwei Arten dokumentiert werden:

• Das "Verhalten" dokumentiert, worauf sich ein Client verlassen kann, der das Empfängerobjekt a kennt Task, aber nicht weiß, von welcher Klasse es eine direkte Instanz ist. Außerdem erfahren Designer von Unterklassen, welche Überschreibungen sinnvoll und welche nicht sinnvoll sind.

• Das "Standardverhalten" dokumentiert, worauf sich ein Client verlassen kann, der weiß, dass das Empfängerobjekt eine direkte Instanz von ist Task(dh was Sie erhalten, wenn Sie es verwenden new Task(). Es teilt den Designern von Unterklassen auch mit, welches Verhalten vererbt wird, wenn dies nicht der Fall ist überschreiben Sie die Methode.

Nun sollten folgende Beziehungen gelten:

• Wenn S ein Subtyp von T ist, sollte das dokumentierte Verhalten von S das dokumentierte Verhalten von T verfeinern.
• Wenn S ein Subtyp von (oder gleich) T ist, sollte das Verhalten des S-Codes das dokumentierte Verhalten von T verfeinern.
• Wenn S ein Subtyp von (oder gleich) T ist, sollte das Standardverhalten von S das dokumentierte Verhalten von T verfeinern.
• Das tatsächliche Verhalten des Codes für eine Klasse sollte das dokumentierte Standardverhalten verfeinern.

Es ist keine Verletzung des Liskov-Substitutionsprinzips.

Das Liskov-Substitutionsprinzip besagt:

Lassen Sie q (x) eine Eigenschaft beweisbar über Objekte sein x vom Typ T . Lassen S ein Subtyp von seiner T . Typ S verstößt gegen das Liskov-Substitutionsprinzip, wenn ein Objekt y vom Typ S existiert, so dass q (y) nicht nachweisbar ist.

Der Grund, warum Ihre Implementierung des Subtyps nicht gegen das Liskov-Substitutionsprinzip verstößt, ist ganz einfach: Es kann nicht bewiesen werden, was Task::Close()tatsächlich geschieht. Sicher, ProjectTask::Close()wirft eine Ausnahme , wenn Status == Status.Started, aber so könnte Status = Status.Closedin Task::Close().

Ja, es ist eine Verletzung.

Ich würde vorschlagen, dass Sie Ihre Hierarchie rückwärts haben. Wenn nicht jeder Taskverschließbar ist, dann close()gehört das nicht rein Task. Vielleicht möchten Sie eine Schnittstelle, CloseableTaskdie alle nicht ProjectTasksimplementieren können.

Es scheint nicht nur ein LSP-Problem zu sein, sondern es werden auch Ausnahmen verwendet, um den Programmfluss zu steuern.

Anscheinend ist dies ein guter Ort, um das Statusmuster für TaskState zu implementieren und die Statusobjekte die gültigen Übergänge verwalten zu lassen.

Mir fehlt hier eine wichtige Sache in Bezug auf LSP und Design by Contract - in den Voraussetzungen ist es der Anrufer, der dafür verantwortlich ist, sicherzustellen, dass die Voraussetzungen erfüllt sind. Der aufgerufene Code sollte in der DbC-Theorie die Vorbedingung nicht verifizieren. Der Vertrag sollte angeben, wann eine Aufgabe geschlossen werden kann (z. B. CanClose gibt True zurück), und der aufrufende Code sollte sicherstellen, dass die Vorbedingung erfüllt ist, bevor er Close () aufruft.

Ja, es ist eine eindeutige Verletzung von LSP.

Einige Leute argumentieren hier, dass es akzeptabel wäre, in der Basisklasse explizit zu machen, dass die Unterklassen Ausnahmen auslösen können, aber ich denke nicht, dass das wahr ist. Unabhängig davon, was Sie in der Basisklasse dokumentieren oder auf welche Abstraktionsebene Sie den Code verschieben, werden die Voraussetzungen in der Unterklasse weiter verbessert, da Sie den Teil "Gestartete Projektaufgabe kann nicht geschlossen werden" hinzufügen. Dies können Sie nicht mit einer Problemumgehung lösen. Sie benötigen ein anderes Modell, das nicht gegen LSP verstößt (oder wir müssen die Einschränkung "Voraussetzungen können nicht verschärft werden" lösen).

Sie können das Dekorationsmuster ausprobieren, wenn Sie in diesem Fall eine LSP-Verletzung vermeiden möchten. Es könnte funktionieren, ich weiß es nicht.