这篇文章描述了一种我觉得有趣的 OOP 方法:
What if objects exist as encapsulations, and the communicate via messages? What if code re-use has nothing to do with inheritance, but uses composition, delegation, even old-fashioned helper objects or any technique the programmer deems fit? The ontology does not go away, but it is decoupled from the implementation.
没有继承或依赖于类层次结构的重用的想法是我发现最令人震惊的,但这有多可行?
给出了示例,但我不太明白如何更改当前代码以适应这种方法。
那么这种方法的可行性如何呢?或者真的不需要更改代码,而是需要“仅在需要或最佳时使用”的基于场景的方法?
编辑:哎呀,我忘了链接:这里是 link
最佳答案
我相信你听说过“总是喜欢组合而不是继承”。
这一前提的基本思想是将具有不同功能的多个对象放在一起以创建一个功能齐全的对象。这应该优先于从彼此无关的不同对象继承功能。
关于这一点的主要论点包含在 Liskov Substitution Principle 的定义中。这张海报有趣地说明了这一点:
如果您有一个 ToyDuck 对象,从纯继承的角度来看,您应该从哪个对象继承?你应该继承鸭子吗?不——很可能你应该从 Toy 继承。
底线是您应该为您的代码使用正确的抽象方法——无论是继承还是组合。
对于您当前的对象,请考虑是否存在应该从继承树中删除并仅作为您可以调用和调用的属性包含的对象。
关于无继承的 OOP 重用 : How "real-world" practical is this?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4989670/