不要误解我的意思 - OOP目前是构建大型代码库的最佳选择。
但为什么人们试图将任何填入OO视图？
例如：每本关于OOP的教科书都包含一个“介绍示例”，它试图在OO继承和组合和聚合构造中表达我们现实世界的一个小视图。并且 - 同时 - 我们都知道它永远不会导致OO模型本身承诺的全能OO结构！作者刚刚创造了一种幻觉。
我个人认为，OO很适合构建代码，但不适合表示现实世界数据及其关系。恕我直言，关系模型是优越的，可能任何其他模型都是优越的。
在OO设计中，尽可能推荐构图而不是继承。因此，一流图书所暗示的基于全继承的世界对象的强大外观模型只是一种幻觉。那么，OO本身可能是一种幻觉？当前以组合为中心的OO模型只不过是具有一些标准化语法糖的普通数据结构 - 与OOP前方法没有太大区别。
另一个例子：想象一下真实复杂的现实世界模型。除此之外，还有石块和人类。在OO模型中，人类是哺乳动物，动物是有机生命形式等等（严格的刚性继承等级OO强加，你知道......）。石块是非有机的东西，也许它们是刚体或其他什么，没关系。
如果你是一名艺术家而且你必须找到一块石块，它可以为一个人的雕像制作一个好的“模板”（？），给定宽度，高度和厚度，那么你必须写一堆特殊情况OO代码从人体模型和石块模型中检索这些属性。或者，您的整个世界模型都是为了支持几何查询而构建的 - 那么它很容易！但这导致得出的结论是 OOP以表示数据的方式很糟糕，允许我们在不同的用例中使用它。 OOP只允许我们准确地表示我们事先设计的用例数据。不多了。除了那些预先确定的情况之外的任何使用只能通过大量的小问题来完成。 关系模型至少试图以可重用的方式表示数据。（可重用：OOP曾经占用过那个词）
为什么所有人都讨厌？
我在使用ORM的项目上工作 - 而且它很糟糕。它是在对数据库进行建模时开始的（由于ORM限制），然后是时候学习ORM的来龙去脉（以及它的错误和进一步的限制），然后害怕隐含发生的东西（新东西（）;东西 - ＆gt; save（）创建一个新行，但是“东西”在哪里扎根？为什么人们试图尽可能地使对象“独立”，但在后面创建了更加根深蒂固的依赖于每个表格的怪异，与连接单身人士沟通..哦，我的上帝..我离题了。）
在几行SQL和一个甜蜜的小查询API中可以完成的许多事情都是在数百甚至数千行“业务逻辑”代码中完成的（当然在应用程序层中，而不是在数据库中）数据所在的位置，以及count（）或sum（）等聚合函数的便宜性。我认为人们在OOP工作时会感觉更好。但这只是愚蠢的。
ORM的创建者只想让用户远离“肮脏的东西”。但正是这些人不应该写ORM - 完美的例子：我坚信ORM创建者类型的人甚至不知道数据库表可以包含复合主键！ ; - ）
那么，为什么OOP如此占领？这只是一个半生不熟的抽象，但是人们会对它发誓，如果你问一些，他们甚至可能会告诉你OOP会创造世界和平。
为什么OOP如此占领/垄断呢？
答案 0 :(得分：2)
在我看来，如果您的业务逻辑实现正在推动数据库的设计，那么有人会把这个推车放到马前。我认为这个想法是开发一个理性的（不，我没说关系）数据模型，然后实现任何逻辑查询并更新数据。
我的经验是，尽管关系数据库非常适合从用户的角度存储和查询数据，但尝试将关系模型扩展为结构化编程或OOP范例是极其困难的。总有一个翻译层。今天大家都认为ORM就是解决方案。虽然从技术上讲，位于关系数据存储和面向对象数据访问层之间的任何转换层都是ORM，但是当我看到人们谈论ORM时，他们似乎在谈论生成该ORM层的一些自动方式。
我不相信存在广义的ORM解决方案。我见过的每一个人都充满了危险。这是一个痛苦的脖子，但我见过的唯一可靠的ORM层是手工编码。当然，在过去五年左右的时间里，我对数据库的工作并没有那么多，所以事情可能已经发生了变化。
我同意你的看法，OOP主要是围绕一个坚固的结构化设计的大量语法糖。然而，它是好的语法糖。它规范了许多在结构化编程中被认为是“最佳实践”的东西，并添加了一些在纯结构化语言中很难或不可能表达的东西（继承，接口，多态等）。我们当然可以将一些或所有这些功能添加到结构化语言中而不必一直到OOP，但为什么呢？ OOP是程序编程语言演变的明显下一步。
答案 1 :(得分：0)
OOP只是工具箱中的另一个工具，但请记住，OO已经成为主流编程语言20多年来的焦点 - 从C ++开始，转向Java和C＃。这可能更多地与为什么模型目前“占据”而不是其他任何东西有关。
答案 2 :(得分：0)
OOP的观点不一定代表世界上每一个物体的每一个方面。重点是代表你关心的东西。例如，假设有一所房子。做房地产的人会关心地点，售价等。建筑商可能会关心蓝图ID或其他东西，我不知道。关键是，你为重要的东西建模并忽略其余的东西。如果您发现需要更多信息，请稍后再添加。
是的，这使得“House”课程适合正在构建的应用程序，并且可能不适合其他人。 OOP的总体目标不是重用类，尽管有时会发生这种情况。关键是将数据与可能影响该数据的操作捆绑在一起，从而在概念上将问题从数百个变量和函数减少到具有已知和测试的接口和相关行为的少数对象。
答案 3 :(得分：0)
Human和StoneBlock都应该继承MaterialObject，它具有高度宽度和深度属性，甚至在给定另一个MaterialObject时实现更大的Than（）方法。
答案 4 :(得分：0)
我几乎认为你的问题是虚伪的，但后来认为它缺乏经验（不是故意侮辱，只是从问题/断言中猜测）。您会发现存在如此复杂的问题，以至于OO是唯一可行的建模方法。并非所有内容都是数据库支持的网站或报告工具。许多系统主要是“业务逻辑”，其中最佳解决方案是OO解决方案（根据我的经验示例：控制和监控机器人飞机及其各种有效载荷）。话虽这么说，许多流行的数据库支持的Web框架是OO + RDBMS（Rails，Grails，Java + Spring + Hibernate等），因为它的组合非常强大。
虽然肯定有时尚和粘性但过时的范式，但我建议当有很多选择（面向对象，函数编程，以RDBMS为中心等）时，人们几乎总是选择最有效率的东西。至少10年来，这对于大部分软件问题都是OO。
答案 5 :(得分：-1)
因为在一天结束时，这是我们自己塑造事物的方式的一个很好的近似。经常提到的计数器是计算机没有对象的概念，它只是1和0，但是分析是空的，因为所有的人类思想只不过是神经元和电脉冲（它可能是，但它是只是不是一种看待事物的有用方式。）
所以你不喜欢继承？我也不做。行为的继承是穷人的代码重用。另一方面，接口的继承很好，因为它给我们带来了多态性。
你不喜欢ORM吗？没有人强迫你使用它们。 OOP和RDMS之间存在冲突，我认为不容易修复，大多数ORM尝试解决这个问题都很天真。 ORM的局限性不是OOP中的缺陷。