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

标签 oop orm

就目前而言,这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持,但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开,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 如此他妈的占据/垄断?

最佳答案

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

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

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

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

关于oop - 为什么面向对象模型如此占据/垄断?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3756807/

相关文章:

php - php 中的 oop 和 pdo 有问题

c# - 如何使用 Dapper 在客户端获取原始 SQL 错误消息?

java - 非法参数异常 : argument type mismatch in Hibernate

oop - 在哪里放置处理两个类之间关系的方法?

c++ - 在 C++ 类对象中初始化指向父类的静态指针

java - 实现接口(interface)和对象

javascript - 如何访问不同对象的属性?

java - JPA ORM XML 标签

java - 如何根据成员对象的字段值而不是成员对象ID获取实体

node.js - Sequelize HasMany 不起作用