これは、リスコフ代替原則の違反ですか？

TaskエンティティのリストとProjectTaskサブタイプがあるとします。タスクはいつでも閉じることができますが、タスクのProjectTasksステータスが[開始済み]になると閉じることができません。UIは、開始済みを閉じるオプションがProjectTask使用できないことを確認する必要がありますが、ドメインにはいくつかの保護手段があります。

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

これClose()で、タスクを呼び出すときに、開始タスクのProjectTask状態の場合は呼び出しが失敗する可能性がありますが、ベースのタスクの場合は失敗しません。しかし、これはビジネス要件です。失敗するはずです。これは、リスコフ代替原理の違反とみなすことができますか？

はい、それはLSPの違反です。リスコフの代替原則では、

• サブタイプでは前提条件を強化できません。
• サブタイプでは事後条件を弱めることはできません。
• スーパータイプの不変式は、サブタイプに保存する必要があります。
• 履歴制約（「履歴ルール」）。オブジェクトは、メソッド（カプセル化）によってのみ変更可能と見なされます。サブタイプはスーパータイプには存在しないメソッドを導入する可能性があるため、これらのメソッドの導入により、スーパータイプでは許可されないサブタイプの状態変更が可能になる場合があります。これは履歴制約により禁止されています。

この例では、Close()メソッドを呼び出すための前提条件を強化することにより、最初の要件を破ります。

強化された前提条件を継承階層の最上位に持ってくることで修正できます：

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

の呼び出しが返さClose()れるときの状態でのみ有効であることを規定することにより、前提条件をに加えてに適用し、LSP違反を修正します。CanClose()trueTaskProjectTask

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

はい。これはLSPに違反します。

私の提案は、CanCloseメソッド/プロパティをベースタスクに追加することです。これにより、どのタスクでも、この状態のタスクを閉じることができるかどうかを判断できます。理由も提供できます。から仮想を削除しますClose。

私のコメントに基づいて：

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

Liskovの置換原理では、プログラムの望ましいプロパティを変更せずに、基本クラスをそのサブクラスのいずれかと置き換えることができると規定されています。ProjectTask閉じたときにのみ例外が発生するため、プログラムはそのために変更する必要ProjectTaskがあり、の代わりに使用する必要がありTaskます。違反です。

しかし、閉じたときに例外が発生Taskする可能性があるという署名の記述を変更する場合、原則に違反することはありません。

LSP違反には3つの当事者が必要です。タイプT、サブタイプS、およびTを使用しているがSのインスタンスが与えられているプログラムP

あなたの質問はT（タスク）とS（プロジェクトタスク）を提供しましたが、Pは提供しませんでした。したがって、あなたの質問は不完全であり、答えは限定されます。違反。すべてのPが例外を予期している場合、LSP違反はありません。

しかし、あなたが行う必要がありSRP違反を。タスクの状態を変更できるという事実と、特定の状態の特定のタスクを他の状態に変更してはならないというポリシーは、2つの非常に異なる責任です。

• 責任1：タスクを表します。
• 責任2：タスクの状態を変更するポリシーを実装します。

これらの2つの責任はさまざまな理由で変化するため、別々のクラスに分類する必要があります。タスクは、タスクであるという事実と、タスクに関連付けられたデータを処理する必要があります。TaskStatePolicyは、特定のアプリケーションでタスクが状態から状態に移行する方法を処理する必要があります。

これは、LSPの違反である場合とそうでない場合があります。

真剣に。聞いてください。

LSPに従う場合、タイプのProjectTaskオブジェクトは、タイプのオブジェクトがTask動作することが期待されるように動作する必要があります。

コードの問題は、タイプのオブジェクトがどのようTaskに動作するかを文書化していないことです。コードを記述しましたが、契約はありません。の契約を追加しますTask.Close。私が追加した契約に応じて、ProjectTask.CloseLSPに従うかどうかに従わないコードがあります。

Task.Closeの次のコントラクトが与えられた場合、コードはLSPに従いProjectTask.Close ません。

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

Task.Close、のコードのために、次の契約が与えられProjectTask.Close ない 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;
     }

オーバーライドされる可能性のあるメソッドは、2つの方法で文書化する必要があります。

• 「振る舞い」は、受信者オブジェクトがであるTaskことを知っているが、それが直接のインスタンスであるクラスを知らないクライアントが信頼できるものを文書化します。また、サブクラスの設計者に、どのオーバーライドが妥当であり、どれが妥当でないかを伝えます。

• 「デフォルトの振る舞い」は、受信者オブジェクトが直接のインスタンスであることを知っているクライアントが信頼できるものを文書化しますTask（つまり、使用すると何を取得しますかnew Task()。メソッドをオーバーライドします。

これで、次の関係が成り立つはずです。

• SがTのサブタイプである場合、Sの文書化された動作は、Tの文書化された動作を改良する必要があります。
• SがTのサブタイプ（またはそれに等しい）である場合、Sのコードの動作は、文書化されたTの動作を改善する必要があります。
• SがTのサブタイプ（またはそれに等しい）である場合、Sのデフォルトの動作は、文書化されたTの動作を改善する必要があります。
• クラスのコードの実際の動作は、文書化されたデフォルトの動作を改良する必要があります。

これは、リスコフ代替原則の違反ではありません。

Liskov Substitution Principleによれば：

ましょうQ（x）はオブジェクトに関する証明可能性であるX型のT。してみましょうSはのサブタイプであることT。タイプSは、オブジェクト場合リスコフの置換原則に違反するY型のSが存在するように、Q（y）が証明可能ではありません。

サブタイプの実装がLiskov Substitution Principleに違反しない理由は非常に単純ですTask::Close()。実際に何が行われるかについては何も証明できません。確かに、ProjectTask::Close()ときに例外がスローされますStatus == Status.Startedが、そうかもしれませんStatus = Status.ClosedでTask::Close()。

はい、違反です。

階層を逆にすることをお勧めします。すべてTaskがクローズ可能でない場合、close()はに属しませんTask。おそらくCloseableTask、すべてProjectTasksが実装できないインターフェースが必要でしょう。

LSPの問題であることに加えて、例外を使用してプログラムフローを制御しているようです（この些細な例外をどこかでキャッチし、アプリをクラッシュさせるのではなく、カスタムフローを実行することを想定する必要があります）。

TaskStateのStateパターンを実装し、状態オブジェクトに有効な遷移を管理させるのに適した場所のようです。

ここでは、LSPとDesign by Contractに関連する重要なことを見逃しています-前提条件では、前提条件が満たされていることを確認するのは呼び出し側です。DbC理論では、呼び出されたコードは前提条件を検証すべきではありません。コントラクトは、タスクを閉じることができるタイミングを指定する必要があり（CanCloseがTrueを返すなど）、呼び出しコードは、Close（）を呼び出す前に前提条件が満たされていることを確認する必要があります。

はい、それはLSPの明らかな違反です。

ここで、サブクラスが例外をスローできることを基本クラスで明示的にすることでこれが受け入れられると主張する人もいますが、それは真実ではないと思います。基本クラスで文書化するもの、またはコードを移動する抽象化レベルに関係なく、サブプロジェクトでは「開始済みプロジェクトタスクを閉じることができません」部分を追加するため、前提条件は引き続き強化されます。これは回避策で解決できるものではありません。LSPに違反しない別のモデルが必要です（または「前提条件を強化できない」制約を緩める必要があります）。

この場合、LSP違反を回避したい場合は、デコレータパターンを試すことができます。うまくいくかもしれませんが、わかりません。