我之前问了一个关于数据集与Business Objects .NET数据集与业务对象的问题:为什么要辩论？为什么不把两者结合起来？
我想在这里概括一下这个问题:OOP是否真的适合非常复杂的问题？我们以MMO游戏引擎为例.我根本不是专家,但在阅读本文时,显然OOP远远不够:
http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/
它的结论是:编程以及与实体系统是非常接近的编程关系数据库.将ES称为"面向关系编程"的形式并不是不合理的.
那么OOP是不是试图摆脱这里留下的东西？
OOP是非线性的,关系是线性的,两者都是必要的,这取决于系统的部分,所以为什么试图消除Relational只是因为它不是"纯粹的"对象.OOP本身就是目的吗？
我的问题不是OOP有用.OOP是有用的,我的问题是为什么纯粹主义者想要做"纯粹的"OOP？
作为链接帖子的作者,我想我会提出几点想法.
仅供参考:我在1997年开始认真地(即商业工作)使用OOP/ORM/UML,我花了大约5年的日常使用才能真正擅长恕我直言.到那时,我已经用ASM和非OOP语言编程了大约5年.
这个问题可能是不完美的措辞,但我认为这是一个很好的问题,可以自问和调查 - 一旦你理解了如何更好地表达它,你就会学到很多有用的东西.
"那么OOP是不是试图摆脱这里留下的东西？"
首先,请阅读Bjarne的论文:http://www.stroustrup.com/oopsla.pdf
恕我直言,没有人应该在不阅读那篇论文的情况下教授任何OOP(并在他们"学会"OOP后重新阅读).很多人误解了他们正在处理的事情.
IME,许多大学课程都不能很好地教授OOP; 他们教人们如何编写方法,类以及如何使用对象.他们很难教你为什么要做这些事情,这些想法来自等等.我认为很多错误的用法来自于:几乎是一个盲人领导盲人的情况(他们并不是盲目的"怎么样"到使用OOP,他们只是盲目"为什么"使用OOP).
引用该论文的最后几段:
"你如何支持优秀的编程技术和优秀的设计技术比标签和流行语更重要.基本的想法只是通过抽象来改进设计和编程.你想隐藏细节,你想利用系统中的任何共性,而你想要让这个实惠.
我想鼓励你不要让面向对象成为毫无意义的术语."面向对象"的概念经常被贬低: - 将其等同于好, - 将其等同于单一语言,或者 - 接受一切都是面向对象的.
我认为除了面向对象的编程和设计之外,还有 - 而且必须是有用的技术.但是,为了避免被完全误解,我想强调一点,我不会尝试使用一种编程语言的严肃项目,这种编程语言至少不支持面向对象编程的经典概念.除了支持面向对象编程的工具之外,我想 - 和C++提供的功能超出了对直接表达概念和关系的支持."
现在......我问你......在你见过的所有OOP程序员和OOP项目中,有多少人可以诚实地声称已经遵守了Bjarne的要求？
IME,低于大多数人.
Bjarne说:
"基本思想只是通过抽象来改进设计和编程"
......但是很多人为自己创造了不同的含义,例如:
"根本的想法是,OOP是好的,而且一切 - 不是OOP都是劣等的"
程序员已经顺序编程ASM,然后是ASM,然后是pascal,然后是C,然后是C++,并且已经暴露于编程预封装等混乱,往往会更好地理解这些东西.他们知道为什么 OOP会出现,它试图解决的是什么.
有趣的是,OOP并没有试图解决每一个编程问题.谁曾说过它,说今天如何谈论它？
它针对的是一小部分问题,这些问题在您的项目越大时就越危险,并且在解决问题时表现为介于"好"和"非常好"之间.
但即使是其中一些,也不仅仅是"善于"解决问题; 还有其他更好的范例......
所有恕我直言,当然;)
任何显着复杂性的系统都不是线性的.即使你非常努力地使系统成为一个线性过程,你仍然依赖于磁盘,内存和网络连接这些可能不稳定的东西,所以你需要解决这个问题.
我不知道有人认为OOP是最终的答案.这只是一种处理复杂性的方法,试图将各种问题限制在尽可能小的范围内,以便它们在爆炸时所造成的损害最小化.我的问题是,它假设完美是可能的.如果是的话,我同意OOP是没有必要的.对我来说,直到有人想出一个更好的方法来减少我犯的错误.