代码之家 › 专栏 › 技术社区 › Frunsi

为什么面向对象模型如此占据/垄断?[闭门]

orm oop

Frunsi · 技术社区 · 7 年前

别误会——OOP目前是构建大型代码库的最佳选择。

但人们为什么要尝试塞满东西呢 任何东西 进入OO视图?

例如:每本关于OOP的教科书都包含一个“介绍示例”,试图用OO继承、组合和聚合结构来表达对现实世界的一个小视图。同时,我们都知道,它永远不会产生OO模型本身承诺的全能OO结构!作者们只是制造了一种错觉。

我个人的观点是,OO很好地构造代码,但它确实如此 不适合表示真实世界的数据 以及它的关系。无论关系模型是什么样的优越性,很可能任何其他模型都是优越的。

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

另一个例子:想象一个非常复杂的现实世界模型。除此之外,还有石块和人类 .在OO模型中,人类是哺乳动物,动物是有机生命形式等等(你知道,OO强加的严格严格的继承层次)。石块是非有机物,可能是刚体或其他什么,这无关紧要。

如果你是一名艺术家,你必须找到一块可以制作好“模板”的石头(?)对于具有给定宽度、高度和厚度的人类雕像,您必须编写一系列特例OO代码,以从人类模型和石块模型中检索这些属性。或者,你的全世界模型是为了支持几何查询而构建的——那就简单了!但这导致了一个结论 OOP不擅长表示数据 以允许我们在不同的用例中使用它的方式。OOP只允许我们精确地表示那些我们事先设计好的用例的数据。没什么了。除了那些预先确定的情况之外,任何用途都只能通过大量的摆弄来完成。 关系模型至少尝试以可重用的方式表示数据。 (可重复使用:OOP曾经占据过这个词)

为什么那么讨厌?

我在一个使用ORM的项目上工作,但它太差劲了。它始于对数据库建模(因为ORM的局限性),然后是了解ORM的细节(以及它的缺陷和进一步的局限性),然后是对隐式发生的东西的恐惧(新事物();事物->save()创建新行,但“thing”的根在哪里?为什么人们试图让对象尽可能地“独立”,但在背后却对与连接单例通信的每表单例产生了更根深蒂固的依赖。。哦,我的上帝。。我离题了)。

许多本可以在几行SQL和一个可爱的小查询API中完成的事情,都是在数百行或数千行“业务逻辑”代码中完成的(当然是在应用层,而不是在数据所在的数据库中,以及在像count()或sum()这样的聚合函数便宜的地方)。我认为当人们能够在OOP中工作时,他们会感觉更好。但这太愚蠢了。

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

那么,为什么OOP如此占人眼球?这只是一个半生不熟的抽象概念,但人们对它发誓,如果你问一些人,他们甚至可能会告诉你OOP将创造世界和平。

为什么OOP会占据/垄断市场?

6 回复 | 直到 15 年前

Jim Mischel 15 年前

在我看来,如果您的业务逻辑实现正在推动数据库的设计,那么就有人本末倒置了。我认为这个想法是开发一个rational(不,我没有说关系)数据模型,然后实现任何逻辑查询和更新数据。

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

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

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

Justin Ethier 15 年前

OOP只是工具箱中的另一个工具,但是要记住,OO现在已经成为主流编程语言的焦点,现在已经超过20年了——从C++开始,然后转到java和C语言。这可能与为什么该模型目前“如此占主导地位”有关,而不是其他任何因素。

cHao 15 年前

OOP的重点不一定是代表世界上每一个对象的每一个方面。重点是代表你所关心的东西。例如,假设有一所房子。从事房地产业务的人会关心位置、售价等。我不知道,建筑商可能会关心蓝图ID之类的东西。关键是,你对重要的东西建模,而忽略其他的。如果需要更多信息,请稍后添加。

是的,这使得“House”类适合正在构建的应用程序,可能不适合其他应用程序。OOP的总体目标不是重用类,尽管有时会发生这种情况。重点是将数据与可能影响该数据的操作捆绑在一起,从而从概念上将问题从数百个变量和函数减少到几个具有已知和已测试接口及相关行为的对象。

bukzor 15 年前

Human和StoneBlock都应该继承MaterialObject,MaterialObject具有高度、宽度和深度属性,甚至在给定另一个MaterialObject时实现一个biggerThan()方法。

SingleShot 15 年前

OO之所以“占位”,是因为它已被证明是解决许多编程问题的最佳选择。同样,对于许多数据存储和检索问题来说,关系模型也是一个很好的选择。当我说“很多”时,我的意思是“太多了,其他的都相形见绌”。事实上,两者结合在一起是一个很好的组合,但在映射这两种范式的交汇点时存在复杂性,因此ORM。

我几乎认为你的问题是不真诚的,但后来决定这是缺乏经验(不是故意侮辱,只是从问题/断言中猜测)。你会发现问题非常复杂,OO是唯一可行的建模方法。并非所有东西都是数据库支持的网站或报告工具。许多系统大多是“业务逻辑”,其中最好的解决方案是OO解决方案(根据我的经验,例如:控制和监控机器人飞机及其各种有效载荷)。尽管如此,许多流行的数据库支持的web框架都是OO+RDBMS(Rails、Grails、Java+Spring+Hibernate等),因为这种组合非常强大。

虽然肯定会有一些流行时尚和粘性但过时的范例,但我建议,当有很多选择(面向对象、函数式编程、以RDBMS为中心等)时,人们几乎总是选择最高效的。至少10年来,这在很大一部分软件问题上一直是面向对象的。

-1

CurtainDog 15 年前

因为归根结底,它很好地近似于我们自己建模的方式。对此经常提出的反驳是,计算机没有对象的概念,它们都是1和0,但这种分析是空洞的,就像说人类所有的思想都只是神经元和电脉冲一样(可能是这样,但这不是一种看待事物的有用方式)。

所以你不喜欢继承?我也是。行为的继承是穷人的代码重用。另一方面,接口的继承性很好,因为它提供了多态性。

你不喜欢吗?没有人强迫你使用它们。OOP和RDMS之间有一个冲突,我认为这不容易解决,大多数ORM试图解决这个问题都很幼稚。ORM的局限性并不是OOP中的一个缺陷。