Why OO sucks

为什么OO很恶心

原文： http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
作者：Joe Armstrong

当我第一次知道OOP的概念时，我非常疑惑，但是不知道为啥——它仅仅在感觉上“不对”。
在OOP问世之后变得粉流行（稍后解释为什么），而批评OOP就像“在教堂里咒骂”。
OO成为了每个受尊敬的语言必须具备的一部分。

而当Erlang变得越来越流行时，我们经常问一个问题“Erlang是OO的吗？”
当然正确的答案是“当然不是”——但是我们没有大肆宣扬——我们只是换了种精心设计的说法，Erlang是某种OO但不是真的是。

这时我想起在法国巴黎时IBM的老板在7th IEEE逻辑编程大会上的演讲。
IBM prolog添加了许多OO扩展，当人们问起时他说：“我们的客户想要OO的prolog，所以我们构建了OO的prolog”

我想到了“多么简单，没有良心的疑虑，没有灵魂的搜索，没有‘这是正确的事情’的问题。。。”

为什么OO很恶心

我对OOP的反对原则源自一些基本的概念，我将概述其中一些反对意见。

反对之一——数据类型和方法应该绑定在一起
对象将方法和数据结构绑定在一起成为不可分割的单元。我认为这是基本的错误，因为方法和数据结构属于完全不同的世界。为啥哩？

1，方法做事情。它们是输入和输出。输入和输出的是方法所改变的数据结构。
在大部分编程语言里，方法由命令式语句顺序构建：“做这件事然后那件事。。。”
理解方法首先得理解做事情的顺序（在懒惰函数编程语言和逻辑语言中这个限制被放宽了）
2，数据结构是结构。它们不做任何事情。它们本质上是声明。“理解”数据结构比“理解”方法简单多了。

方法作为黑盒子来转换输入和输出。如果我理解输入和输出，这样我就理解了方法。这并不意味着我可以写这个方法。

方法通常理解为在一个计算系统里用来将数据结构T1转换为数据结构T2的东西。

既然方法和数据结构是完全不同类型的动物，那么将它们锁在一个笼子里就是完全错误的。

2，反对之二——任何东西都必须为对象
考虑“时间”。在OO语言里“时间”也必须是对象。但是在非OO语言里一个“时间”是一个数据结构的实例。
例如，在Erlang里有许多不同类型的时间，它们可以使用类型声明来明确指定：

-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...

注意这些定义不属于任何特殊的对象。它们很普遍，并且数据结构表示的时间可以被系统中的任何方法处理。

没有相关联的方法。

反对之三——在一个OOP语言里数据类型定义散布到任意位置
在OOP语言里数据类型定义属于对象。
这样我就不能在一个地方找到所有的数据类型定义。
在Erlang或者C里我可以在一个单独的include文件或数据字典里定义我所有的数据类型。
在一个OOP语言里我不能——数据类型定义散布到任意位置。

让我举一个例子。假设我想定义一个通用的数据结构。通用数据类型是一个数据类型，它在系统中的任意位置出现。

lisp程序员知道，拥有一个较小数量的通用数据类型和在它上面的大量的小方法会更好。

通用数据类型就比如linked list，或者一个array或者一个hash table或者更高级的对象如time或者date或者filename。

在一个OOP语言里我不得不选择一些base对象来在里面定义通用的数据结构，所有其他想使用这些数据结构的对象必须继承该对象。
假设现在我想创建一些“time”对象，那么它应该属于哪个对象呢。。。

反对之四——对象拥有私有状态
状态是所有罪恶的根源。特别是有副作用的方法应该避免。

在编程语言里状态是令人讨厌的，而真实世界里状态却千奇百怪的存在着。
我对我的银行账户的状态很感兴趣，当我从我的账户存钱或取钱时我希望我的银行账户状态成功更新。

既然状态在真实世界里存在，那么编程语言应该提供什么能力来处理状态呢？

1，OOP语言说“将状态隐藏”。状态仅仅通过访问方法来隐藏和可见。
2，传统编程语言（C，Pascal）说状态的可见度由语言的scope规则来决定。
3，纯声明式语言说没有状态。系统的全局状态转移到方法里然后从方法里出来。
类似于monad(函数式编程语言)和DCG(逻辑语言)等机制被用来隐藏状态，这样它们可以像“有没有状态无所谓”一样来编程，但是对系统状态的完全访问是必需的。

