Question

我正在阅读史蒂夫的“5个必不可少的电话屏幕问题”，同时准备接受下周的采访，我遇到了这段摘录：

例如，您可能会找到一个决定车辆类的候选人应该是ParkingGarage的子类，因为车库包含汽车。这只是被破坏了，并且它在任何合理数量的情况下都是不可修复的培训时间。

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

Answer 1

添加到Evan的回答：

当涉及到继承时，尊重＆＃34;是＆＃34; （或＆＃34;是一种＆＃34;）关系不是整个故事。

一个好的设计也将考虑LSP（Liskov替代原则）。该原则指出，如果B是A的子类型，那么A可以用B替换而没有任何令人惊讶的效果。例如，任何与Vehicle一起使用的代码也适用于Car。

显示破坏这一原则是多么容易的经典例子是Square-Rectangle示例。

乍一看，使Square继承自Rectangle似乎相当明显。一个正方形＆＃34;是一种＆＃34;长方形。它是一个矩形，其宽度和高度始终是相同的值。为了保留这个属性，你可能会设计你的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.但是，如果用Square替换，它将打印20而不是导致意外行为 - 并打破Liskov替代原则。所以我们看到矩形不能总是用正方形替换。

LSP是五个SOLID原则之一 - 我建议阅读更多有关其他4的原则。

如果您正在寻找一本好的OO书，我必须说Head First Design Patterns是一本书，这是我读过的最好的书。它与java略有关系，但只是略有不同，它们将它用于代码示例而不是其他任何内容。它应该是与语言无关的，无论你的编程背景如何，你都可以阅读它。

Answer 2

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

Car是Vehicle。

Vehicle <{1}}。

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

OO设计面试

2 个答案: