为什么很少看到游戏程序用到全部面向对象编程方法的？

疯子阿虹

ogre不够面向对象吗？

numpfish

huangjinlu: Re:为什么很少看到游戏程序用到全部面向对象编程方法的？

所谓继承、重载、多态等，只是神化了编程语音而已,给你带来方便，更给你添乱，试想一个精密的程序，其中有很多神秘的方法代码你放的下心吗？所以有用则用之，无需则弃之.

所谓的神秘的方法代码是你没弄懂的吧，了解个大概，偶尔用了几次，发现一两个自己无法解释的bug，然后就弃用了。

tkminigame

面向对象事件传递这些，别jb害人了，游戏程序员首先要学会的是用最简单最直接的方式解决问题，而这些需要更基础的计算机知识，oo这些商业化忽悠是用来拯救那些水平未够但又做着程序员工作的绝望的程序员们。就是让他们从一个坑爬出来，掉到另一个坑里。在这个领域就属于误人子弟

tkminigame

搜了一篇文章可以看看。
http://coolshell.cn/articles/3036.html

程序员要避免忽悠，避免过多的在忽悠上浪费时间，首要还是要练好基本功。

josephchen

我也经历过几个公司，都是面向过程开发的，其结果就是无法应对需求变化和后期开发成本高昂，项目往往都很难走好，后期基本无法维护，这个只能说主程人员能力不够。作为一个合格的架构师面向对象本身就是最基本的，能够根据经验正确认识和分析实际中的问题，并采用适当的设计模式，这里不仅仅是书本上介绍的设计模式，在实际应用场合可以是千变万化的。从而让别的开发人员能够在其基础上做各种开发，就如同各种类库和framework一样，将复杂的逻辑隐藏，只暴露出符合人逻辑思维的方法和事件等，供给实际开发人员使用，从而简化逻辑，达到简单易用的目的。这个如同楼上说的，好的架构师只要最直接的方法，当然，还是在考虑了之后的扩展性和维护性做出的综合决定。楼上所谓的面向对象没用。。。那个估计是开发底层，写个驱动什么的场合了，这个和通常的庞大项目或者是游戏项目通常没有可比性，因为后者更注重适应变化和可维护性。

numpfish

顶楼上的， 喷面向对象的一般是还没理解什么是面向对象。不是你用了java C#就是面向对象，也不是你套用了几个设计模式就是面向对象。

loverotin

面向对象这个名词被神话了，这主要是一个思想，一个项目无非是在大的框架设定上，世界的布局架构上用到的设计方式，框架只需要做一次，大部分都是在框架内部做的业务逻辑

不过继承多态，在处理逻辑的时候用到的还是很多的，至于用与不用，用的好与坏与实际的开发人员的经验有关，一般来说，一个逻辑功能最后达到的目的就是完成该功能，有的人可能设计的好以后修改容易，有的人设计的差可能在修改的时候会改动更多的代码

tkminigame

写程序时注意数据的流向。

你的程序是把数据A转换成数据B，那么就应该采用一条从数据A到数据B的最短路径，这是最直接最有效率的方式，然后再看，A到B是最有效率的，但是A到C有点远，为了减少路的总长度，可能要让A到B的路打个弯，再在某个点打个缺口，这样就不用完全修另一条A到C的路，还为B到C打下基础，这叫代码重用。

如果在这个时候还要考虑将来通往D,E,F类型的数据转换，那么就应该在设计A到B的路的时候把这些可能考虑进来，使将来的工程成本降到最低，这叫考虑扩展性。

后来发现，在某个区域，各种数据之间交叉太深，为M种数据修MxN条路太不经济，于是你决定在数据类型上建飞机跑道，让任何经过该数据的流转都从飞机跑道进出，减少了接口数量，或者采取某种调度模式，让数据A到数据B进过间接的调度而不再直接发生连接，这叫解耦。

以上的实现，没有哪一种是非要采用面向对象的。很多时候，不采用OO的原因：

一，OO进行数据流转的方式，太猥琐，太弯弯绕了。所以OO效率不高，而且这种时候，代码可读性也不高。

二，要了解问题的本质是什么，然后要了解OO的实现机制，它适合解决哪类问题。然后你会发现，在很多时候采用OO都是错误的选择，因为这种机制挡着你的路了，不仅没能简单直接的解决问题，还增加了额外的麻烦。

在现实中很多工程问题根本用不上OO，而很多人还坚持用OO，是因为：

一，他们只会用OO，学校就是这么教的。

二，被商业化宣传给忽悠了，以为包治百病，这个行业里没这种东西。