OOP语言所选择的“隐藏状态”可能是最坏的选择。
它们不是将状态显示出来并寻找减少状态的坏处的方式，而是将状态隐藏起来。

为什么OO粉流行？

1，原因1——它被认为很容易学
2，原因2——它被认为让代码更易重用
3，原因3——它被大肆宣传
4，原因4——它创建了一个新的软件工业

我看不到原因1和原因2的证据。原因看起来像是技术背后的驱动力。
如果一个编程语言技术如此之差，然后它创建了一个新的工业来解决它自己本身的问题，则它会成为想从中牟利的人的好工具。

这就是OOP背后真正的驱动力。

以及一篇回复：Why "Why OO Sucks" Sucks

评论

153 楼 xhanxhanxhan 2008-10-07  

看成去QQ SUCK 了

152 楼 davidzhao 2008-09-30  

怎么样觉得好就怎么用
你何必管别人OO还是不OO呢?
符合设计模式 大家有共同的专业术语
如果没有了这些 那就是倒退到面向过程

151 楼 VonNeumann 2008-09-23  

楼上有位说人ID好的
我这个ID咋样？

被这贴深深的雷到了
PS：T1是个好辩手，用到了很多辩论的技巧

150 楼 abettor 2008-09-17  

我怎么觉得这个话题放在21世纪简直就像在争论地球是不是圆的一样呢。

149 楼 bcccs 2008-09-16  

yayv 写道

OO流行，是因为使GUI开发变得简单，人们自然希望把这种成功推广到所有的开发环境。

突然看到，oo开发真的使gui开发简单了？
我怎么觉得任何语言的gui库都很别扭呢。
无论cpp，java，都不是靠GUI起家的。

148 楼 devil-wx 2008-09-16  

无力的反驳

147 楼 andyss 2008-09-16  

越来越觉得这些人很"操蛋", 问题就在于这样讨论的意义在什么地方, 只说不做, 说完之后照样跟说之前用什么语言就用什么语言, 用什么思想就用什么思想. 虚伪啊! 整天只知道拿纸给老外擦屁股再给自己擦屁股, 根本没有勇气倒过来.

146 楼 yayv 2008-09-06  

OO流行，是因为使GUI开发变得简单，人们自然希望把这种成功推广到所有的开发环境。

145 楼 jasongreen 2008-09-06  

多研究些问题，少谈些主义

java是OO吗？static的存在就有悖OO

144 楼 seele 2008-09-05  

...OO和数据操作是两个不同的内容..拿来比较干什么？

相辅相成...

OO的思想用来配合需求
数据操作用来处理需求中的内容数据...

你用OO单纯去处理数据是很麻烦..

各有各的长处,也有短处....

突然想起很早以前的一个谈论。...五笔和拼音哪个好....

143 楼 seemoon 2008-09-04  

haiyan_qi 写道

seemoon 写道

感觉这个帖子的争论很水，真的，想不到还有人在无聊的说这些事情。tiobe 08年编程语言的排名上，c仍名列三甲，这个话题就好比java vs. .net一样没有什么意义。做微内核的底层操作系统，你需要用oo来写吗？做一个业务系统，你需要用老cobol去写吗？

你不知道银行的核心业务系统就是用cobol来写的吗？无知没关系，但别露出你的愚昧。

呵呵，legacy system好吧？这牛角钻得够深的。的确人固有愚昧的一面。

142 楼 haiyan_qi 2008-09-03  

seemoon 写道

感觉这个帖子的争论很水，真的，想不到还有人在无聊的说这些事情。tiobe 08年编程语言的排名上，c仍名列三甲，这个话题就好比java vs. .net一样没有什么意义。做微内核的底层操作系统，你需要用oo来写吗？做一个业务系统，你需要用老cobol去写吗？

你不知道银行的核心业务系统就是用cobol来写的吗？无知没关系，但别露出你的愚昧。

141 楼 seemoon 2008-09-02  

