2025上半年,最新 AI实践都在这!20+ 应用案例,任听一场议题就值回票价 了解详情
写点什么

为什么有这么多开发者讨厌面向对象编程?

  • 2019-09-02
  • 本文字数:2524 字

    阅读完需:约 8 分钟

为什么有这么多开发者讨厌面向对象编程?

关于面向对象编程,有人喜欢它,也有人讨厌它。


面向对象编程(OOP)已经存在了很长时间。它是一种编码风格、一种思想流派、一种学校里的教授实践。它的核心思想是将代码组织成有意义的“对象”,这些“对象”是现实问题的模型,将描述模型各个“状态”的变量和修改这些变量的方法(子例程或函数)捆绑在一起。


面向对象编程思想与人们在现实世界中思考问题的方式是一致的。他们将代码组织成有意义的代码块,这些代码块之间有着各种直接的关系。他们最终得到的是不同类型的对象,这些对象之间进行离散的交互,相互交换数据状态变更消息。


但在实践当中,有些批评者声称,OOP 并不总是这么回事。


Ilya Suzdalnitski 是这种“憎恨者”阵营的一员,他是一位高级全栈工程师,上个月发表了一篇 6000 字的文章(https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7),说 OOP 是“万亿美元的灾难”。而且事实证明,他并不是唯一一个有这种强烈感觉的人。在写完另一篇系列文章后,他发现,“这两篇文章在一个月内达到了 50 万的阅读量”。


Suzdalnitski 说,“OOP 没能把它本应该要解决的问题解决好”,反而把事情变得更加复杂。OOP 代码的变量及其可变状态“在不同的对象之间被随意共享”。


他在一封电子邮件中写道:“在大多数情况下,OOP 代码最终会变成带有全局状态的大泥团,任何人都可以随意修改它”。


Suzdalnitski 还认为,面向对象代码难以重构,也难以进行单元测试。他在文章中大胆宣称:“写出好的、可维护的面向对象代码很难……”


他写道:“程序员宝贵的时间和精力都花在思考‘抽象’和‘设计模式’上,而不是解决现实世界中的问题。”


Suzdalnitski 指出了 OOP 的另一个主要问题:并发。他在电子邮件中说:“OOP 生于单核 CPU 时代,那时的程序员不需要担心并发问题……而函数式编程(还有 Go 语言和 Rust 等)崛起的一个主要原因是它们能够有效地处理并发问题”。


他在文章最后指出,函数式编程将是更好的选择。函数式编程是 OOP 的竞争编程范式,在函数式编程中,问题不是被建模成对象,而是纯数学函数,并强调要避免让状态发生变化。三周后,Suzdalnitski 以欲扬先抑的讽刺性笔调发表了另一篇文章(《不要再尝试函数式编程了》),对函数式编程大加称道了一番。

读者的反应

Suzdalnitski 敢于挑战 OOP 编程范式的论调激起了其他开发者的强烈反应。Suzdalnitski 的第一篇文章在 Medium 上得到了 174 个回复,其中有一个来自德克萨斯州的软件工程师 Jesse Dickey,他说 OOP 这个名字本身就是一个错误。“你不是在用对象编程,而是用类。所以,你可以把它叫作面向类编程……”他后来补充说,更准确地说,类应该是“自定义类型”。


Suzdalnitski 第一篇文章的链接也出现在了 Reddit 的 10 个讨论话题中,开发者开始对哪种编程范式更好产生了尖锐的分歧——是函数式编程还是面向对象编程:


“我使用的是 OOP 语言,但却以 FP(函数式编程)的方式编写代码(大部分是 TypeScript)。函数和数据是相互独立的。与 FP 相比,重构一个混乱的 OOP 代码库简直是一场噩梦……”


“我研究了一下‘纯函数式编程’,但感觉这就是一场灾难,就像是在没有电子表格软件的情况下处理电子表格……”


很快,他们开始争论问题到底是该归咎于编程范式还是程序员本身。


“软件应该由普通程序员开发来开发,而不是精英程序员。如果你的编程范式或技术栈需要精英程序员,那么随着时间的推移,很可能会以失败告终,因为精英程序员很难留住……”


“OOP 倾向于让代码变得混乱,而函数式编程倾向于让事情变得尽可能清晰……”

作者的想法

面对读者的激烈反应,Suzdalnitski 作何感想?


Suzdalnitski 在邮件中写道:“我一生中的大部分时间都在编程。我获得的经验越多,就越开始意识到我以前写的代码有多糟糕,真的很糟糕。这些年来,我花了大量时间学习 OOP,但具有讽刺意味的是,我得到的回报非常少……”


即使是简单的功能也需要“大量时间”来实现,而且代码库越大,实现起来就越困难。


