oop - 为什么面向对象模型如此占据/垄断？

Question

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




10年前关闭。




不要误会我的意思 - OOP 目前是构建大型代码库的最佳选择。

但是为什么人们要尝试填充任何事情进入 OO View ？

例如:每本关于 OOP 的教科书都包含一个“介绍示例”，它试图在 OO 继承、组合和聚合构造中表达我们对现实世界的一个小看法。而且 - 同时 - 我们都知道它永远不会导致 OO 模型本身 promise 的全能 OO 构造!作者只是制造了一种错觉。

我个人的观点是，OO 对代码结构很好，但它是 不适合代表真实世界的数据 及其关系。恕我直言，关系模型更胜一筹，可能任何其他模型都更胜一筹。

在 OO 设计中，推荐组合而不是继承已经成为惯例——只要有可能。因此，一流书籍建议的那种基于所有继承的对象世界模型看起来很强大，只是一种幻觉。那么，OO 本身可能是一种错觉？而当前以组合为中心的 OO 模型只不过是带有一些标准化语法糖的普通数据结构——这与 OOP 之前的方法没有太大区别。

另一个例子:想象一个我们现实世界的非常复杂的模型。除此之外，还有石块和人类。在 OO 模型中，人类是哺乳动物，动物是有机生命形式等等(OO 强加的严格严格的继承层次结构，你知道......)。石块是非有机物，也许是刚体什么的，都没有关系。

如果你是一个艺术家，你必须找到一个石块，它可以为一个给定宽度、高度和厚度的人类雕像制作一个很好的"template"(？)，那么你必须编写一堆特殊情况的 OO 代码来从人体模型和石块模型中检索这些属性。或者，您的整个世界模型是为支持几何查询而构建的 - 那么这将很容易!但这导致 的结论OOP 不擅长表示数据 以允许我们在不同用例中使用它的方式。 OOP 只允许我们准确地表示我们预先设计的那些用例的数据。不多了。除了那些预先确定的情况之外，任何使用都只能通过大量摆弄来完成。 关系模型至少尝试以可重用的方式表示数据。 (可重复使用:OOP 曾经甚至占用了这个词)

为什么这么讨厌？

我在一个使用 ORM 的项目上工作 - 它很糟糕。它开始于对数据库建模(因为 ORM 的限制)，然后是学习 ORM 的来龙去脉(及其错误和进一步的限制)的时候，然后是对隐式发生的事情的恐惧(new thing(); thing ->save() 创建一个新行，但是“东西”的根在哪里？为什么人们试图使对象尽可能“独立”，但在后面创建对每个表单例的根深蒂固的依赖，那与连接单例沟通.. 天哪.. 我离题了)。

很多本来可以用几行 SQL 和一个小巧的查询 API 完成的事情，却用数百甚至数千行“业务逻辑”代码完成(当然是在应用程序层，而不是在数据所在的数据库中)是，以及像 count() 或 sum() 这样的聚合函数会很便宜)。我认为当人们可以在 OOP 中工作时，他们会感觉更好。但这只是愚蠢的。

而 ORM 的创造者只是想让用户远离“肮脏的东西”。但正是那些人不应该写 ORM - 一个完美的例子:我坚信 ORM-creator 类型的人甚至不知道数据库表可以包含复合主键! ;-)

那么，为什么 OOP 如此占据优势呢？这只是一个半生不熟的抽象，但人们对一切都发誓，如果你问一些，他们甚至可能会告诉你 OOP 将创造世界和平。

为什么 OOP 如此他妈的占据/垄断？

Answer 1

在我看来，如果您的业务逻辑实现正在插入您的数据库设计，那么有人会把车放在马之前。我认为这个想法是开发一个合理的(不，我没有说关系)数据模型，然后实现任何逻辑查询并更新数据。

我的经验是，虽然关系数据库非常适合从用户的角度存储和查询数据，但尝试将关系模型扩展到结构化编程或 OOP 范式中是非常困难的。总有一个翻译层。今天每个人都认为 ORM 是解决方案。虽然从技术上讲，位于关系数据存储和面向对象的数据访问层之间的任何转换层都是 ORM，但当我看到人们谈论 ORM 时，他们似乎在谈论生成该 ORM 层的某种自动化方式。

我不相信存在通用的 ORM 解决方案。我见过的每一个人都充满了危险。这是一个令人头疼的问题，但我见过的唯一可靠的 ORM 层是手工编码的。诚然，在过去五年左右的时间里，我在数据库方面的工作并不多，所以情况可能已经发生了变化。

我同意你的看法，OOP 在很大程度上只是围绕一个坚实的结构化设计的大量语法糖。但是，它是很好的语法糖。它形式化了许多在结构化编程中被认为是“最佳实践”的东西，并添加了一些在纯结构化语言中很难或不可能表达的东西(继承、接口(interface)、多态等)。我们当然可以将部分或全部这些特性添加到结构化语言中，而无需一直使用 OOP，但为什么呢？ OOP 显然是过程式编程语言发展的下一步。