感觉这个帖子的争论很水，真的，想不到还有人在无聊的说这些事情。tiobe 08年编程语言的排名上，c仍名列三甲，这个话题就好比java vs. .net一样没有什么意义。做微内核的底层操作系统，你需要用oo来写吗？做一个业务系统，你需要用老cobol去写吗？

没有oo，那么今天我们要写个代码就变成这个样子：

================================================
1. 问题分析
    在正式的程序设计之前首先要分析和透彻地理解问题本身，用结构化的分析方法分析问题的结构。要克服急于编程的欲望，开始时必须保证有一段时间集中精力分析软件应当做什么，而不是如何来做。根据问题的性质和要求构造一个满足问题要求和限制的系统。
    结构化分析的基本方法就是“分解”和“抽象”。把一个大问题分割成若干个小问题，然后分别解决，这就是“分解”。先考虑问题的本质和功能，暂把问题的细节略去，以后再考虑实现的细节，这就是“抽象”。自顶向下逐层分解的分析体现了分解和抽象的原则，使人们不至于一下子陷入细节，这样有助于正确地理解问题，避免走“冤枉路”。
    在结构化分析阶段，学生应先画出问题流程图，导出系统的逻辑模型，用约定的图型和记号，对问题进行逻辑上的模拟和描述。
    2. 结构化设计
    在导出了问题流程以后，就可以进行系统结构设计，即把问题模型转化为系统结构模型。这个阶段的工作是将系统划分成一个个模块，选择数据结构，定义在其上进行的操作，利用这些操作便可以实现系统所要求的功能。每一个操作是一个过程或函数，其对应于一个模块，以完成系统的子功能。所有模块应按从上向下调用的原则构成层次型的结构图，并与问题的逻辑结构相对应。
    在结构化设计过程中要列出过程和函数间的调用关系，过程的接口部分说明,模块之间的输入输出方式，模块之间传递什么数据类型，求精所得出的模块结构图。
    用结构化的自然语言描述模块所要做的工作和输入输出。
    在把系统划分成模块时，要考虑以下几个因素： 模块内部数据联系度要大，模块问的联系度要低，模块尽量通过少数参数联系，模块间的共享信息应尽量少。
    3. 过程设计
    即确定每个模块的内部特征，即怎样做的问题。按照在前一阶段规定的逻辑模块设计程序和控制结构，使程序结构清晰、流畅。
    按照操作的要求确定数据结构及其算法。
    使用顺序，选择和循环三种基本的单入口和单出口的控制结构描述过程的内部流程,使程序的基本结构与问题的流图结构保持一致，使程序的静态结构与动态执行保持一致,使过程流图易读、易编码、易修改。
    过程设计主要有图形描述方法和设计语言描述方法两种，前者有流程图、 N-S盒图和PAD(程序分析图)。如采用C语言来进行程序设计，在过程设计阶段可采用三个基本的控制结构和自然语言来描述程序流程，用这种方法进行过程设计，其结构与最终的程序接近，很容易进一步细化，编写正式的语言程序。
    4. 结构化编程
    在完成了过程设计之后，就可以着手编写C程序了。在编程时除了要求源程序的语法正确、程序逻辑无误，还要求程序有较好的可读性、可靠性、健壮性、可测试性和可修改性。
    结构化程序设计支持自顶向下、逐步求精的思想，采用顺序、选择和重复三种单入口、单出口基本控制语句和它们的嵌套组合来构成具有复杂层次的结构化程序,用这种方法编制出来的程序具有较好的可读性、可靠性和可测试性。结构化编程方法严格限制goto语句的使用。
    (1) 结构化编程要求程序员有良好的程序设计风格，程序结构友好，层次分明,思想清晰。
    (2) 采用良好的程序书写文体和格式，程序行按程序的层次结构合理安排缩格,使其按锯齿形排列。程序中插入必要的空行，使逻辑结构更加清晰、易读。
    (3) 在程序中加上必要的注释。注释有序言性和功能性两类。注释要包含程序模块的功能、界面接口及进入及离开模块的参数的说明、调用语句的格式。对程序中的数据结构及重要变量和一些主要语句要加以说明。一般讲注释的总量约占全部源程序的三分之一到一半以上。注释要在开发过程中形成，而不能在上机完成后补写。
    (5) 选用有意义的常量、类型和变量标识符，并使这些标识符按一定的规律排列,尽量避免采用容易混淆的英文字母和数字字符作为变量标识符，如英文字母o和数字0、英文字母I、l和数字1等。
    (6) 语句代码要简单，直接，清晰，不要追求奇特怪巧的“技术”。
    (7) 避免过多的循环或条件嵌套，避免复杂的条件测试。一般情况下逻辑运算“非”总令人头痛一些。在多条件测试时，使用括号可增加条件测试的清晰性和可靠性。
    (8) 合理的对用户友好的输入输出格式。交互式I/O中，输入要有提示，并采用自由格式。输出语句要带有输出值的说明，格式要整齐，美观。
    (9) 不要修补结构不好的程序，要忍痛割爱，从新编写。
