如何避免违反Liskov替代原则（LSP）？

Question

我的情况与Code Complete中Steve
McConnell
提到的情况非常相似。我唯一的问题是基于车辆，而三轮车恰好是根据法律，属于汽车。到目前为止，汽车只有四个轮子。无论如何，我的域都不必要地复杂，因此很容易遵循下面的cats示例。

对重写例程并且在派生例程中不执行任何操作的类要保持怀疑。这通常表明基类的设计存在错误。例如，假设您有一个Cat类和一个例程Scratch（），并假定您最终发现某些猫被剥皮并且无法抓挠。您可能很想创建一个从Cat派生的名为ScratchlessCat的类，并重写Scratch（）例程以执行任何操作。这种方法存在几个问题：

通过更改其接口的语义，它违反了Cat类中提供的抽象（接口协定）。

当您将其扩展到其他派生类时，这种方法很快就会失去控制。如果您发现没有尾巴的猫会怎样？还是不抓老鼠的猫？还是不喝牛奶的猫？最终，您将得到派生类，例如ScratchlessTaillessMicelessMilklessCat。

随着时间的流逝，这种方法会导致代码难以维护，因为祖先类的接口和行为对后代的行为几乎没有暗示。

解决此问题的位置不在基类中，而在原始Cat类中。创建一个Claws类，并将其包含在Cats类中。根本问题是所有猫都抓挠猫的假设，因此，应从源头上解决该问题，而不仅仅是在目标位置进行包扎。

根据他以上伟大著作的文字。跟随不好

父类不必是抽象的

public abstract class Cat {
   public void scratch() {
      System.out.println("I can scratch");
   }
}

派生类

public class ScratchlessCat extends Cat {
   @Override
   public void scratch() {
      // do nothing
   }
}

现在，他建议创建另一个类Claws，但我不知道如何使用该类来避免需要ScratchlessCat#Scratch。

Answer 1

您仍然会有一个scratch()方法，但不会被派生类覆盖：

public class Cat {
  Claw claw_;
  public Cat(Claw claw) {claw = claw_;}
  public final void scratch() {
    if (claw_ != null) {
      claw_.scratch(this);
    }
  }
}

这使您可以将抓取逻辑委托给所包含的Claw对象（如果存在）（如果没有爪，则不进行抓取）。从cat派生的类在如何刮擦方面没有发言权，因此无需根据能力创建影子层次结构。

同样，由于派生类无法更改方法的实现，因此它们不会破坏scratch()基类接口中方法的预期语义的问题。

如果将其极端化，您可能会发现您有很多类，而没有很多派生-大多数逻辑都委托给组合对象，而不委托给派生类。