怎么从本质上理解面向对象的编程思想？ 第1页

面向对象编程（OOP），是一种设计思想或者架构风格。OO语言之父Alan Kay，Smalltalk的发明人，在谈到OOP时是这样说的：

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).
...
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP.

简单解释一下上面的这几句话的大概意思：OOP应该体现一种网状结构，这个结构上的每个节点“Object”只能通过“消息”和其他节点通讯。每个节点会有内部隐藏的状态，状态不可以被直接修改，而应该通过消息传递的方式来间接的修改。

这个编程思想被设计能够编写庞大复杂的系统。

那么为什么OOP能够支撑庞大复杂的系统呢？用开公司举个例子。如果公司就只有几个人，那么大家总是一起干活，工作可以通过“上帝视角“完全搞清楚每一个细节，于是可以制定非常清晰的、明确的流程来完成这个任务。这个思想接近于传统的面向过程编程。而如果公司人数变多，达到几百上千，这种“上帝视角”是完全不可行的。在这样复杂的公司里，没有一个人能搞清楚一个工作的所有细节。为此，公司要分很多个部门，每个部门相对的独立，有自己的章程，办事方法和规则等。独立性就意味着“隐藏内部状态”。比如你只能说申请让某部门按照章程办一件事，却不能说命令部门里的谁谁谁，在什么时候之前一定要办成。这些内部的细节你管不着。类似的，更高一层，公司之间也存在大量的协作关系。一个汽车供应链可能包括几千个企业，组成了一个商业网络。通过这种松散的协作关系维系的系统可以无限扩展下去，形成庞大的，复杂的系统。这就是OOP想表达的思想。

第一门OOP语言是Ole-Johan Dahland和Kristen Nygaard发明的Simula（比smalltalk还要早）。从名字就可以看出来，是用来支撑“模拟系统”的。模拟这个场景非常适合体现OOP的这个思想。这个语言引入了object、class、subclass、inheritance、动态绑定虚拟进程等概念，甚至还有GC。Java很大程度上受了Simula的影响。我们在现在教书上讲解OOP类、实例和继承关系时，总会给出比如动物-猫-狗，或者形状-圆-矩形的例子，都源自于此。

还有一些带有OO特征的语言或者研究成果在Simula之前就出现，这里就不往前追溯了。

但随后在施乐Palo Alto研究中心（Xerox PARC），Alan Kay、Dan Ingalls、Adele Goldberg在1970年开发了smalltalk，主要用于当时最前沿计算模型研究。在Simula的基础之上，smalltak特别强调messaging的重要性，成为了当时最有影响力的OOP语言。与smalltalk同期进行的还有比如GUI、超文本等项目。smalltalk也最早的实现了在GUI使用MVC模型来编程。

但是，并不是说OOP程序一定要用OOP语言来写。再强调一下，OOP首先是一种设计思想，非仅仅是编码方式。从这个角度推演，其实OOP最成功的例子其实是互联网。（Alan Kay也是互联网前身ARPNET的设计者之一）。另外一个OOP典型的例子是Linux内核，它充分体现了多个相对独立的组件（进程调度器、内存管理器、文件系统……）之间相互协作的思想。尽管Linux内核是用C写的，但是他比很多用所谓OOP语言写的程序更加OOP。

现在很多初学者会把使用C++，Java等语言的“OOP”语法特性后的程序称为OOP。比如封装、继承、多态等特性以及class、interface、private等管家你在会被大量提及和讨论。OOP语言不能代替人类做软件设计。既然做不了设计，就只能把一些轮子和语法糖造出来，供想编写OOP程序的人使用。但是，特别强调，是OOP设计思想在前，OOP编码在后。简单用OOP语言写代码，程序也不会自动变成OOP，也不一定能得到OOP的各种好处。

我们在以为我们在OOP时，其实很多时候都是在处理编码的细节工作，而非OOP提倡的“独立”，“通讯”。以“class”为例，实际上我们对它的用法有：

• 表达一个类型（和父子类关系），以对应真实世界的概念，一个类型可以起到一个“模版”的作用。这个类型形成的对象会严格维护内部的状态（或者叫不变量）
• 表达一个Object（即单例），比如XXXService这种“Bean”
• 表达一个名字空间，这样就可以把一组相关的代码写到一起而不是散播的到处都是，其实这是一个“module”
• 表达一个数据结构，比如DTO这种
• 因为代码复用，硬造出来的，无法与现实概念对应，但又不得不存在的类
• 提供便利，让foo(a)这种代码可以写成a.foo()形式

其中前两种和OOP的设计思想有关，而其他都是编写具体代码的工具，有的是为了代码得到更好的组织，有的就是为了方便。

很多地方提及OOP=封装+继承+多态。我非常反对这个提法，因为这几个术语把原本很容易理解的，直观的做事方法变的图腾化。初学者往往会觉得他们听上去很牛逼，但是使用起来又经常和现实相冲突以至于落不了地。

