《设计模式精解》读书笔记

Posted on 2008-05-14 17:53 RichardHe 阅读(321) 评论(0)  编辑 收藏 引用 所属分类: [转]

1、模式是应该结合在一起共同解决问题的。

评论:以前看《GOF设计模式》的时候主要就是看目的,然后就是代码,对协作啊,优缺点啊,效果啊都不怎么注意,不过就算看了也不知所云。学下来就像背数学公式一样,单个是记住了,拿到具体环境里又懵了。看来还是得多花点时间看看模式的关联啊。

 

2、我的错误是:我尝试先创建问题领域中的累,然后将这些类缝合起来形成最终的系统。——Alexander把这样的过程称为一个“坏主意”。我从来没有问过我自己:我是否拥有正确的类?仅仅因为这些类看起来如此正确、如此明显。我拥有的是在开始分析时立刻进入脑海中的类,是我们的老师告诉我们应该在系统中寻找的“名词”。但是我的错误就是仅仅尝试把它们简单地放在一起。

评论:连大牛都会犯这样的错误,我这样的菜鸟这样分析系统应该也比较正常吧。在看问题的层次上,我们太过于重视细节,就像我写WinForm程序时先考虑有哪些组件可以使用一样,把思路给限制住了,忽视了类所处的环境、上下文。

 

3、面向对象的范式:使用对象将责任转义到更局部的范围。对象应该对自己负责,并且这种责任应该被清楚的定义出来。

评论:这个对类的定义就要合理的多。作者认为软件开发中有三个视角:概念(用例)->规格(接口)->实现(代码)。从最低层次看,类就是变量+函数,但这样就太狭隘了。真正的对象应该与现实生活中的对象相似,有自己的行为、状态,自己对自己负责(多么精确的概述啊)。

 

4、抽象类就是其他类的占位符。

评论:比较形象的描述。我先描述类的大致行为供调用者了解,具体的行为留到子类实现,抽象类与子类达成一个契约。

 

5、过早的对细节投入过多的关心是一个分析缺陷。

评论:同2

 

6、留意你的直观:当你看到某些不喜欢的东西时,你胃部的感觉。

评论:牛人就是幽默。这里主要是说明如何感觉一个设计是坏的设计的。我是说最近写程序胃老不舒服,饭也吃不好……

 

7、关注模式的场景而非解决方案。

评论:作者自始至终一直强调是场景决定解决方案,而不是为了实现某个模式而去进行设计,否则就像小学生套公式一样了。场景分析好了,模式自然也就出来了(这是境界比较高的时候)。

 

8、在创建对象时用共同点/变化点分析而非观察名词与动词。因此,我们要:

   a、发现并封装变化点。

   b、优先使用对象组合,而非类继承。

评论:关于共同点/变化点的分析,在Bridge模式中体现的犹为明显(我在前面的Blog中介绍过),借助分析矩阵也可以帮助理清思路。而b点是面向对象设计中的基本原则,就不用多说了。

 

9switch语句常常标志着:(1)对多态行为的需要。(2)存在着放错地方的责任。请考虑用一种更普适的解决方案代替switch语句,比如抽象、将责任分配给另外的对象等等。

评论:老听别人说丑陋的switch语句、ifelse语句,都不是太懂,现在好像有点懂了,因为条件语句不灵活,很难维护吧。碰到它马上就要想到用多态的方式去处理,像State模式、Visitor模式就和这有关。

 

10、用模式的方法去思考:

步骤:

1)、发现我在问题领域中拥有的模式

2)、对于这些需要分析的模式,做下列工作:

   a、挑出为其他模式提供最多场景的模式。

   b、在我概念性最高的设计中使用这个模式。

   c、识别任何可能已经出现的附加模式。将它们添加到“需要分析的模式”中。

   d、对需要分析而未分析的模式,重复上述工作。

3)、按照需要将细节添加的设计中。扩展方法和类定义。

评论:具体的说就是找到可以统领全局的模式,再用其他的模式配合它,“面向模式的设计”(POP)。算了吧,我连OOP都没学好,这个以后再说啦。

 

11、在学习面向对象技术的早期学习设计模式,可以大大帮助你提高对面向对象分析、设计的理解。

评论:这个倒是第一次听说,不过怎么也得先把继承、封装、多态弄清楚吧。再加上一条,在学习设计模式时,一定要先读这本《设计模式精解》,再看《GOF设计模式》,


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


posts - 94, comments - 138, trackbacks - 0, articles - 94

Copyright © RichardHe