作者:大宽宽
链接:https://www.zhihu.com/question/305042684/answer/550196442
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

面向对象编程(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作为某种教条就大大的违反了这个思想的初衷,也只能得到拧巴的代码。

发表评论

邮箱地址不会被公开。 必填项已用*标注