##关于建模的问题.txt

一些关于UML的经典讨论

中国UML论坛

原文(lythm于2001/03/22 01:33粘贴) 
hi,关于建模的问题 
--------------------------------------------------------------------------------

我是一个初学者,还在读书,我不知道现在学习uml是不是早了点 
可我在学,但学不得法,感觉就是:分析的时候没有什么是确定的 
一种方式和另一种方式都很好,感到路子很多,但都有这样那样的缺点 
我觉得可能是我的经验不足吧.我还没有能力体会出什么是好的设计吧 

我正在写一个游戏,一方面是兴趣另一方面作为ood的练习 

我的设计是这样的, 
在屏幕上所有不能重叠在一起的对象作为一层,将层作为一个抽象基类 
实现了两个接口,一个是draw,一个是ProcessEvent 
所有的屏幕可见的类都从CLayer继承,然后从CLayer派生一个容器类 
所有有关联的类都包容在容器里,这样可以一起处理,在每个容器的draw 
里调用成员的draw实现重画 
另外我还定义了几个工具类,不是从任何基类继承下来的,如CDraw,CInput,CSound等等,用来驱动他们 
可是后来我发现我所有的需要显示的的类都是从CLayer继承下来的,这样不管能不能重叠都是一个层了,好像已经违背了原来的语义 
可是我的程序也已经差不多写完了,怎么办?是否有什么补救的的策略? 
我现在感觉是头脑里乱哄哄,已经理不出头绪了. 
我本来是想将碰撞监测放到层里,层内的东西不能重叠,所以分配这个任务给他实在好不过的了,虽然我现在做的用不上碰撞监测,但是这个想法对吗? 

还有一个问题,就是菜单,我定义了一个CDDMenu和CDDMenuItem类 
menu是menuitem的容器,在CDDMenuItem的构造函数参数里传一个CCommand的子类 
每个cmd都覆盖了基类的Action接口,可是实际应用的时候我发现,不管什么操作 
在都不能进行,除非把所有类的的实例作为参数传给cmd,可是这参数怎么定义呢? 
是不是用模版? 
可是这参数要通过menuitem阿 
还是在cmd构造是传实例? 
快帮帮我把,我怎么觉得用oo最后使得一切乱糟糟阿 

是不是我功力不够?我该怎么提高啊? 

请大家一定帮帮我. 
帮我看看上面的实现,还有什么不妥的地方?我准备全部重写了,重写之前 
请给我提提意见 
拜托了,给大家磕头了 

====
原文(jyemii于2001/03/22 11:01粘贴) 
回复: hi,关于建模的问题 
--------------------------------------------------------------------------------

你学 UML 不会太早，我常说 UML 是软件设计时用来建造模型的一种语言，即然是一种语言，它具有「语言」应有的特色，如果这种语言是你生活或职场上面所需要的，目的是和其它人沟通，什么时候学习都不算早。若以一个初学者而言，这种茫然的感觉是有的，我们都是过来人，我觉得你所欠缺的是实务的经验，欠缺的是运用的火候，以及实作对象的技巧，其余你还是做的很好。 

UML 它是一种建模的语言，它没有规范如何分析系统的方法，也就是它并非软件开发程序的方法论，所以你若对建模有兴趣，你还必须学习一套方法。另外，你犯了一般程序员所易犯的毛病，未完成系统分析及设计的建模作业，就很急速的进入软件构筑(指的是程序设计及编码的动作)。因为看完你的叙述，只见到你在类别设计及程序实作上遭受到的困难。再来，从你上面的那一大串叙述中，能够真实捕获你设计意图的人，那更少之又少。于是，我给你以下几点建议： 

首先，建议你看 Design Patterns 这本书，里面有几个设计的样式(Patterns)很适合你所遭遇的状况，例如你设计 Menu -> MenuItem -> Command 的问题，可以使用 Command Pattern，而 Design Patterns 有关 Command Pattern 这个章节，也有一个范例类似你的问题，并且提出解决的方法及范例。而对于 Clayer 及 Menu 部分的实作，有关的 Pattern 尚有 Composite、Memento、Decorator这些 Pattern 技巧可以使用，详细的说明请参考这本书(你可以从文件分享中取得，也有部分翻译文)。 