“问题越来越多,而且问题出现得越来越频繁”。


2014 年,Suzdalnitski 发现了 F#——微软在 2010 年发布的多范式编程语言。


“这门语言看起来很奇怪,但同时又很优雅……从那时候开始,函数式编程的想法一直萦绕在我脑海里”。

“危险的 OOP”

多年来,他开始将函数式编程思想应用到他的 C#代码中。随后,他所在的公司完成了向 JavaScript 的迁移。从那天起,“我非常努力地寻找 OOP 的使用场景,但从来没有找到过”。


“在使用非 OOP 语言时,比如 JavaScript,函数可以独立于对象存在。我们再也不用为了包含这些函数而去发明一些奇怪的概念(比如 SomethingManager),这真是一种解脱。”


这一切都让他相信“OOP 是危险的。OOP 程序固有的非确定性让代码变得不可靠”。程序在运行时会有很多不同的路径,因为会有很多不同的对象,而且会不断动态创建出新的对象。“这种看似无辜的编程范式对世界经济造成的破坏性影响是人们难以理解的”。


他知道他的观点会让一些人感到生气。但在文章浏览量达到 50 万之后,他有没有听到什么可以让他改变主意的东西,或者从另一个角度看问题呢?


Suzdalnitski 表示,“有一条评论引起了我的注意”。一个读者评论说,现在存在着一种制度潜流,这种潜流导致不断产生大量 OOP 程序员。“对于管理者来说,继续使用 OOP 是有道理的,因为廉价的 OOP 开发者遍地都是,很多应届毕业生都熟悉 OOP”。但 Suzdalnitski 认为他们最终会为此付出代价。或者,换句话说,“OOP 之所以流行,是因为廉价的 OOP 开发者随处可见,而函数式程序员通常更聪明、更贵……”


“当然,交付 OOP 产品通常需要更长的时间,不仅难以维护,而且由于 OOP 的非确定性,通常会有很多 bug”。


这也就是为什么 Suzdalnitski 开始在网上发表他的文章,因为“如果我能激励一千个人质疑 OOP 的好处,并尝试函数式编程,那么他们将会写出更好、更可靠的代码。”


他认为自己成功了,他的文章浏览量达到了 50 万,让世界走上了一条新道路。这条道路通往另一个世界,在这个新世界里,有更快乐的开发者、更快乐的用户和更省钱的公司……


英文原文:https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/


2019-09-02 07:3015072
用户头像

发布了 38 篇内容, 共 32.2 次阅读, 收获喜欢 208 次。

关注

评论 11 条评论

发布
用户头像
谈论这个问题就和讨论java和js哪个才是正确的编程语言一样 毫无意义
2019-11-25 10:20
回复
用户头像
“在使用非 OOP 语言时,比如 JavaScript,函数可以独立于对象存在。我们再也不用为了包含这些函数而去发明一些奇怪的概念(比如 SomethingManager),这真是一种解脱。”

这一切都让他相信“OOP 是危险的。OOP 程序固有的非确定性让代码变得不可靠”。程序在运行时会有很多不同的路径,因为会有很多不同的对象,而且会不断动态创建出新的对象。
2019-09-11 10:30
回复
用户头像
50万阅读量能说明什么问题呢?标题党也很容易吸引流量,这个文章有很大的标题党嫌疑。
2019-09-11 07:45
回复
用户头像
如果作者不贴出一些代码来横向比较,那么这种讨论就会陷入无意义的口水战、空对空。最好是是他自己写过的oo风格的代码和fp代码,如果是同一个问题的两种实现就更好。
可惜作者只是空谈了oo的一些问题,oo当然不是银弹,oo当然可能被误用或错用,不过更可能是不够oo。这只能靠具体代码和细微处的设计来判断,talk is cheap,show me the code。
如果作者展示出的oo代码显示其真的已经了解oo并能正确设计 却仍存在其声称的那些问题,那么这个抱怨才是有意义的。
2019-09-11 07:43
回复
用户头像
如果作者不贴出一些代码来横向比较,那么这种讨论就会陷入无意义的口水战、空对空。最好是是他自己写过的oo风格的代码和fp代码,如果是同一个问题的两种实现就更好。
可惜作者只是空谈了oo的一些问题,oo当然不是银弹,oo当然可能被误用或错用,不过更可能是不够oo。这只能靠具体代码和细微处的设计来判断,talk is cheap,show me the code。
如果作者展示出的oo代码显示其真的已经了解oo并能正确设计 却仍存在其声称的那些问题,那么这个抱怨才是有意义的。
2019-09-11 07:42
回复
用户头像
作者的论述十分的片面,在他的认知里可能函数式编程比面向对象编程更能实际解决他的业务需求,也更贴近他的编程习惯。但是不要忘了,世界上还有很多初级程序员,操着if ... else ... 大刀来编码,动辄单个方法两三百行,写着完完全全命令式的代码,OOP难道不比这些程序员写出来的代码好?
然而作者并没有明确表示或者在含糊其辞:我只是在讨论OOP和FP两种编程方式的差异。他是一棍子打死了OOP,大量地否定了这种良好的编码方式,从而误导大量的初级程序员抱着侥幸心理而不去了解和学习
2019-09-08 12:59
回复
用户头像
面向对象被实践证明是适合软件工程的,可以用来构建复杂项目啊。只是所有类构成的系统对于程序员来说是个很沉重的学习包袱,需要清晰的了解才知道到底用哪个类效率最高。而且派生层级越多的子类所带的数据成员越多,很多都是无用的也会被初始化,很多内存是浪费的。所以面向接口编程也有自身的优势,也曾被称为Better C++。函数式编程我不太了解,不过我觉得所有的编程范式应该融合使用,即使是OOP里成员函数的实现不还是结构化程序设计吗。
2019-09-02 17:21
回复
用户头像
很多人都喜欢基于自己的认知来概括事物的全貌,对,说的就是盲人摸象。