“封装”，是想把一段逻辑/概念抽象出来做到“相对独立”。这并不是OOP发明的，而是长久以来一直被广泛采用的方法。比如电视机就是个“封装”的好例子，几个简单的操作按钮（接口）暴露出来供使用者操作，复杂的内部电路和元器件在机器里面隐藏。再比如，Linux的文件系统接口也是非常好的“封装”的例子，它提供了open，close，read，write和seek这几个简单的接口，却封装了大量的磁盘驱动，文件系统，buffer和cache，进程的阻塞和唤醒等复杂的细节。然而它是用函数做的“封装”。好的封装设计意味着简洁的接口和复杂的被隐藏的内部细节。这并非是一个private关键字就可以表达的。一个典型的反面的例子是从数据库里读取出来的数据，几乎所有的字段都是要被处理和使用的，还有新的字段可能在处理过程中被添加进来。这时用ORM搞出一个个实体class，弄一堆private成员再加一堆getter和setter是非常愚蠢的做法。这里的数据并非是具有相对独立性的，可以进行通讯的“Object“，而仅仅是“Data Structure”。因此我非常喜欢有些语言提供“data object”的支持。

当然，好的ORM会体现“Active Record”这种设计模式，非常有趣，本文不展开

再说说“继承”，是希望通过类型的 is-a 关系来实现代码的复用。绝大部分OOP语言会把is-a和代码复用这两件事情合作一件事。但是我们经常会发现这二者之间并不一定总能对上。有时我们觉得A is a B，但是A并不想要B的任何代码，仅仅想表达is-a关系而已；而有时，仅仅是想把A的一段代码给B用，但是A和B之间并没有什么语义关系。这个分歧会导致严重的设计问题。比如，做类的设计时往往会希望每个类能与现实当中的实体/概念对应上；但如果从代码复用角度出发设计类，就可能会得到很多现实并不存在，但不得不存在的类。一般这种类都会有奇怪的名字和非常玄幻的意思。如果开发者换了个人，可能很难把握原来设计的微妙的思路，但又不得不改，再稳妥保守一点就绕开重新设计，造成玄幻的类越来越多…… 继承造成的问题相当多。现在人们谈论“继承”，一般都会说“Composite Over Inheritance“。

多态和OOP也不是必然的关系。所谓多态，是指让一组Object表达同一概念，并展现不同的行为。入门级的OOP的书一般会这么举例子，比如有一个基类Animal，定义了run方法。然后其子类Cat，Dog，Cow等都可以override掉run，实现自己的逻辑，因为Cat，Dog，Cow等都是Animal。例子说得挺有道理。但现实的复杂性往往会要求实现一个不是Animal的子类也能“run”，比如汽车可以run，一个程序也可以“run”等。总之只要是run就可以，并不太在意其类型表达出的包含关系。这里想表达的意思是，如果想进行极致的“多态”，is-a与否就不那么重要了。在动态语言里，一般采用duck typing来实现这种“多态”——不关是什么东西，只要觉得他可以run，就给他写个叫“run”的函数即可；而对于静态语言，一般会设计一个“IRun”的接口，然后mixin到期望得到run能力的类上。简单来说，要实现多态可以不用继承、甚至不用class。

OOP一定好吗？显然是否定的。回到OOP的本心是要处理大型复杂系统的设计和实现。OOP的优势一定要到了根本就不可能有一个“上帝视角”的存在，不得不把系统拆成很多Object时才会体现出来。

举个例子，smalltalk中，1 + 2 的理解方式是：向“1”这个Object发送一给消息“+”，消息的参数是“2”。的确是非常存粹的OOP思想。但是放在工程上，1 + 2理解为一般人常见的表达式可能更容易理解。对于1 + 2这样简单的逻辑，人很容易从上帝视角出发得到最直接的理解，也就有了最简单直接的代码而无用考虑“Object”。

如果是那种“第一步”、“第二步“……的程序，面向数据的程序，极致为性能做优化的程序，是不应该用OOP去实现的。但很无奈如果某些“纯OOP语言”，就不得不造一些本来就不需要的class，再绕回到这个领域适合的编码模式上。比如普通的Web系统就是典型的“面向”数据库这个中心进行数据处理（处理完了展示给用户，或者响应用户的操作）。这个用FP的思路去理解更加简单，直观。也有MVC，MVVM这样的模式被广泛应用。

还有一些领域尽管用OOP最为基础很适合，但是根据场景，已经诞生出了“领域化的OOP”，比如GUI是一个典型的例子。GUI里用OOP也是比较适合的，但是GUI里有很多细节OOP不管或者处理不好，因此好的GUI库会在OOP基础之上扩展很多。早期的MFC，.Net GUI Framework, React等都是这样。另外一个领域是游戏，用OOP也很合适，但也是有些性能和领域细节需要特殊处理，因此ECS会得到广泛的采用。

总结一下，OOP是众多设计思想中的一种。很多OOP语言把这种思想的不重要的细节工具化，但直接无脑应用这些工具不会直接得到OOP的设计。即便是OOP思想本身也有其适合的场景和不适合的场景。即便是适合的场景，也可能针对这个场景在OOP之上做更针对这个场景需求的定制的架构/框架。如果简单把OOP作为某种教条就大大的违反了这个思想的初衷，也只能得到拧巴的代码。