Posted on 2008-05-14 17:53
RichardHe 阅读(337)
评论(0) 编辑 收藏 引用 所属分类:
[转]
1、模式是应该结合在一起共同解决问题的。
评论:以前看《GOF设计模式》的时候主要就是看目的,然后就是代码,对协作啊,优缺点啊,效果啊都不怎么注意,不过就算看了也不知所云。学下来就像背数学公式一样,单个是记住了,拿到具体环境里又懵了。看来还是得多花点时间看看模式的关联啊。
2、我的错误是:我尝试先创建问题领域中的累,然后将这些类缝合起来形成最终的系统。——Alexander把这样的过程称为一个“坏主意”。我从来没有问过我自己:我是否拥有正确的类?仅仅因为这些类看起来如此正确、如此明显。我拥有的是在开始分析时立刻进入脑海中的类,是我们的老师告诉我们应该在系统中寻找的“名词”。但是我的错误就是仅仅尝试把它们简单地放在一起。
评论:连大牛都会犯这样的错误,我这样的菜鸟这样分析系统应该也比较正常吧。在看问题的层次上,我们太过于重视细节,就像我写WinForm程序时先考虑有哪些组件可以使用一样,把思路给限制住了,忽视了类所处的环境、上下文。
3、面向对象的范式:使用对象将责任转义到更局部的范围。对象应该对自己负责,并且这种责任应该被清楚的定义出来。
评论:这个对类的定义就要合理的多。作者认为软件开发中有三个视角:概念(用例)->规格(接口)->实现(代码)。从最低层次看,类就是变量+函数,但这样就太狭隘了。真正的对象应该与现实生活中的对象相似,有自己的行为、状态,自己对自己负责(多么精确的概述啊)。
4、抽象类就是其他类的占位符。
评论:比较形象的描述。我先描述类的大致行为供调用者了解,具体的行为留到子类实现,抽象类与子类达成一个契约。
5、过早的对细节投入过多的关心是一个分析缺陷。
评论:同2。
6、留意你的直观:当你看到某些不喜欢的东西时,你胃部的感觉。
评论:牛人就是幽默。这里主要是说明如何感觉一个设计是坏的设计的。我是说最近写程序胃老不舒服,饭也吃不好……
7、关注模式的场景而非解决方案。
评论:作者自始至终一直强调是场景决定解决方案,而不是为了实现某个模式而去进行设计,否则就像小学生套公式一样了。场景分析好了,模式自然也就出来了(这是境界比较高的时候)。
8、在创建对象时用共同点/变化点分析而非观察名词与动词。因此,我们要:
a、发现并封装变化点。
b、优先使用对象组合,而非类继承。
评论:关于共同点/变化点的分析,在Bridge模式中体现的犹为明显(我在前面的Blog中介绍过),借助分析矩阵也可以帮助理清思路。而b点是面向对象设计中的基本原则,就不用多说了。
9、switch语句常常标志着:(1)对多态行为的需要。(2)存在着放错地方的责任。请考虑用一种更普适的解决方案代替switch语句,比如抽象、将责任分配给另外的对象等等。
评论:老听别人说丑陋的switch语句、ifelse语句,都不是太懂,现在好像有点懂了,因为条件语句不灵活,很难维护吧。碰到它马上就要想到用多态的方式去处理,像State模式、Visitor模式就和这有关。
10、用模式的方法去思考:
步骤:
(1)、发现我在问题领域中拥有的模式
(2)、对于这些需要分析的模式,做下列工作:
a、挑出为其他模式提供最多场景的模式。
b、在我概念性最高的设计中使用这个模式。
c、识别任何可能已经出现的附加模式。将它们添加到“需要分析的模式”中。
d、对需要分析而未分析的模式,重复上述工作。
(3)、按照需要将细节添加的设计中。扩展方法和类定义。
评论:具体的说就是找到可以统领全局的模式,再用其他的模式配合它,“面向模式的设计”(POP)
。算了吧,我连OOP都没学好,这个以后再说啦。
11、在学习面向对象技术的早期学习设计模式,可以大大帮助你提高对面向对象分析、设计的理解。
评论:这个倒是第一次听说,不过怎么也得先把继承、封装、多态弄清楚吧。再加上一条,在学习设计模式时,一定要先读这本《设计模式精解》,再看《GOF设计模式》,
。