面向对象编程，再见！

作为程序员，你是使用函数式编程还是面向对象编程方式？在本文中，拥有 10 多年软件开发经验的作者从面向对象编程的三大特性——继承、封装、多态三大角度提出了自己的疑问，并深刻表示是时候和面向对象编程说再见了。

几十年来我都在用面向对象的语言编程。我用过的第一个面向对象的语言是 C++，后来是 Smalltalk，最后是 .NET 和 Java。

我曾经对使用继承、封装和多态充满热情。它们是范式的三大支柱。

我渴望实现重用之美，并在这个令人兴奋的新天地中享受前辈们积累的智慧。

想到将现实世界的一切映射到类中，使得整个世界都可以得到整齐的规划，我无法抑制自己的兴奋。

然而我大错特错了。

1.继承，倒塌的第一根支柱

乍一看，继承似乎是面向对象范式的最大优势。所有新手教程讲解继承时都会拿出最简单的继承的例子，而这个例子似乎很符合逻辑。

然后就是满篇的重用了。甚至以后的一切都是重用了。

我囫囵吞下这一切，然后带着新发现兴冲冲地奔向世界了。

香蕉猴子丛林问题

带着满腔的信仰和解决问题的热情，我开始构建类的层次结构然后写代码。似乎一切皆在掌控中。

我永远不会忘记我准备从已有的类继承并实现重用的那一天。那是我期待已久的时刻。

后来有了新的项目，我想起了另一个项目里我很喜欢的那个类。

没问题，重用拯救一切。我只需要把那个类拿过来用就好了。

嗯……其实……不仅是那一个类。还得把父类也拿过来。但……应该就可以了吧。

额……不对，似乎还需要父类的父类……还有……嗯，我们需要所有的祖先类。好吧好吧……搞定了。没问题。

不错。但编译不过，怎么回事？哦我知道了……这个对象还需要另一个对象。所以那个也得拿过来。没问题……

等等……我不仅需要那个对象，还需要那个对象的父类，和父类的父类，和……包含的所有对象的所有祖先……

唉……

Erlang 的创建者 JoeArmstrong 有句名言：

面向对象语言的问题在于，它们依赖于特定的环境。你想要个香蕉，但拿到的却是拿着香蕉的猩猩，乃至最后你拥有了整片丛林。

香蕉猴子丛林的解决方法

这个问题的解决方法是，不要把类层次建得那么深。但如果继承是重用的关键，那么给继承机制添加的任何限制都会限制重用。对吧？

没错。

那我们可怜的面向对象程序员该怎么办？指望一杯三聚氰胺奶维系我们的健康吗？

答案就是：包含和委托（Contain and Delegate）。一会儿会详细解释。

菱形继承问题

早晚你会遇到下面这种恶心的问题，有些语言甚至根本解决不了。

大多数面向对象语言都不支持这种情况，尽管看上去似乎很符合逻辑。为什么面向对象语言支持这种情况如此困难？

来看看下面的伪代码：

Class PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
  function start() {
  }
}
Class Printer inherits from PoweredDevice {
  function start() {
  }
}
Class Copier inherits from Scanner, Printer {
}

注意 Scanner 和 Printer 类都实现了名为 start 方法。

那么问题来了，Copier继承哪个start？是Scanner的还是Printer的？肯定不可能同时继承啊。

菱形继承的解决

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

没错。大多数面向对象都不让你这么干。

但是，但是……要是必须这样建模该怎么办？我需要重用！

那就必须使用包含和委托。

Class PoweredDevice {
}
Class Scanner inherits from PoweredDevice {
  function start() {
  }
}
Class Printer inherits from PoweredDevice {
  function start() {
  }
}
Class Copier {
  Scanner scanner
  Printer printer
  function start() {
    printer.start()
  }
}

注意现在 Copier 类包含一个 Printer 实例和一个 Scanner 实例。然后将 start 函数委托给 Printer 类的实现。要委托给 Scanner 也很简单。

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

脆弱的基类问题

好吧，那我尽量使用较浅的类层次结构，并保证里面没有环，这样就不会出现菱形继承了。

似乎一切都解决了。直到我们发现……

我前一天工作得好好的代码今天出错了！关键是，我没有改任何代码！

嗯也许是个 bug……但等等……的确有些改动……

但改动的不是我的代码。似乎改动来自我继承的那个类。

为什么基类的改动会破坏我的代码？

原来是这样……

看看下面这个基类（用Java写的，但就算你不懂Java，应该也很容易看懂）：

import java.util.ArrayList;

public class Array
{
  private ArrayList