为什么更喜欢组合而不是继承?每种方法都有哪些权衡?什么时候应该选择继承而不是组合?
当前回答
简而言之,我同意“比起继承,我更喜欢成分”,但对我来说,这听起来常常像“比起可口可乐,我更爱土豆”。有继承的地方,也有合成的地方。你需要了解差异,然后这个问题就会消失。这对我来说真正的意义是“如果你要使用继承——再想想,你很可能需要复合”。
当你想吃的时候,你应该更喜欢土豆而不是可口可乐,当你想喝的时候,应该更喜欢可口可乐而不是土豆。
创建子类不仅仅意味着调用超类方法的便捷方式。当子类在结构上和功能上都是一个超级类时,您应该使用继承,因为它可以用作超级类,并且您将使用它。如果不是这样的话,那不是继承,而是其他东西。合成是指你的对象由另一个组成,或者与它们有某种关系。
所以对我来说,如果有人不知道自己是否需要继承或组成,真正的问题是他不知道自己是想喝酒还是想吃饭。多想想你的问题领域,更好地理解它。
其他回答
我听过的一条经验法则是,当它是一种“is-A”关系时,应该使用继承;当它是“has-A”关系的时候,应该使用组合。尽管如此,我觉得你应该始终倾向于构图,因为它消除了很多复杂性。
简单地说,实现就像你(类)应该遵循的规则
但是扩展就像对很多类使用公共代码,也许只是其中一个需要重写。
你想强迫自己(或其他程序员)坚持什么,什么时候你想让自己(或另一个程序员)有更多的自由。有人认为,当你想强迫某人以某种方式处理/解决某个特定问题时,继承是有帮助的,这样他们就不会走错方向。
Is-a和Has-a是一个有用的经验法则。
你需要看看Bob叔叔的SOLID类设计原则中的Liskov替换原则。:)
我看没有人提到钻石问题,这可能是继承带来的。
总之,如果类B和C继承了a,并且都重写了方法X,而第四个类D继承了B和C,并且没有重写X,那么应该使用X D的哪个实现?
维基百科对这个问题中讨论的主题提供了一个很好的概述。