游戏开发论坛

 找回密码
 立即注册
搜索
楼主: instemast

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

[复制链接]

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 17:24:00 | 显示全部楼层

Re: Re:经验与教训----在架构时不要沉迷于OO;在实现时灵

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

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


同感...

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 17:28:00 | 显示全部楼层

Re: Re:经验与教训----在架构时不要沉迷于OO;在实现时灵

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

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 17:38:00 | 显示全部楼层

Re: Re:经验与教训----在架构时不要沉迷于OO;在实现时灵

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

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


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

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

125

主题

364

帖子

396

积分

中级会员

Rank: 3Rank: 3

积分
396
QQ
发表于 2008-9-19 17:47:00 | 显示全部楼层

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

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

149

主题

4981

帖子

5033

积分

论坛元老

Rank: 8Rank: 8

积分
5033
QQ
发表于 2008-9-19 17:47:00 | 显示全部楼层

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

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

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 17:59:00 | 显示全部楼层

Re: Re:经验与教训----在架构时不要沉迷于OO;在实现时灵

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

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


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

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

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

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 18:03:00 | 显示全部楼层

Re: Re:经验与教训----在架构时不要沉迷于OO;在实现时灵

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

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


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

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 18:05:00 | 显示全部楼层

Re: Re:经验与教训----在架构时不要沉迷于OO;在实现时灵

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

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


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

149

主题

4981

帖子

5033

积分

论坛元老

Rank: 8Rank: 8

积分
5033
QQ
发表于 2008-9-19 18:16:00 | 显示全部楼层

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

啊晕……自底向下?

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

362

主题

3023

帖子

3553

积分

论坛元老

Rank: 8Rank: 8

积分
3553
 楼主| 发表于 2008-9-19 18:21:00 | 显示全部楼层

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

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

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2026-1-20 15:35

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表