OOP的重大挑战者

Question

据我所知，OOP是大型项目最常用的范例。我也知道大型系统的一些较小子集使用其他范例（例如SQL，它是声明性的），我也意识到在较低级别的计算中OOP并不可行。但在我看来，通常更高级别的解决方案几乎总是以OOP方式组合在一起。

是否存在真正的非OOP范例实际上是大型解决方案的更好选择的情况？或者这些日子闻所未闻？

自从我开始学习CS以来，我一直在想这个;很容易让人觉得OOP是一种永远无法超越的编程必杀技。

Answer 1

在我看来，OOP如此广泛使用的原因并不是因为它是适合这项工作的正确工具。我认为可以通过他们理解的方式向客户描述解决方案。

CAR是一辆拥有发动机的车辆。那就是编程和现实世界！

很难理解任何能够很好地适应编程和现实世界的东西。

Answer 2

Linux是一个非常不是OOP的大型项目。它也没有太大的收获。

我认为OOP对它有很好的响应，因为它与良好的编程实践相关联，如封装，数据隐藏，代码重用，模块化等。但是这些优点绝不是OOP特有的。

Answer 3

你可以看一下由Joe Armstrong编写的Erlang。

维基百科：

  

“Erlang是一个通用的目的   并发编程语言和   运行时系统。顺序子集   Erlang是一种函数式语言，   严格评估，单身   分配和动态类型。“

Joe Armstrong：

  

“因为问题所在   面向对象的语言是他们的   得到了所有这种隐含的环境   他们随身携带。您   想要一个香蕉，但你得到的是一个   大猩猩拿着香蕉和   整个丛林。“

Answer 4

OOP的承诺是代码重用和更容易维护。我不确定它是否已经发布。我认为像dot net这样的东西与我们过去各种供应商的C库非常相似。如果需要，可以调用该代码重用。至于维护坏代码是坏代码。 OOP没有帮助。

Answer 5

我是OOP的最大粉丝，我每天都在练习OOP。 这是编写代码最自然的方式，因为它类似于现实生活。

尽管如此，我意识到OOP的虚拟化可能会导致性能问题。 当然，这取决于您的设计，您选择的语言和平台（使用基于垃圾收集的语言（如Java或C＃）编写的系统可能比使用C ++编写的系统更糟糕）。

我想在实时系统中，程序编程可能更合适。

Answer 6

请注意，并非所有声称为OOP的项目实际上都是OOP。有时大多数代码都是程序性的，或者数据模型是anemic，依此类推......

Answer 7

Zyx，你写道，“大多数系统使用关系数据库......”

我担心没有这样的事情。关系模型明年将有40年历史，至今仍未实施。我认为你的意思是“SQL数据库”。您应该阅读Fabian Pascal的任何内容，以了解关系dbms和SQL dbms之间的区别。

“......关系模型通常因其受欢迎程度而被选中，”

是的，它很受欢迎。

“......工具的可用性”，

没有必要的主要工具：关系模型的实现。

“支持”，

是的，关系模型有很好的支持，我敢肯定，但它完全不受dbms实现的支持。

“以及关系模型实际上是一个数学概念，”

是的，这是一个数学概念，但是，没有实施，它主要局限于象牙塔。字符串理论也是一个数学概念，但我不会用它实现一个系统。

事实上，尽管它是一个数学概念，但它肯定不是一门科学（如计算机科学），因为它缺乏任何科学的第一要求：它是可证伪的：我们没有实现关系数据库可以检查它的说法。

这是纯蛇油。

“......与OOP相反。”

与OOP相反，关系模型从未实现过。

购买一本关于SQL的书并提高工作效率。

将关系模型留给非生产性理论家。

Answer 8

请参阅this和this。显然你可以使用C＃和五种不同的编程范例，C ++和三种等等。

软件构建与基础物理学不同。物理学试图用可能受到新实验数据和/或理论挑战的范式来描述现实。物理学是一门科学，它以软件构造所不具备的方式搜索“真理”。

软件构建是业务。您需要高效，即实现某些人付钱的目标。使用范例是因为它们对有效地生成软件非常有用。你不需要每个人都同意。如果我做OOP并且它对我来说效果很好，我不关心如果我有时间和金钱来学习它并且稍后重新思考整个软件结构，那么“新”范例对我来说可能会有20％的用处。我正在从事工作并从头开始重新设计。

另外，你可能正在使用另一种模式，我仍然会感到高兴，就像我可以在日本料理餐厅赚钱一样，你可以在隔壁的墨西哥餐厅赚钱。我不需要和你讨论日本食物是否比墨西哥食物更好。

Answer 9

我怀疑OOP很快就会消失，它恰好适合我们的问题和心理模型。

我们开始看到的是多范式方法，其中声明性和功能性思想被纳入面向对象的设计中。大多数较新的JVM语言都是这方面的一个很好的例子（JavaFX，Scala，Clojure等）以及.net平台上的LINQ和F＃。

重要的是要注意，我不是在谈论在这里替换OO，而是在补充它。

• JavaFX已经证明了一个声明性的 解决方案超越了SQL和XSLT， 并且还可以用于绑定 视觉之间的属性和事件 GUI中的组件

• 对于容错和高度 并发系统，功能 编程非常适合非常 正如爱立信所展示的那样 AXD301（使用Erlang编程）

所以......随着并发性变得越来越重要，FP越来越受欢迎，我想不支持这种范式的语言会受到影响。这包括许多目前流行的，如C ++，Java和Ruby，尽管JavaScript应该很好地处理。

Answer 10

使用OOP使代码更易于管理（如在修改/更新/添加新功能中）并理解。对于更大的项目尤其如此。因为模块/对象将数据和操作封装在该数据上，所以更容易理解功能和全局。

OOP的好处是（更容易与其他开发人员/管理人员/客户）讨论LogManager或OrderManager，每个都包含特定功能，然后描述“一组将数据转储到文件中的方法”和'跟踪订单详情的方法'。

所以我认为OOP特别适用于大型项目，但总会有新的概念出现，所以请继续留意新的东西，评估并保留有用的东西。

Answer 11

人们喜欢将各种事物视为“物体”并对其进行分类，因此毫无疑问，OOP如此受欢迎。但是，有些领域的OOP并未获得更大的人气。大多数系统使用关系数据库而不是客观数据库。即使第二个记录具有一些值得注意的记录并且对于某些类型的任务更好，但由于其受欢迎程度，工具的可用性，支持以及关系模型实际上是数学概念这一事实，因此关系模型是不可选择的。 OOP。

我从未见过OOP的另一个领域是软件构建过程。所有配置和make脚本都是程序性的，部分原因是由于在shell语言中缺乏对OOP的支持，部分原因是OOP对于此类任务而言过于复杂。