OO设计访谈

Question

我当时正在读史蒂夫·叶格的“五个基本的手机屏幕问题”，同时也在为下周即将到来的采访做准备，我遇到了一段节选：

例如，您可能会找到一个候选人，他决定车辆类应该是ParkingGarage的一个子类，因为车库中包含汽车。这是被打破的，而且在任何合理的训练时间内都是无法修复的。

由于对OO设计缺乏经验，我试图理解为什么这是一个失败的假设？

Answer 1

补充埃文的答案：

谈到继承，尊重“是一种”(或“是一种”)关系并不是全部。

一个好的设计也将铭记LSP (Liskov替代原则)。该原理指出，如果B是A的一个子类型，则可以用B代替A，而不会产生任何令人惊讶的效果。例如，与Vehicle一起工作的任何代码也将与Car一起工作。

这个经典的例子展示了打破这个原则是多么的容易，就是方框的例子。

乍一看，让Square继承矩形似乎相当明显。正方形是一种矩形。它是一个矩形，其宽度和高度总是相同的值。为了保留这个属性，您可能会像这样设计Square类：

public class Square : Rectangle
{    
  //SetWidth method inherited from Rectangle
  public override void SetWidth(int width) {
    base.width = width;
    base.height = width;
  }
}

太完美了。但是现在，想象一下下面的代码：

public void SomeMethod(Rectangle rect) {
  rect.SetHeight(10);
  rect.SetWidth(20);
  print(rect.GetHeight());
}

这段代码期望第三行打印10，因为它只是将矩形的高度设置为10。然而，如果用正方形代替，它将打印20，从而导致意外行为--并破坏Liskov替换原则。所以我们看到矩形不能总是用正方形来代替。

LSP是五个坚实的原则之一--我建议阅读更多关于其他4条的内容。

如果你在寻找一本好的OO书，我必须说，“头第一设计模式”( Head First Design Patterns )是一本非常棒的书，是我读过的最好的书。它与java略有关联，但它们只将其用于代码示例，而不用于其他任何东西。它应该是语言不可知论，你可以阅读它，无论你的编程背景。

Answer 2

继承是一种“是一种”关系。

Car是Vehicle。

Vehicle是而不是a ParkingGarage。

ParkingGarage可能包含许多Vehicles，但这是组合，而不是继承