为什么更喜欢组合而不是继承?每种方法都有哪些权衡?什么时候应该选择继承而不是组合?
当前回答
继承是非常强大的,但你不能强迫它(参见:圆-椭圆问题)。如果你真的不能完全确定一个真正的“is-a”子类型关系,那么最好是组合。
其他回答
继承是非常强大的,但你不能强迫它(参见:圆-椭圆问题)。如果你真的不能完全确定一个真正的“is-a”子类型关系,那么最好是组合。
除了是/有一个考虑因素之外,还必须考虑对象必须经历的继承的“深度”。任何超过五或六级继承深度的内容都可能会导致意外的强制转换和装箱/拆箱问题,在这种情况下,编写对象可能是明智的。
合成与继承是一个广泛的主题。对于什么更好,没有真正的答案,因为我认为这一切都取决于系统的设计。
通常,对象之间的关系类型为选择其中一个对象提供了更好的信息。
如果关系类型是“is-A”关系,则继承是更好的方法。否则关系类型为“HAS-A”关系,则组合将更接近。
这完全取决于实体关系。
就我个人而言,我学会了总是喜欢组合而不是继承。没有可以用继承解决的编程问题,而不能用组合解决;尽管在某些情况下,您可能必须使用接口(Java)或协议(Obj-C)。因为C++不知道任何这类东西,所以您必须使用抽象基类,这意味着您无法完全摆脱C++中的继承。
组合通常更符合逻辑,它提供了更好的抽象、更好的封装、更好的代码重用(尤其是在非常大的项目中),并且不太可能因为您在代码中的任何地方进行了孤立的更改而在远处破坏任何东西。这也使得维护“单一责任原则”变得更容易,该原则通常被概括为“一个类的改变不应该有一个以上的原因”,这意味着每个类都是为了一个特定的目的而存在的,它只应该有与其目的直接相关的方法。此外,拥有一个非常浅的继承树,即使您的项目开始变得非常大,也可以更容易地保持概述。许多人认为遗产很好地代表了我们的现实世界,但事实并非如此。现实世界使用的合成比继承多得多。几乎每一个你能拿在手中的现实世界物体都是由其他更小的现实世界对象组成的。
不过,组合也有缺点。如果您完全跳过继承,只关注组合,您会注意到,如果您使用了继承,通常需要编写一些额外的代码行。你有时也会被迫重复自己,这违反了干原则(干=不要重复自己)。此外,组合通常需要委托,一个方法只是调用另一个对象的另一个方法,而没有其他代码围绕此调用。这种“双重方法调用”(可能很容易扩展到三重或四重方法调用,甚至更远)的性能要比继承差得多,因为继承只是继承父级的方法。调用继承的方法可能与调用非继承的方法一样快,也可能稍慢,但通常仍比两个连续的方法调用快。
您可能已经注意到,大多数OO语言不允许多重继承。虽然在一些情况下,多重继承确实可以为您带来一些东西,但这些都是例外,而不是规则。每当你遇到一个你认为“多重继承将是解决这个问题的一个非常酷的特性”的情况时,你通常都应该重新考虑继承,因为即使它可能需要一些额外的代码行,基于组合的解决方案通常会变得更加优雅、灵活和经得起未来考验。
继承确实是一个很酷的功能,但我担心它在过去几年中被过度使用了。人们将遗产视为一把能钉住一切的锤子,不管它实际上是一颗钉子、一颗螺丝钉,还是一个完全不同的东西。
这两种方式可以很好地生活在一起,并相互支持。
组合只是将其模块化:您创建类似于父类的接口,创建新对象并将调用委托给它。如果这些对象不需要彼此了解,那么组合是非常安全且易于使用的。这里有很多可能性。
然而,如果父类出于某种原因需要访问“子类”为没有经验的程序员提供的函数,那么它可能看起来是一个使用继承的好地方。父类可以只调用它自己的抽象“foo()”,该抽象被子类覆盖,然后它可以将值赋给抽象基。
这看起来是一个不错的想法,但在许多情况下,只给类一个实现foo()的对象(或者甚至手动设置foo)提供的值)要好于从需要指定foo函数的基类继承新类。
Why?
因为继承是传递信息的一种糟糕方式。
组合在这里有一个真正的优势:关系可以颠倒:“父类”或“抽象工作者”可以聚合实现特定接口的任何特定“子”对象+任何子对象都可以设置在接受其类型的任何其他类型的父类中。而且可以有任意数量的对象,例如MergeSort或QuickSort可以对实现抽象比较接口的任何对象列表进行排序。或者换一种说法:实现“foo()”的任何一组对象和可以使用具有“foo)”的对象的其他一组对象都可以一起玩。
我可以想到使用继承的三个真正原因:
您有许多具有相同接口的类,您希望节省编写它们的时间必须为每个对象使用相同的基类您需要修改私有变量,在任何情况下都不能是公共的
如果这些都是真的,那么可能需要使用继承。
使用原因1没有什么不好的,在对象上有一个坚实的界面是非常好的。这可以使用组合或继承来完成,没有问题——如果这个接口简单且不改变。通常,继承在这里非常有效。
如果原因是第二,那就有点棘手了。你真的只需要使用相同的基类吗?一般来说,仅仅使用相同的基类是不够的,但这可能是框架的一个要求,这是一个无法避免的设计考虑。
然而,如果您想使用私有变量,即案例3,那么您可能会遇到麻烦。如果您认为全局变量不安全,那么应该考虑使用继承来访问私有变量也不安全。请注意,全局变量并不是那么糟糕——数据库本质上是一组全局变量。但如果你能处理,那就很好了。