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设计模式》，。