经验与教训----在架构时不要沉迷于OO；在实现时灵活选用OO

instemast

sjinny: Re:经验与教训----在架构时不要沉迷于OO；在实现时灵活选用OO

啊晕……自底向下？

恩……我也是觉得要两者结合，不过并没有什么好方法。
如果只是在需求和手段之间用接口来转接，那么有一种风险就是这个转接层会搞得比较复杂……

你不觉得，把封装 DirectXXX 封装成自己的类库，实际上就是在做这种转换吗。
DX不方便直接作高层应用，而另一方面，不用DX或GL等API，我们能实现自己的类库吗？

PS1.只上不下的后果是，每当新添加，或修改一个小小功能时，会对很多代码造成连锁式地影响，这就是为什么我7月份重写UI，而只下不上的UI会令用户敬而远之

PS2.此外说到“人类语言风格”（如果实现了）我认为是：
近人类语言 --> “下”    （这里“近人类语言”就是“上”）
因为沉迷OO会浪费青春，所以用“近人类语言”充当“上”层。

lingjingqiu

如果你觉得自然语言适合表达非线性的逻辑关系你就当我什么都没说。

sander_like_kof

有没有 "主谓兵"是看自己设计的结果,而不是指所有的程序员都在这样做; OO语言特性只能是工具,你要不用人类的语言设计接口自然也就没 "主谓兵"了. 工具在于灵活运用,思想也就不一样了,仁者见仁. 我举例子只是想说明OO思想运用的当可以是程序语言接近人类语言. instemast拿出的代码

PlayerManager.LovesPlayer(I, you); //这句在确定I和you的关系,实现上很可能是个中介者模式,也就是说
//在理解上我可以认为这样说 PlayerManager确定了I和you的关系. 那好,主语是PlayerManager,谓语是确定或 者是存储, I和you的是定语,关系是兵语

Destination.Append( MyString );  //Destination是主语 Append是谓语 MyString是兵语,这还不是?
MyString.AppendTo( Destination );//此句同理

你看看举的例子就逃不了这模式,因为你是个人,OO语言是人类发明的,他就是人类语言相比于C style它肯能表现人类的语言句法,或者说更能良好的表现人类的语言. 至于你能举出PlayerManager.LovesPlayer(I, you);这句那是因为人类是通过语言在描述世界,而世界有的是很抽象的,就好比 "关系",我完全可以把PlayerManager.LovesPlayer(I, you);一句改为 PlayerManager.ConfirmRelation (I, you);

sander_like_kof

所以用“近人类语言”的“上”层类接口表达,才是OO的一大真理,而抽象的东西为什么就不能用OO最基本的理论"隐藏细节"处理掉抽象的借口呢?

asuna

然后，发现这一种方法，虽然从外面看，接口不错（毕竟经过了绞尽脑汁的设计），
但是编码实现时，经常是复杂而困难的，甚至是混乱的，
---- 我觉得这个还是接口设计有些问题. 作设计的人如果不是透彻了解整个系统实现, 很容易出这种问题. 比如在经验不够尚不成熟的架构师.

自底向上的关键我觉得在扩展性如何上. 如果是比较关注重用和扩展的程序员还好些, 如果大部分开发都比较初级, 项目再大些, 用这种方法简直是一场灾难.

我觉得该警醒的是把oo简单的等同成类, 等同成封装, oo了就要绝对的oo.
比如很多java程序或者新程序的习惯, 所有的变量都私有, 全部要通过函数读写
这个拿来做游戏我觉得简直有些灾难性

不管用什么, 如果硬要拘泥于形式应该都是不好的吧.
老实说我觉得架构时与其oo不oo的
不如多考虑考虑架构如何更好的适应需求的变更.

instemast

外层接口要按照用户要求进行设计（否则会令用户讨厌，他们不关心我们的实现）。
内层接口则慎重考虑到编码实现。

我觉得该警醒的是把oo简单的等同成类, 等同成封装, oo了就要绝对的oo.
比如很多java程序或者新程序的习惯, 所有的变量都私有, 全部要通过函数读写
这个拿来做游戏我觉得简直有些灾难性

没错。
用 C 也可以写 OO 那样的接口函数，但是在实现上，容易导致模块划分不良，
而 OO 克服了这一点。但是，一些程序员会认为 OO 等同于他们的需求了
（有个刚学程序的对我说“我在理解，万物皆对象”---- 非常糟糕）

总而言之，内部实现应该“高内聚”，比如像 win32 就把所有东西抽象为 window
一方面很方便实现健壮的程序，另一方面比较能适应需求的变动。
外围的mfc, vb6, .net都要仰仗于 hwnd.

instemast

...algorism based. 嘿嘿.

FankScale

OO本没错，问题在于设计

源代码之光

上上下下，左左右右，ABBA

小小C

什么叫又上又下，先上后下？

我在写一个东西时，把各部分分开来做，尽量降低各部分之间的联系，使得一个部分被修改后，尽量不影响到其它部分，一个部分甚至可以独立的拿出来。

还没有参与过大型项目的开发，现在刚进一家比较大的公司。只谈谈自己做ARPG游戏的感受。

一开始，没有像许多人那样，定义什么类，什么继承，什么多态。一开始写的是底层，一个是把DDRAW封装，负责渲染。另一个是资源管理类，负责资源的打包、读取等。

然后，并不是马上开始写什么游戏。而是先写动画编辑器，实现动画文件的帧、方向等的编辑操作。在写这个编辑器时，不断修改完善前面两个底层。

再然后，开始写地图编辑器，尝试各种地图数据组织的方法，实现地图、建筑物的编辑。

再然后，开始尝试把人物放到地图上，尝试并实现人物的控制。然后慢慢加入寻路、NPC、战斗等等。

再然后，为了实现NPC、物品、魔法，而尝试并实现了自己的脚本系统。原来的动画编辑器也慢慢的变成了游戏编辑器，加入了对脚本、NPC对话框、物品、魔法的编辑功能。

整个制作的过程，就是一个累砖头的过程，先有底层，然后慢慢往上加东西，一块砖头可以放进去，也可以拿出来，不影响整坐墙的稳固性。 我在制作这个游戏时，我心里想的是怎么把它的功能实现，怎么尽量的减少重复性的工作，我并没有去想什么继承，多态，设计模式。。。。。。整个游戏只有二、三个地方用到了继承，只在精灵类中用到了虚方法。。。。。。。

现在在公司开发，用wxWidgets，它的确是实现了OO，但是写一个简单的窗口release版的有1.17M.............OO思想是好的，但是想追求完美的OO，也许会付出代价的。