我没有完全理解他的榜样。

但是，重要的是要了解OOP对于可以自然建模的事物非常有效，而对其他事物（例如，横切关注点或方面）则非常无效。这是OOP的缺点之一。另一个是，由于动态调度，它通常会导致一些运行时成本。

另外，很容易滥用OOP进行不合理的抽象。让火箭从身体继承下来就是一个例子。我的经验是，当其他行为（例如聚合）更合适时，新手开发人员要么不信任并且不使用继承，要么过于渴望并错误地使用了继承。随着时间的流逝，对该机制的经验和了解会不断提高。

我不确定他所说的“
OOP模式没有严格实现继承规则”，因为OOP不是模式。一个潜在的问题是，一个人可以写一个违反Liskov替换原则的子类型，因此覆盖方法不会像覆盖方法那样“至少”表现出来。没有办法自动检查这一点，因此有可能编写违反OOP原则的代码。

关于您的最后一个问题“我们可以在理想的面向对象设计中拔掉类层次结构吗？”，我不确定您在这里的意思。如果您要在运行时更改层次结构，并使其在执行过程中不再存在子类型关系，则可以。某些语言（例如Smalltalk）是可能的。有人会说这是“更多的面向对象”。在smalltalk中，类型支持的“方法”是在方法调用时根据当前层次结构和每个类的当前内容确定的。虽然我喜欢smalltalk，但是这并不是我不为所动的功能，因为我更喜欢编译时检查，而运行时的意外次数更少。