其次，实际编写程序时与你使用的作业平台（Linux 或 Windows），及使用的程序语言也有关系，若我没有猜错，你应该使用 C++。而我的意思是，如果你的环境是 Windows + MFC，你应该尽量发挥 MFC 及 Windows 的特色，当然，若是 Linux + C++，那么你必须使用C++自行架构所有类别，但你仍然可以考量运用 Linux 平台的特性。 

希望以上的说明，对你能够提供一些帮助。 

=====
原文(lythm于2001/03/22 21:12粘贴) 
回复: hi,关于建模的问题 
--------------------------------------------------------------------------------

谢谢 
有帮助 
关于对设计的描述用什么工具能够好一点?你说的是指我讲的含糊不清吗? 
我对uml的认识仅仅是effect一书的开头介绍的一些,有什么更好的书么? 

===
原文(jyemii于2001/03/23 12:13粘贴) 
回复: hi,关于建模的问题 
--------------------------------------------------------------------------------

>关于对设计的描述用什么工具能够好一点？ 
对于用来描述你设计概念，绘制 UML 图形的工具有很多，如 Rational Rose、Microsoft Visio Enterprise 2000等，但价格都不便宜，如果你想要了解有关工具的相关信息，可以参考下列的网站，它提供相当完整的说明及各种工具的比较： 
　　http://www.objectsbydesign.com/tools/modeling_tools_cn.html 
若你无法取得这些工具软件，实际上你也可以绘制在纸上，虽然比较不方便，但仍不失为一种克难的学习方式，重点在描绘你的设计概念，可以达成目的就行了。 

>你说的是指我讲的含糊不清吗？ 
程序设计除了与实务经验息息相关外，与开发产品的领域知识也有关系，对有开发软件多年经验的人而言，后者(领域知识)较前者(程序设计)重要许多，当然，这不是意味程序设计就不重要。因此，若你想让缺乏游戏这个相关领域知识的人，了解你设计的意图，你必须竭尽所能的，让他明白你在实体设计及逻辑设计的概念，就拿相关类别(Class)及类别之间关系(Association)的设计描述，jasperyeh 这位网友的描述，显得清楚很多。你可以看看他的所发的帖子，是不是相当清楚？从这些细节，可以了解这位老兄（应该也不算怎么老，搞不好还较我年轻许多），他于程序设计的实务经验就有相当程度的火候。因此，他的建议就具有一定程度的价值，我的意思是说，你可以于游戏设计这部分不断向他请益，并把他的宝藏挖出来。 

>我对uml的认识仅仅是effect一书的开头介绍的一些，有什么更好的书么？ 
UML 入门书，以 Martine Fowler 所写的 UML Distilled, 2nd Edition(UML 精华，目前最新的是第二版)写得最好，他对 UML 的发展、表示法(Notations)的正确使用概念及如何运用各种图形，提供初学者一个正确运用 UML 的观念。但对 UML 正规语法的着墨就不多，而要了解 UML 详细的语法当然首推 Grady Booch、Ivar Jacobson 及 James Rumbaugh 三位大师合着的 The Unified Modeling Language Reference Manual(UML 参考手册)，另外你也可以从 OMG 协会中下载 UML 官方的规格。文件分享区内应该也有这种东西，这有助于你在设计时辅助参考用。另外有一本书，同样也是这三位大师所写的，书名为The Unified Modeling Language User Guide(UML 使用指引)，也是很好的一本书。其它还有很多好书，你可到以下的网站去看： 
http://www.rational.com/products/rose/books.jsp 
而有关UML Distilled, 2nd Edition，你可以在下面的网站看到更多的信息： 
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=020165783X 

希望这样的回答对你有所助益。 

====
原文(notyy于2001/03/22 11:37粘贴) 
回复: hi,关于建模的问题 
--------------------------------------------------------------------------------

没关系。继续努力。：） 
关于clayer，原本你打算做为所有需要显示但不能重叠的类的抽象接口，现在则实现成了所有需要显示的类的抽象接口。那就再定义一个需要显示但不能重叠的类的抽象接口如cunoverlap和一个需要显示而且能够重叠的类的抽象接口如coverlap或什么的，都继承自clayer，然后修改那些继承自clayer但不能够重叠的类，改为继承自cunoverlap，为cunoverlap定义碰撞检测的接口，在继承自cunoverlap的类里实现，其他的类改为继承字coverlap 