函数式编程当然有用,尤其越简单的场景,越适用。
而面向对象,天生就是用来解决复杂系统的构建的。通过解耦、抽象、多态、封装,从对象化、组件化、构件化的角度将大的系统分解重用。
2019-09-02 08:45
回复
微服务在某方面来讲,是可以大大降低大型复杂系统code部分的难度的,把复杂转移给PAAS,中间件团队等。 code应该越简单越好。 个人理解。
2019-09-02 14:25
回复
个人觉得如果只是为了简单 就不要搞微服务 因为微服务又会带来很多额外的问题
2019-11-25 10:18
回复
用户头像
严格地说讨厌的是“基于类的编程”,对,婊的就是你,Java
2019-09-02 08:21
回复
没有更多了
发现更多内容

KeilC51基础 利用仿真测试代码的运行时间

万里无云万里天

嵌入式 单片机 8051

KeilC51基础 生成可以下载到单片机的Hex文件

万里无云万里天

嵌入式 单片机 8051

AI时代:中美竞争,未来在孩子手中!

新消费日报

为什么单元测试不是持续交付的唯一答案

禅道项目管理

项目管理 DevOps 单元测试 自动化测试 持续交付

Mac密室逃脱游戏推荐:Escape Simulator for mac安装包

你的猪会飞吗

Mac游戏下载 Mac电脑软件

六月的魔力:揭秘2024年加密市场与Reflection的创新与收益

BlockChain先知

《神经网络设计》PDF

程序员李木子

鸿蒙笔记 helloworld(Java)

万里无云万里天

鸿蒙系统 DevEco Device Tool

硬件加倍,性能翻番!TDengine 线性扩展能力测试全解析

TDengine

数据库 tdengine 时序数据库

华为云技术专家硬核分享,云原生中间件如何加速业务发展

华为云开发者联盟

云原生 中间件 华为云 华为云开发者联盟 企业号2024年7月PK榜

办公神器小浣熊:有你我怎能不摸鱼

知识浅谈

AI AIGC 办公小浣熊

VSPD9.0基础 建立一对互联的虚拟串口,进行串口通信的测试

万里无云万里天

虚拟化 串口通信 VSPD

深度解读昇腾CANN多流并行技术,提高硬件资源利用率

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号2024年7月PK榜

KeilC51基础 改变代码的字体大小

万里无云万里天

嵌入式 单片机 8051

KeilC51基础 添加与删除中文时出现问号

万里无云万里天

嵌入式 单片机 8051

2024年6月文章一览

codists

编程人

基于STC89C52+PulseSensor心率传感器检测心率实时显示

DS小龙哥

7月月更

鸿蒙再进化,原生游戏商用化进程加速

最新动态

经验整理 Datawhale-23期数据挖掘-心跳信号分类预测

万里无云万里天

人工智能 数据挖掘

经验整理 神经网络基础知识

万里无云万里天

人工智能 神经网络

鸿蒙笔记 下载和安装DevEco Studio

万里无云万里天

DevEco Studio 鸿蒙系统

我在中东做MCN,月赚10万美金

自象限

如何在 Spring Boot 中开发一个操作日志系统

网罗开发

Java’ 企业号 6 月 PK 榜

认证总结 北京业余无线电台A类

万里无云万里天

通信 无线电

经验整理 小甲鱼Python

万里无云万里天

Python 经验分享

为什么有这么多开发者讨厌面向对象编程?_语言 & 开发_David Cassel_InfoQ精选文章