没有继承的OOP重用:这个"真实世界"的实用性如何？

Question

本文介绍了一种有趣的OOP方法:

如果对象作为封装存在,并通过消息进行通信怎么办？如果代码重用与继承无关,但使用组合,委托,甚至老式帮助对象或程序员认为合适的任何技术,该怎么办？本体不会消失,但它与实现分离.

没有继承或依赖于类层次结构的重用的想法是我发现最令人震惊的,但这有多可行？

给出了示例,但我不太清楚如何更改当前代码以适应此方法.

那么这种方法有多可行？或者是否真的不需要更改代码,而是基于场景的方法,即"仅在需要或最佳时使用"？

编辑:哎呀,我忘了链接:这里是链接

Answer 1

我相信你已经听说过"总是喜欢构图而不是继承".

这个前提的基本思想是将具有不同功能的多个对象放在一起以创建一个功能齐全的对象.这应该优先于从彼此无关的不同对象继承功能.

关于这一点的主要论点包含在利斯科夫替代原则的定义中,并在本海报中有趣地说明:

如果你有一个ToyDuck对象,你应该继承哪个对象,从纯粹的继承角度来看？你应该继承鸭子吗？不 - 你很可能应该继承玩具.

底线是你应该为你的代码使用正确的抽象方法 - 无论是继承还是组合.

对于当前对象,请考虑是否存在应该从继承树中删除的对象,并且仅包含作为可以调用和调用的属性.

Answer 2

继承不适合代码重用.继承代码重用通常会导致:

1. 具有继承方法的类,不能在它们上调用(违反Liskov替换原则),这会使程序员感到困惑并导致错误.
2. 深度层次结构,当它可以在十几个或更多类中的任何地方声明时,需要花费大量时间来查找所需的方法.

通常,继承树的深度不应超过两层或三层,通常只应继承接口和抽象基类.

然而,仅仅为了它而重写现有代码是没有意义的.但是,当您需要修改时,请尽可能切换到合成.这通常允许您以较小的部分修改代码,因为类之间的耦合会更少.