至于后一个问题似乎和design pattern里的command pattern描述的情况比较象，去看看吧。 

====
原文(tacone于2001/03/22 13:48粘贴) 
CLayer不是抽象基类 ，另外定义抽象基类 
--------------------------------------------------------------------------------

对你的模型做了如下修改： 
引入抽象基类CGameObject,CGameViewObject,由它们实现原CLayer的大部分功能，CGameObject派生CGameViewObject和CGameContain,CGameContain和CLayer都有多个实例它们一对一关联，在把CLayer聚集到孤子类CGameScreen，CGameViewObject派生其他所有的屏幕可见的类，CGameViewObject各子对象聚集到CGameContain，这样一来处于相同CLayer实例的屏幕可见对象不会重叠，而处于不同CLayer实例的屏幕可见对象可以重叠，并保留在每个容器的draw 里调用成员的draw实现重画 。 
上传图CLayer改进，不知妥否。 


第二问题，可能是CMD与接口的映射没做好，若愿意还是看看你这部分的详细设计 再说。 
EMAIL：[e-mail] 

===
原文(lythm于2001/03/22 21:03粘贴) 
回复: CLayer不是抽象基类 ，另外定义抽象基类 
--------------------------------------------------------------------------------

首先申明一点，我准备重写了，原来的框架全都不用了，请大家修改的时候 
不要考虑和原来代码的兼容，谢谢大家 
tacone： 
CLayer是继承自那一个类？是不是就是CGameContain？ 
还有孤子类是什么意思？是不是就是不从任何基类继承的？ 
如果要实现碰撞监测，在CGameContain李，那么我在那个接口里调用？ 
因为程序是基于dx的，所以每次屏幕刷新是强制的 
流程如下 

在CGameApp（是我定义的应用类，模仿mfc的CWinApp，不过消息循环简单处理了）里有个函数，StartGame 
bool StartGame（） 
{ 
。。。 
for（int i=0；i _Layers[i]->draw(_draw) 
... 
for(i=0;i _Layers->ProcessEvent(...); 
... 
} 
所以,我在CGameContain的ProcessEvent里进行碰撞监测,行不行? 


还有,关于_draw,我是作为CLayer里的draw函数的参数传进去的,这样可以保证 
只有在draw方法里可以画,其他地方不行(模仿mfc的ondraw(CDC* pDC)) 
没问题吧? 

=====
原文(tacone于2001/03/25 12:22粘贴) 
回复: lythm 
--------------------------------------------------------------------------------

lythm: 
大家提了很多建议，基本思路都是把能重叠的对象分配到不同层。 
你的原设计中有对抽象基类的多个引用，我不太习惯。 
为了实现多层，我认为Clayer有多个实例（故Clayer不能是抽象基类），每个实例对应一层，处于同层的对象不能重叠，处于不同层的对象可以重叠，Clayer 与CGameContain 一一关联，其相互关系如同MFC中CDOC/CVIEW的相互关系，当然应该在CGameContain的ProcessEvent里进行碰撞监测。Clayer 是否从CGameObject 派生并不重要。 
对于 Draw（），定义CGameContain 为CGameViewObject 及其各子类的友员，也能达到你原来的意图。 
特此补充。 

====
原文(lythm于2001/03/22 21:09粘贴) 
回复: hi,关于建模的问题 
--------------------------------------------------------------------------------

首先申明一点，我准备重写了，原来的框架全都不用了，请大家修改的时候 
不要考虑和原来代码的兼容，谢谢大家 

tacone和notyy的实现都可以,那个更好?什么理由?我想认识更深一些 
我个人认为好像notyy的实现比较简单一些,是不是? 


还有,关于_draw,我是作为CLayer里的draw函数的参数传进去的,这样可以保证 
只有在draw方法里可以画,其他地方不行(模仿mfc的ondraw(CDC* pDC)) 
没问题吧? 

关于cmd我再好好看看设计模式重新考虑一下 

===
原文(jasperyeh于2001/03/22 23:02粘贴) 
Re: hi,关于