================================================================
以上出自：http://ee.sjtu.edu.cn:8080/os/lab1.asp

当然，我不否认有些人很天才，过程方法对他来说足够了，甚至他只需要0101的？键盘的键太多了，雨人一定能够做到。

140 楼 GaryHe 2008-08-28  

没办法,谁让猴子在这个世界上称了霸，老虎豹子再有本事，也只有关在笼子里被人养活了。

139 楼 hax 2008-08-28  

希望T1大人还是回到正题上，不要继续搅和到诡辩中了。

138 楼 hax 2008-08-28  

python 写道

貌似又回到当年java vs c的年代。两种方式，不管是OO还是FP，仅是人处理事物的方法与世界观，再扯点就是哲学。

本质上都是为了解决人与机器交流的问题，到哪天，机器可以自然理解人类语言，我想这种争论就会销声匿迹

你丫占了个不错的id，说出来的话咋那么没劲。赶紧删了吧。管理员最好连我这篇一起删。

BTW，哲学就是用来给你们“扯”乎的啊。别没事就拿“哲学”当马桶。

137 楼 hax 2008-08-28  

sungine 写道

大师们 。。。。停一下！！！
您们觉得  用科学（或数学、诺依曼等等）来证明哲学（形而上、oo等等）有意义么？？
有位磨眼睛片的哲学大师曾用几何论证的方式证明过哲学。。可他毕竟没能完全解释世界（他的理论基础是我思故我在）
还有位疯掉的哲学大师不相信理性的推论，结果也没能完全解释世界。
无论是数学能证明哲学还是不能证明，都有人为此付出了一生。。。
您们还是继续讨论OO 和 诺依曼的问题吧，这个比较容易出成果。。 我会很认真的拜读 各位大师的文笔。。。

我以我那差点被退学的哲学学士的学历跟大家保证：

他们讨论的不是哲学，而是某人在诡辩。

136 楼 hurd 2008-08-26  

gigix 写道

lyl0035 写道

为啥就没人想想，其实在面向对象的代码中也流露着面向过程的思想，同时在面向过程的代码中也多少受到一些面向对象的影响。
虽然Linux是用C写的，但是其中一些代码的设计确实体现了OOP的思想，只不过形式上还是C罢了。

回帖之前要看帖

inshua 写道

近来读了一下 SICP，我感觉 oo 和 fp 本质上是同一的，一个对象实际上就是一个闭包。

闭包这东西和IO monad以及pure Function没什么关系吧？？？

135 楼 python 2008-08-26  

貌似又回到当年java vs c的年代。两种方式，不管是OO还是FP，仅是人处理事物的方法与世界观，再扯点就是哲学。

本质上都是为了解决人与机器交流的问题，到哪天，机器可以自然理解人类语言，我想这种争论就会销声匿迹

134 楼 gigix 2008-08-25  

lyl0035 写道

为啥就没人想想，其实在面向对象的代码中也流露着面向过程的思想，同时在面向过程的代码中也多少受到一些面向对象的影响。
虽然Linux是用C写的，但是其中一些代码的设计确实体现了OOP的思想，只不过形式上还是C罢了。

回帖之前要看帖

inshua 写道

近来读了一下 SICP，我感觉 oo 和 fp 本质上是同一的，一个对象实际上就是一个闭包。