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

instemast

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

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

同感...

instemast

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

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

你不如看看下面例子的再说：
PlayerManager.LovesPlayer(I, you); // C++常用的风格
Destination.Append( MyString );
MyString.AppendTo( Destination );

我没有看出来“主谓兵”。

>> 倒退到 C - style
我最希望的不是 C style，而是人类语言比如“Append MyString to Destination”
只不过，据我所知这样的语言没有在计算机上实现。所以 C style 也可以凑合着。
http://bbs.gameres.com/showthread.asp?threadid=116888

instemast

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

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

本文主要讨论的是，从设计（策划！）角度，应该采用什么样的方法去描述工程的外在结构，就是说，用什么样的语言文字，（理性地）表述我们的设计蓝图。

说极端点，就是“门外汉”怎么描述一个软件/游戏/引擎。
----因此不涉及“耦合的关系”----因为不管代码是怎么耦合的，在外部都可以用喜爱的接口去包装，或者用喜爱的文字去描述。

shaoxiaoning

《UNIX编程艺术》里分别总结了 自顶向下 和自底向下 的优点和缺点，以及两者结合的情形。
而UNIX则首推自底向下的设计。

sjinny

我对你的那些概念的理解就是，做设计时的出发点更偏重需求或者更偏重手段。
我那个图所表达的是：
如果偏重于需求，那么可能会使用不是很成熟的手段来解决正确的问题；
而如果偏重于手段，则可能会使用很成熟的手段去解决错误的问题。

instemast

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

同意楼上观点，我个人认为一劳永逸的可能性不太大，主要原因是需求是无限和不可预知的，而手段方法则是建立...

本文的大目的是“在设计时建议远离OO”（因为即使不写代码也容易被OO套住），而不是讨论如何开发软件。

要谈到如何开发软件的话，我上面已经归纳了3种方法（一代而过）。
其中“又上又下”型最好

如果需求增加了，那么首先“上部”（外围接口设计）就要改变，
然后我们看，“下部”（编码实现）的类架构需不需要修改，若能实现新功能就不改。

instemast

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

《UNIX编程艺术》里分别总结了 自顶向下 和自底向下 的优点和缺点，以及两者结合的情形。
而UNIX则首推自底向下的设计。

是啊。在调用win API, com, mfc 的时候，代码敲类死了。自己封装也不现实。

instemast

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

我对你的那些概念的理解就是，做设计时的出发点更偏重需求或者更偏重手段。
我那个图所表达的是：
如果偏...

我现在都是两方面并重，最后把两方面连接起来。连接方法基本就是“接口转换”

sjinny

啊晕……自底向下？

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

instemast

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