问题描述
我知道这个问题已经，但似乎总是假设继承至少有时比组合更可取。我想挑战这个假设，希望能获得一些理解。
我的问题是：从你可以用对象组合完成任何事情您可以使用经典继承，因为经典继承经常被滥用[1] ，因为对象组合使您可以灵活地更改委托对象运行时，为什么你会永远使用经典继承吗？
我可以理解为什么你会推荐Java和C ++等语言的继承不能为委派提供方便的语法。在这些语言中，只要不明显不正确，就可以使用继承来节省大量的输入。但是像Objective C和Ruby这样的其他语言为委托提供了经典的继承和非常方便的语法。 Go编程语言是我所知道的唯一一种语言，它决定了经典继承比它的价值更麻烦，并且仅支持代码重用的委托。
另一种陈述我的问题的方法是：即使你知道经典继承对于实现某个模型不是不正确的，这个理由足以使用它代替组合？
[1]许多人使用经典继承来实现多态，而不是让他们的类实现接口。继承的目的是代码重用，而不是多态。此外，有些人使用继承来模拟他们对is-a关系的直观理解。
更新
我只想澄清一下我的意思是当我谈论继承时：
我在谈论。我不谈论继承纯粹抽象的基类，这与实现接口相同，我记录的并不反对。
更新2
我知道继承是实现C ++多态的唯一方法。在这种情况下，你必须使用它是显而易见的。所以我的问题仅限于Java或Ruby等语言，它们提供了实现多态的不同方法（分别是接口和鸭子类型）。
如果您将未显式覆盖的所有内容委托给实现相同接口的其他对象（基础对象），那么您基本上在组合的基础上进行Greenspunned继承，但是（在大多数语言中）具有更多冗长和样板。使用组合而不是继承的目的是，您只能委派要委派的行为。
如果希望对象使用基类的所有行为，除非显式重写，那么继承是表达它的最简单，最简单，最直接的方式。 / p>
I know the question has been discussed before, but it seems always under the assumption that inheritance is at least sometimes preferable to composition. I'd like to challenge that assumption in hopes of gaining some understanding.
My question is this: Since you can accomplish anything with object composition that you can with classical inheritance and since classical inheritance is very often abused[1] and since object composition gives you flexibility to change the delegate object runtime, why the would you ever use classical inheritance?
I can sort of understand why you would recommend inheritance in some languages like Java and C++ that do not offer convenient syntax for delegation. In these languages you can save a lot of typing by using inheritance whenever it is not clearly incorrect to do so. But other languages like Objective C and Ruby offer both classical inheritance and very convienient syntax for delegation. The Go programming language is the only langage that to my knowledge has decided that classical inheritance is more trouble than it's worth and supports only delegation for code reuse.
Another way to state my question is this: Even if you know that classical inheritance is not incorrect to implement a certain model, is that reason enough to use it instead of composition?
[1] Many people use classical inheritance to achieve polymorphism instead of letting their classes implement an interface. The purpose of inheritance is code reuse, not polymorphism. Furthermore, some people use inheritance to model their intuitive understanding of an "is-a" relationship which can often be problematic.
Update
I just want to clarify what I mean exactly when I talk about inheritance:
I am talking about the kind of inheritance whereby a class inherits from a partially or fully implemented base class. I am not talking about inheriting from a purely abstract base class which amounts to the same thing as implementing an interface, which I for the record am not arguing against.
Update 2
I understand that inheritance is the only way to achieve polymorphism i C++. In that case it's obvious why you must use it. So my question is limited to languages such as Java or Ruby that offer distinct ways to achieve polymorphism (interfaces and duck typing, respectively).
If you delegate everything that you haven't explicitly overridden to some other object implementing the same interface (the "base" object), then you've basically Greenspunned inheritance on top of composition, but (in most languages) with a lot more verbosity and boilerplate. The purpose of using composition instead of inheritance is so that you can only delegate the behaviors you want to delegate.
If you want the object to use all the behavior of the base class unless explicitly overridden, then inheritance is the simplest, least verbose, most straightforward way to express it.
这篇关于为什么要使用继承？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！