OOP的重要挑战者

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

对于大规模的解决方案，是否存在真正的非OOP范式实际上是更好的选择的场景？或者这是最近闻所未闻的

---

自从我开始学习计算机科学以来，我就一直在想这个问题；很容易让人感觉到OOP是编程的天堂，永远不会被超越。

在我看来，OOP被广泛使用的原因并不在于它是工作的正确工具。我认为更重要的是，可以用客户理解的方式向客户描述解决方案

汽车是一种有发动机的车辆。这是编程和现实世界的结合

---

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

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

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

---

所以我想OOP是很有帮助的，尤其是在大型项目中，但总是会有新的概念出现，所以在未来要不断寻找新的东西，评估并保留有用的东西。

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

不过，我意识到OOP的虚拟化可能会导致性能问题。 当然，这取决于你的设计、语言和你选择的平台（以垃圾收集为基础的语言编写的系统，如java或C++）可能比用C++编写的系统更糟糕。p>

---

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

请注意，并非所有声称是OOP的项目实际上都是OOP。有时大部分代码都是过程性的，或者数据模型是，等等……

Linux是一个大型项目，它不是OOP。它也不会从中获得很多好处

---

我认为OOP有一个很好的环，因为它与良好的编程实践相关联，如封装、数据隐藏、代码重用、模块化等。但这些优点绝非OOP所独有。

OOP的承诺是代码重用和易于维护。我不确定它是否送达。我认为像dotnet这样的东西与我们过去从不同供应商那里得到的C库非常相似。如果需要，可以称之为代码重用。至于维护，坏代码就是坏代码。OOP没有帮助。

人们喜欢将各种事物视为“对象”，并对它们进行分类，因此，毫无疑问，OOP非常流行。然而，OOP在某些领域并没有得到更大的普及。大多数系统使用关系数据库而不是目标数据库。即使第二个模型有一些显著的记录，并且对于某些类型的任务来说更好，但由于其流行性、工具的可用性、支持以及关系模型实际上是一个数学概念（与OOP相反）这一事实，选择关系模型也是不明智的

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

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

恐怕没有这种事。关系模型明年将有40年的历史，至今尚未实现。我想你的意思是“SQL数据库”。你应该阅读Fabian Pascal的任何文章来理解关系数据库管理系统和SQL数据库管理系统之间的区别

“…通常选择关系模型是因为它很受欢迎，”

没错，它很受欢迎

“…工具的可用性，”

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

“支持，”

是的，我确信关系模型有很好的支持，但是dbms实现完全不支持它

关系模型实际上是一个数学概念

是的，这是一个数学概念，但由于没有得到实施，它主要局限于象牙塔。弦论也是一个数学概念，但我不会用它来实现一个系统

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

这是纯蛇油

“…与OOP相反。”

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

买一本关于SQL的书，就可以提高工作效率

将关系模型留给没有生产力的理论家。

参见和。显然，你可以使用五种不同的编程范式C，三，C++等。 软件构造与基础物理并不相似。物理学努力用可能受到新实验数据和/或理论挑战的范式来描述现实。物理学是一门寻找“真理”的科学，而软件构造则不然

软件建设是一项业务