面向对象的编程范式由于反模块化和反并行性而过时了吗？[关闭]

我已经读过CMU教授罗伯特·哈珀（Robert Harper）发表的有争议的文章《向新生学习FP》。他声称CMU将不再在入门课程中教授面向对象的编程，因为它“不适合现代CS课程”。

他声称：

面向对象的编程从入门课程中就完全消除了，因为它的本质是反模块化的和反并行的。

为什么将OOP视为反模块化和反并行的？

请考虑，哈珀教授CS入门课程的需求与现实生活项目的需求有很大不同。他的工作是向新生传授基本概念（例如，模块化，并行性，归纳法）。因此，非常重要的一点是，所选择的语言（和范式）可以尽可能少地使用仪式（句法和概念）来表达这些概念。在这种情况下，熟悉程度，工具支持，可用的库，执行性能等都是完全无关的。因此，在考虑以下内容时，请记住这一点...

OO是反模块化的观点是由于对其他类的大量依赖关系导致的，即使设计良好的类的对象往往最终也会失败。当您查看过去几年依赖注入框架，文章，书籍和博客文章的泛滥时，即使在OO的支持者的眼中，这也是一个问题，这一点变得很清楚（模拟和存根的兴起也很有趣）。

另一个提示是设计模式的重要性以及实现它们的复杂性（与其他编程范例相比），例如工厂，构建器，适配器，桥，装饰器，外观，命令，迭代器，介体，观察者，策略和模板方法，也许Composite在某种程度上与提高OO代码的模块化有关。

继承也存在问题（例如脆基类问题）和（亚型）多态性情愫一个溢出的向上多个类，其中的变化可以通过整个继承链纹波之间的算法的实现（向上和向下！）。

与计算（又称为可变性与不变性）相比，反并行的指控与状态的强调有关。前者使人们更难以表达子计算的依赖性（这是Harper的并行性！），因为通常无法从状态的管理位置（也就是声明实例变量的文件）推断出外部参与者会在什么时候改变它。

对不变性和计算的强调使子计算的依赖关系表达更加容易，因为没有状态管理，只有函数/计算在要表达子计算的依赖关系的位置组合在一起。

这可能是一个大胆的主张，但是我有点怀疑，这个罗伯特·哈珀从未真正写过真正的软件。他似乎只关心ML和静态类型系统。尽管可能有这么大的贡献，但我看不出他关于OOP的主张如何具有相关性。

本文没有争议。争议涉及审查，辩论和讨论。您在这里所遇到的是一些无知的学者，他们在一个陈述中就提出了两个非常基本的指责，而又不愿提出任何论据。

1. 关于OOP是反模块化的说法完全是胡说八道。我什至不知道该如何响应，不仅没有提供任何参数，而且设计上的OOP 是一种通过封装和抽象的方式在各个模块之间建立非常低耦合的模块化方法。

2. 声称OOP是反并行的，这表明缺乏了解。OOP不会锁定任何有关并发的决定。OOP仅指示隐藏它们：如果构建正确，则不能说对象的实现是否并行。
   因此，最终OOP和并行编程是正交的。actor模型是一种优雅的并发模型，可以直接反映在对象系统中（但不必如此），从而将两者强大地结合在一起。

OOP的问题在于，很少有人真正理解Alan Kay定义它的含义。

1. OOP是一种方法。在某些语言中，它是使用模式实现的，而在另一些语言中，您可以直接使用内置的语言习语（例如Ruby，Objective-C，Smalltalk，Io）。
2. 与通常的看法相反，OOP与类无关。它与对象有关，而对象与消息传递或封装和抽象的非泄漏方式有关。

这就是Java对OOP为何指尖对海战的原因。对于许多其他所谓的“ OOP语言”也是如此，但是关于Java的事情是，在大学中，人们普遍认为应该使用Java来教授OOP。

我同意那些应该从CS课程中删除使用Java进行OOP的介绍的人的观点。我还认为，显然对OOP缺乏基本了解的人不应该教它。因此，如果Bob坚持学习ML并简单地讲授自己具有扎实的知识，那可能会更好。
目前，OOP更像是一种时尚的礼节，人们喜欢坚持一切。人们说，这伤害了OOP。OOP并不落伍。当人们最终了解它到底是什么而不是什么时（例如，通过使用关键字class500次来解决所有可能的问题），OOP的黄金时代尚未到来。

您会看到每一个条纹的狂热者。

面向对象编程不是万灵丹。从来没有。这是炒作的受害者。不可避免地，人们会厌倦炒作，并开始产生强烈的反响（无论该范式的实际用途如何）。

从现在起的二十年里，毫无疑问，我们还会对功能编程产生其他抵制。

我不能完全回答这个问题，因为一个人只能猜测其作者的模糊思想。我强烈怀疑这篇文章将使它的作者感到尴尬。关于OOP的任何事情都不能表明它既不是模块化也不是并行的：

模块化：OOP的一个主要方面是它确实是模块化的（但是模块化在不同的上下文中意味着不同的东西）。因此，无论作者是在谈论泛化还是静态编程，他都是错误的。

并行化：关于并行编程，大多数框架都支持中断，线程化和现在适当的并行化，例如我们在.Net framework 4.0中看到的内容以及连接到它的OOP语言。

我怀疑作者已经成为时尚的受害者，因为人们误解函数式编程和OOP在使用上是互斥的。OOP语言中有一些功能样式，这些文献有充分的文档记录，例如，Oliver Sturm在该领域中已经发表过。

作者坚持认为，对于新生的程序员来说，OOP太难理解了，这可能是正确的-尽管鉴于CMU的入学要求，但我对此表示怀疑！与纯函数式语言相比，反模块化和反并行语句在狭窄的上下文中可能是正确的，但是几乎不能谴责整个范例（对于那些知道如何使用它的人来说似乎很好用）。

拟议的课程将在一个班级教授函数式编程，在另一个班级教授命令式（过程）编程，并在另一班级教授数据结构。一旦大一掌握了这三样东西，他/她就应该准备学习OOP。

我个人认为这太过分了，但是学者们喜欢尝试新事物和极端事物。作为一种平衡，麻省理工学院曾经（并且可能仍然）在一个新生班上教授所有主要的编程范例。

奇怪的是，两所学校都产生了一些非常优秀的程序员。去搞清楚。