这是否违反了《里斯科夫换人原则》？

假设我们有一个Task实体列表和一个ProjectTask子类型。任务可以随时关闭，除非ProjectTasks状态为“已启动”的任务无法关闭。用户界面应确保关闭启动选项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()Task时，如果调用ProjectTask处于启动状态，则有可能失败，而如果它是基本Task，则调用不会失败。但这是业务需求。它应该失败。可以认为这违反了Liskov替代原则吗？

是的，它违反了LSP。里氏替换原则要求是

• 前提条件不能在子类型中得到加强。
• 子条件不能弱化后置条件。
• 超类型的不变量必须保留在子类型中。
• 历史记录约束（“历史记录规则”）。对象只能通过其方法（封装）被视为可修改的。由于子类型可能会引入父类型中不存在的方法，因此，这些方法的引入可能会导致子类型中状态不允许在父类型中发生变化。历史记录约束禁止这样做。

您的示例通过增强调用该Close()方法的前提条件来打破第一个要求。

您可以通过将增强的前提条件带到继承层次结构的顶层来解决此问题：

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

通过规定调用Close()仅在CanClose()返回时的状态下有效，true您使前提适用于Task和，从而ProjectTask解决了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();
    }
}

是。这违反了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需要三方。类型T，子类型S和使用T但被赋予S实例的程序P。

您的问题提供了T（任务）和S（项目任务），但没有提供P。因此，您的问题不完整，并且答案是合格的：如果存在一个P，并且不希望出现异常，那么对于该P，您有一个LSP。违反。如果每个P都期望有异常，那么就没有LSP违规。

但是，您确实违反了SRP。事实上，任务的状态可以改变，而政策在某些国家的某些任务应该不会改变其他国家，是两个完全不同的责任。

• 责任1：代表一项任务。
• 职责2：实施更改任务状态的策略。

这两个职责由于不同的原因而发生变化，因此应该放在不同的类别中。任务应处理作为任务的事实以及与任务相关联的数据。TaskStatePolicy应该处理任务在给定应用程序中从状态过渡到状态的方式。

这可能会也可能不会违反LSP。

说真的 听我说。

如果遵循LSP，则类型对象ProjectTask必须表现为Task预期类型的对象。

代码的问题在于您尚未记录类型对象的Task预期行为。您已经编写了代码，但没有合同。我将为添加合同Task.Close。根据我添加的合同，该代码ProjectTask.Close是否遵循LSP。

给定Task.Close的以下合同，该代码ProjectTask.Close 不遵循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;
     }

给定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;
     }

应该以两种方式记录可能被覆盖的方法：

• “行为”记录了知道收件人对象是Task，但不知道它是直接实例的类的客户端可以依靠的内容。它还告诉子类的设计者哪些覆盖是合理的，哪些覆盖是不合理的。

• “默认行为”记录了客户端，该客户端知道接收者对象是的直接实例Task（即，如果使用该操作，您会得到什么new Task()。），它还告诉子类设计者如果不这样做，将继承哪些行为覆盖该方法。

现在，以下关系应该成立：

• 如果S是T的子类型，则S的已记录行为应完善T的已记录行为。
• 如果S是T的子类型（或等于T），则S的代码的行为应细化T的已记录行为。
• 如果S是T的子类型（或等于T），则S的默认行为应细化T的已记录行为。
• 类的代码的实际行为应改进其记录的默认行为。

这并不违反《里斯科夫换人原则》。

里斯科夫替代原则说：

令q（x）是关于类型T的对象x的可证明性质。令S为T的子类型。如果存在类型S的对象y，则q是不可证明的，则类型S违反了Liskov替换原理。

为什么要实现子类型而不违反Liskov替换原理，原因很简单：Task::Close()实际操作无法证明。当然，ProjectTask::Close()在时Status == Status.Started会引发异常，但Status = Status.Closed在中可能会引发异常Task::Close()。

是的，这是违反规定。

我建议您将层次结构倒退。如果不是每个Task都可关闭，close()则不属于Task。也许您想要一个CloseableTask所有非人ProjectTasks都能实现的接口。

除了是LSP问题外，似乎它正在使用异常来控制程序流（我必须假设您在某个地方捕获了这个微不足道的异常并执行了一些自定义流，而不是使应用崩溃。）

看起来这是为TaskState实现State模式并让状态对象管理有效转换的好地方。

在这里，我缺少与LSP和按合同设计有关的重要内容-在前提条件中，呼叫者的责任是确保满足前提条件。在DbC理论中，被调用的代码不应验证先决条件。合同应指定何时可以关闭任务（例如CanClose返回True），然后调用代码应确保在调用Close（）之前满足前提条件。

是的，这明显违反了LSP。

有人在这里争论说，在基类中明确声明子类可以引发异常将使这种情况可以接受，但我认为这不是真的。不管您在基类中记录了什么文档或将代码移至哪个抽象级别，子条件中的前提条件都仍然得到加强，因为您向其中添加了“无法关闭启动的项目任务”部分。这不是您可以通过变通办法解决的事情，您需要一个不违反LSP的其他模型（或者我们需要放宽“无法加强前提条件”的约束）。

如果要避免在这种情况下违反LSP，可以尝试使用装饰器模式。这可能有效，我不知道。