我知道之前已经讨论过这个问题,但似乎总是假设继承至少有时候比组合更好.我想挑战这个假设,希望获得一些理解.
我的问题是:既然你可以完成与对象组合东西,你可以用经典的继承和自经典的继承是很经常被滥用[1] ,自对象组合为您提供了灵活地改变委托对象运行时,为什么你会永远使用经典继承？
我可以理解为什么你会推荐Java和C++等语言中的继承,这些语言不能提供方便的委派语法.在这些语言中,只要不明显不正确,就可以使用继承来节省大量的输入.但是像Objective C和Ruby这样的其他语言提供了经典的继承和非常方便的委托语法.Go编程语言是我所知道的唯一一种语言,它认为经典继承比它的价值更麻烦,并且仅支持代码重用的委托.
陈述我的问题的另一种方式是:即使您知道经典继承对于实现某个模型不是不正确的,那么这个理由是否足以使用它而不是组合？
[1]许多人使用经典继承来实现多态,而不是让他们的类实现接口.继承的目的是代码重用,而不是多态.此外,有些人使用继承来模拟他们对"is-a"关系的直观理解,这种关系往往是有问题的.
更新
我只想在谈到继承时澄清我的意思:
我在谈论一种继承的类型,即一个类继承自部分或完全实现的基类.我不是在谈论继承纯粹抽象的基类,这与实现接口相同,我记录的并不反对.
更新2
我知道继承是实现C++多态性的唯一方法.在这种情况下,显而易见的是你必须使用它.所以我的问题仅限于Java或Ruby等语言,这些语言提供了实现多态的不同方法(分别是接口和鸭子类型).
我必须承认我有点像OOP怀疑论者.面向对象的不良教学和实验经验无济于事.所以我转变成了Visual Basic中的狂热信徒(经典之作!).
然后有一天我发现C++已经改变了,现在有了STL和模板.我真的很喜欢!使语言有用.然后另一天MS决定对VB进行面部手术,我真的很讨厌无端更改的最终结果(使用"end while"而不是"wend"会让我成为一个更好的开发者？为什么不放下"next"for"结束了",为什么呢？为什么强迫getter和setter一起？等等？加上我发现无用的Java特性(例如继承,以及分层框架的概念).
现在,几年后,我发现自己在问这个哲学问题:遗产真的需要吗？
四人一组说我们应该支持对象组合而不是继承.在考虑它之后,我找不到你可以用继承做的事情,你不能用对象聚合和接口做.所以我想知道,为什么我们甚至在第一时间拥有它？
有任何想法吗？我很想看到一个例子,说明继承器肯定需要在哪里,或者使用继承而不是组合+接口可以导致更简单和更容易修改的设计.在以前的工作中,我发现如果你需要更改基类,你还需要修改几乎所有的派生类,因为它们取决于父行为.如果你使基类'方法虚拟...那么没有太多的代码共享发生:(
另外,当我最终创建自己的编程语言(我发现大多数开发人员共享的长期未满足的愿望)时,我认为添加继承没有任何意义......
组成和继承.
我知道它们都是适当选择的工具,上下文在组合和继承之间进行选择时非常重要.然而,关于每个的适当背景的讨论通常有点模糊; 这让我开始考虑传统OOP的独特方面是多么明显的继承和多态.
多态性允许人们同等地指定"is-a"关系以及继承.特别是,从基类继承隐式地创建该类与其子类之间的多态关系.然而,尽管可以使用纯接口实现多态,但是继承通过同时传输实现细节使多态关系复杂化.通过这种方式,继承与纯多态性完全不同.
作为一种工具,继承通过简化在无关紧要的情况下重用实现,为程序员提供与多态(通过纯接口)不同的方式.但是,在大多数情况下,超类的实现细节与子类的要求略有冲突.这就是为什么我们有"覆盖"和"成员隐藏"的原因.在这些情况下,继承所提供的实现重用是通过在级联级别的代码中验证状态更改和执行路径的额外工作来购买的:子类的完整"扁平化"实现细节分布在多个类之间,这通常意味着多个文件,其中只有部分适用于相关的子类.在处理继承时,查看该层次结构是绝对必要的,因为如果不查看超类的代码,就无法知道哪些未覆盖的细节会对您的状态进行整理或转移您的执行.
相比之下,独占使用组合可以保证您可以看到哪些状态可以通过显式实例化对象进行修改,这些对象的方法可以自行调用.真正扁平化的实现仍然没有实现(实际上甚至不可取,因为结构化编程的好处是实现细节的封装和抽象)但是你仍然可以重用代码,你只需要在一个地方查看当代码行为不端时.
我的目标是在实践中测试这些想法,避免传统继承为基于纯接口的多态性和对象组合的组合,我想知道,
有什么对象组成和接口无法实现继承吗？
编辑
在迄今为止的回复中,ewernli认为一种技术没有技术专长,而另一种技术则没有; 后来他提到了每种技术固有的不同模式和设计方法.这是有道理的.但是,这个建议让我通过询问是否专用组合和界面代替传统继承来禁止使用任何主要设计模式来改进我的问题？如果是这样,在我的情况下是不是有相同的模式？
我刚刚学习oop并且正在努力解决继承和多态之间的差异.
如果我理解正确,继承定义了类型层次结构和类之间的关系.子类从父类继承行为,并且可以提供父级上任何公共接口的专门行为.
多态性是这些子类可以提供自己的行为,同时仍然遵循父接口.
这是不是一回事吗？
假设我们有一个interface叫做Animal有所谓的两种方法move()和makeSound()。
这意味着我们可以发送消息move()和makeSound()类型的变量Animal，并且我们只能将实现的类的对象分配给Animal类型的变量Animal。
现在我的问题是，Java 是否可以不强制想要使用多态的类来实现interface?
例如，为什么 Java 没有像下面这样实现多态：
我们只需创建一个Animal interface，然后我们就可以将我们想要的任何对象分配给一个类型的变量，Animal只要该对象具有方法move()and makeSound()，例如：
Animal animal1;
/* The Java compiler will check if Dog have the methods move() and makeSound(), if yes then
compile, if no then show a compilation error */
animal1 = new Dog();
animal1.move();
animal1.makeSound();
注意：我以 Java 为例，但我一般是在谈论所有 OOP 语言。另外，我知道我们可以使用继承自超类的子类来实现多态（但这与使用 的想法基本相同interface）。