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

instemast

（不建议初学者阅读！初学者请认真学习怎么实现某某功能）

开门见山，我们举几个结构化软件开发的例子（那种无架构的代码就不举了）


中小类库型（我们都这样，  很  良  好  ）

对于中小型的类库或应用，设计一个接口，然后实现这些类即可。 这  很  好 ， 我们谁都是这样做的。


但是对于   大   型   工程，起初可能会采用：

只上不下型（我曾用过）

首先丰富地运用OO各种思想，根据需求（或者参考现有某类库的接口），设计了工程架构，
然后，一一对应地，编码实现这些class.

然后，发现这一种方法，虽然从外面看，接口不错（毕竟经过了绞尽脑汁的设计），
但是编码实现时，经常是复杂而困难的，甚至是混乱的，于是某些人采用：

只下不上型（我没用过）

认真分析如何才能有效地，健壮地去实现工程的设计。决定将类架构，按照“如何实现”去设计。

好处：好处是很实在的，
后果：有些大公司的东西以本人身份，没有资格去评价，但是不知名的人/公司写的东西，我还是可以去评价的吧----类库的用户苦了，于是，这样做：

又上又下型（我最近在用）

把“只下不上型”作为软件的强健有力的“内容物”，
在外部，按照用户的需求，封装一层接口，比喻为“美容”。

具体可以是：
1 外层仅仅是语法上的转换，比如把 Engine->CreateTexture() 包装成 new CTexture.
2 外层在内层基础上，添加了少量简单的辅助代码，而不只是语法的转换，比如对
win32 hwnd 的简单包装类 inst::CGameWnd。
3 外层利用内层，完成更加高级和复杂的功能，比如微软利用 win32 实现了 MFC 。

--------------------------------------------------------------------------

上述方法的实施中，有什么问题？
----对OO特性的沉迷。具体在2方面：

A 在采用第一种“只上不下型”方法时，非常沉迷于OO特性以及C++特性等，对代码恋恋不舍，恨不得自己亲手实现所有的类才放心----因为实现代码，直接一一对应于接口的架构，导致 接口设计-紧密连接-实现代码；

现在我们改用了“又上又下型”的良好方法，而且打算远离实现代码，而只考虑接口设计，那么情况又如何呢？

B 设计一个接口架构的时候，沉迷于各种OO特性，在很多细节上，十分拘泥，浪费了大量时间，尽管已经对实现代码不再关心了。

综上所述，就算实现代码的类架构，和外部接口的类架构是分离的，我们仍然摆脱不了“对OO特性的沉迷”！
----因为，外部接口，也是用那些OO的东西去设计的！

--------------------------------------------------------------------------

“面向对象程序的语义学中的意味不明之处”一文中指出，在外部（用户角度）看来，
OO并不是描述事物的最佳选择。
----那就不要沉迷OO了----既然OO并不好   （我是说外部接口设计哦！莫断章取义！）

不过目前还没有“格语法”（既简化的人类语言）这样的语言，嘿嘿，要么改用C风格，要么自己实现一个“格语法”语言（我的做法）

--------------------------------------------------------------------------

总的来说：

（在大型项目的外部接口的设计上），沉迷于OO，非常不利！沉迷于OO获得了多么多么好的结果了吗？没有----与其沉迷OO，不如暂时用 C style 凑合着，要么更先进地，稍微花点时间，搞搞类似人类语言----这绝对比沉迷OO值得！因为人人都会说人类语言，不需要花多少时间的，而且事半功倍，因为人类语言比OO更加高级，不是吗？

clayman

汗.......

sea_bug

个人经验，开始用struct，后来用class，最后还是struct。。。

无名剑

错不在OO,错是在没处理好代码之间松散耦合的关系

sander_like_kof

大家都说OO"好"了那么多年,突然有个人才说还不如倒退到C style 。干脆西方不要资本主义,中国不要社会主义了.我们一起后到封建制! NO,NO,NO,一起回原始算了

sander_like_kof

请不要发谬论了,C也好,OO也好,范型也好都只不过是人类解决实际问题的哲学方法而已,还不是看否运用的当,用的不好OO当然没其他方式好。  

sander_like_kof

OO本来就是人类语言. 比如如下接口, I.love(you); 这多好主谓兵都有啊? 怎么,沉迷OO就不是人类语言了?

sjinny

不一定是OO的问题，自顶向下与自底向上都各有利弊，传一张以前画的图。

ricohcanon

同意楼上观点，我个人认为一劳永逸的可能性不太大，主要原因是需求是无限和不可预知的，而手段方法则是建立在已知的基础上。如果自顶向下，那么试问你的需求就是这样的吗？不再考虑将来了？如果自底向上，再试问，那些不可预知的无限需求以你现在的手段就能够完全表现出来吗？所以我个人认为不大可能有一劳永逸两全其美的解决方案。只能是在一个可预知，可掌握的范围内找出一个适合的解决方案。

instemast

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

不一定是OO的问题，自顶向下与自底向上都各有利弊，传一张以前画的图。

(1)
注意我说的是：“只上不下”“只下不上”“又上又下”
----这里的“上”“下”不是动词，只是表示场所的名词。

你的图中只表示了前2个，而没有“又上又下”----我认为后者够理想地解决问题

(2)
我除了归纳一下现有的几个设计方法之外，
写这个文章重点想说明的是----不要沉迷于OO特性