oop - OOP 范式在真正复杂的系统中的局限性？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




我之前问过一个关于 Dataset vs Business Objects 的问题
.NET Dataset vs Business Object : Why the debate? Why not combine the two?

我想在这里概括一下这个问题:OOP 真的适用于非常复杂的问题的证据在哪里？让我们以 MMO 游戏引擎为例。我根本不是专家，但当我阅读这篇文章时，它显然表明 OOP 远远不够:

http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/

它得出结论:
使用实体系统进行良好的编程与使用关系数据库进行编程非常接近。将 ES 称为“面向关系编程”的一种形式并非没有道理。

那么 OOP 是不是试图摆脱一些留在这里的东西？

OOP 是非线性的，Relational 是线性的，两者都是必要的，具体取决于系统的一部分，所以为什么要尝试消除 Relational，因为它不是“纯”对象。 OOP 本身就是目的吗？

我的问题不是 OOP 有用。 OOP 很有用，我的问题是为什么纯粹主义者想要做“纯粹的”OOP？

Answer 1

作为链接帖子的作者，我想我会提出一些想法。

仅供引用:我在 1997 年开始认真地(即用于商业工作)使用 OOP/ORM/UML，恕我直言，我花了大约 5 年的日常使用才真正擅长它。到那时，我已经用 ASM 和非 OOP 语言编程了大约 5 年。

这个问题的措辞可能不完美，但我认为这是一个很好的问题，问问自己并进行调查——一旦你理解了如何更好地表达它，你就会学到很多关于这一切如何联系在一起的有用信息。

“那么，OOP 是不是试图摆脱一些留在这里的东西？”

首先，在这里阅读 Bjarne 的论文:http://www.stroustrup.com/oopsla.pdf

恕我直言，没有人应该在没有阅读那篇论文的情况下学习任何 OOP(并在他们“学习”OOP 后重新阅读)。很多人都误解了他们在处理什么。

IME，很多大学类(class)都没有教好OOP；它们教人们如何编写方法和类，以及如何使用对象。他们教的很差，为什么你会做这些事情，想法来自哪里，等等。我认为很多误用来自:几乎是盲人引导盲人的案例(他们在“如何”方面并不盲目使用 OOP，他们只是不知道“为什么”使用 OOP)。

引用论文的最后几段:

“你如何支持好的编程技术和好的设计技术比标签和流行语更重要。基本思想只是通过抽象来改进设计和编程。你想隐藏细节，你想利用系统中的任何共性，你想让这个负担得起。

我想鼓励你不要让面向对象成为一个毫无意义的术语。 “面向对象”的概念经常被贬低:
– 把它等同于善，
– 将其等同于一种语言，或
– 接受一切都是面向对象的。

我认为，除了面向对象的编程和设计之外，还有——而且必须——有用的技术。但是，为了避免被完全误解，我想强调的是，我不会尝试使用编程语言进行严肃的项目
至少不支持面向对象编程的经典概念。除了支持面向对象编程的工具外，我还希望——而且 C++ 提供的功能超出了它们对概念和关系的直接表达的支持。”

现在……我想问你……在你见过的所有 OOP 程序员和 OOP 项目中，有多少人可以诚实地声称已经遵守了 Bjarne 的要求？

IME，少于大多数。

Bjarne 指出:

“基本思想只是通过抽象来改进设计和编程”

...然而，许多人为自己发明了不同的含义，例如:

“基本思想是OOP是好的，不是OOP的一切都是低劣的”

使用 ASM 顺序编程的程序员，然后是 ASM，然后是 pascal，然后是 C，然后是 C++，并且已经接触到编程预封装等的困惑，往往对这些东西有更好的理解。他们知道为什么会出现 OOP，它试图解决什么问题。

有趣的是，OOP 并没有试图解决所有的编程问题。谁会想到它，说它今天是如何谈论的？

它针对的是少数问题，这些问题随着您的项目变得越来越大而变得非常危险，结果证明这些问题在解决方面介于“好”和“非常好”之间。

但即使是其中的一些，也只是“擅长”解决问题；还有其他范式更好......

恕我直言，当然;)