几十年来，我一直在以对象为导向的语言进行编程。我使用的第一种OO语言是C ++，然后是SmallTalk，最后是.NET和Java。

我是为了利用遗产，，，，封装， 和多态性。范式的三个支柱。

我渴望获得重复使用的希望，并利用那些在这个新令人兴奋的景观中来到我面前的人所获得的智慧。

我无法将现实世界中的物体映射到他们的班级中，并期望整个世界都将整齐地落入到位。

我再错了。

继承，第一个跌落的支柱

乍一看，继承似乎是面向对象范式的最大好处。所有简单的形状层次结构示例被列为新灌输的示例，似乎是合乎逻辑的。

重用是一天的话。不……成为一年，也许是永远。

我吞咽了整个，并用新发现的洞察力冲向了世界。

香蕉猴丛林问题

有了我的内心宗教和问题，我开始建立班级等级结构和编写代码。一切都是正确的。

我永远不会忘记那天我准备通过从现有班级继承来兑现重复使用的承诺。这是我一直在等待的那一刻。

一个新的项目出现了，我回想起我上一个项目中我非常喜欢的那堂课。

没问题。重用进行营救。我要做的就是简单地从另一个项目中获取该课程并使用它。

好吧……实际上……不仅是那堂课。我们将需要父班。但是……但是就是这样。

gh…等等……看来我们也将需要父母的父母……然后……我们将需要所有父母。好吧……好吧……我处理这个。没问题。

而且很棒。现在它不会编译。为什么？？我懂了…这对象包含这是另一个目的。所以我也需要。没问题。

等等……我不仅需要那目的。我需要该对象的父母及其父母的父母，等等，等等，依此类推，依此类推，所有包含的对象以及所有这些对象以及父母，父母，父母……

啊。

有很棒的报价乔·阿姆斯特朗，Erlang的创造者：

面向对象的语言的问题在于他们拥有随身携带的所有隐含环境。您想要一个香蕉，但您得到的是一颗拿着香蕉和整个丛林的大猩猩。

香蕉猴丛林解决方案

我可以通过不创建太深的层次结构来驯服这个问题。但是，如果继承是重复使用的关键，那么我对该机制的任何限制肯定都会限制再利用的好处。正确的？

正确的。

那么，有什么贫穷的面向对象的程序员是对Kool-Aid的健康帮助？

包含并委托。稍后再详细介绍。

钻石问题

迟早，以下问题将纠正其丑陋，并且根据语言无法解决的头部。

大多数OO语言不支持这一点，即使似乎逻辑上有道理。用OO语言支持这种情况有什么困难？

好吧，想象以下伪代码：

class powereddevice {
}类扫描仪从powereddevice继承{
函数start（）{
}
}类打印机从powereddevice {
函数start（）{
}
}类复印机从扫描仪，打印机{
}

注意两个扫描器班级和打印机类实现一个称为的函数开始。

因此，哪个启动函数可以执行复印机类继承？这扫描器一？这打印机一？不可能两者。

钻石解决方案

解决方案很简单。不要那样做。

恩，那就对了。大多数OO语言都不会让您这样做。

但是，但是……如果我必须为此建模怎么办？我要我的重复使用！

那你必须包含并委托。

class powereddevice {
}类扫描仪从powereddevice继承{
函数start（）{
}
}类打印机从powereddevice {
函数start（）{
}
}类复印机{
扫描仪扫描仪
打印机打印机
函数start（）{
打印机.start（）
}
}

在这里注意到复印机现在，类包含一个实例打印机和扫描器。它委派了开始功能到打印机班级的实施。它可以很容易地委派给扫描器。

这个问题是继承支柱的另一个裂缝。

脆弱的基类问题

因此，我使我的层次结构浅，并防止它们周期性。我没有钻石。

一切都是正确的。直到…

有一天，我的代码工作，第二天它停止工作。这是踢脚。我没有更改代码。

好吧，也许这是一个错误……但是等等…确实有所改变…

但这不是我的代码。事实证明，变化是在我继承的班级中。

基础类别的更改如何破坏我的代码？

这就是……

想象以下基类（用Java编写，但是如果您不知道Java，应该很容易理解）：

导入java.util.arraylist;

公共类阵列
{
private arraylist