我在看一本名叫《DesignPatternExplained》的书，读了一到五章，觉得有些地方很不错。
1． 找教室
假设你要在一个会议上担任讲师，听课的人在课后还要去听其他课，但他们不知道听课地点。你的责任之一，就是确保大家都知道下一堂课去哪上。
· 结构化程序设计
也就是功能分解，通常会让一个“主”程序负责控制子程序。主程序要密切关注大量细节，除你之外没有其他人负责。
· 另外一种方法
你只给出通用的提示“我已经把下一堂课的地点和其他教室的位置贴到教室后面了，请根据它找到你们下一堂课的教室”，然后期待每个人会自己弄清怎样完成任务。
2． 新视角
引用Martin folwer 在<UML Distilled〉书中将的3个视角：
· 概念：软件要负责什么
· 规约：软件要怎么使用
· 实现：怎样履行自己的责任
3． 美与丑
1979年一位伟大的建筑师Christopher Alexander写了一本经典著作：The Timeless Way of Building, <建筑的永恒之道>。书中提到一个问题：“质量能客观评价吗？”
也就是说真的是情人眼里出西施还是人们能够就哪些东西美哪些东西丑取得共识？
大量的工作说明在一种文化中，不同的人在很大程度上会就“何为优秀的设计，何为美”之类的问题达成共识。
那么应该怎样进行优秀的设计呢？我们可以扪心自问：
在优秀的设计中具备的，而在劣质的设计中不具备的是什么？
以及
在劣质的设计中具备，而在优秀的设计中不具备的是什么？
我们要找出设计因何优秀，又因何拙劣。
4． 模式
设计与要解决的问题密不可分，观察解决相似问题的不同设计，可以看清优秀设计之间的相似之处。这种相似之处就是所谓的模式。
因此模式的定义是：“在某一背景下某个问题的解决方案”。
“每个模式都描述了一个在我们的环境中会不断重复出现的问题，并进而叙述了这个问题的解决方案的要素，通过这种方式，解决方案可以上百次的反复应用，但具体方式又不会完全相同”。
模式的关键特征
项目 描述
名称 每个模式都有唯一的用于标识的名称
意图 模式的目的
问题 模式要解决的问题
解决方案 模式怎样为问题提供适合其背景的解决方案
参与者和协作者 模式所涉及的实体
效果 使用模式的效果，研究模式中期作用的各种因素
实现 模式的实现方式
注意：实现只是模式的具体应用，不能视为模式本身
一般性结构 显示模式典型结构的标准图
5． 模式应用举例
· 木匠对话
想象一下，有两个木匠在讨论怎样为橱柜制作抽屉。
木匠甲：你认为我们应该怎样制作这些抽屉？
木匠乙：这个嘛，在木料上直接锯下去，然后回转45度再锯，接着再直着锯，然后换一个方向45度往回锯，接着再直着锯下去，然后。。。
这段话让人不知所云，木匠乙到底给出什么建议？细节往往就是如此。你获得的是对细节的具体描述，而对“到底要做成什么”和“为什么这么做”毫无头绪！
当然，真正的职业木匠可不会这样说话，真实的情形如此：
木匠甲：我们应该用鸠尾榫还是斜榫？
和上面对话本质的区别是他们在讨论问题的解决方案的差别，外行听不出来，而其中含义却非常丰富。
斜榫：更容易制作，只需将制作榫的木料锯出45度的斜面，然后用钉子或木胶结合起来既可。重压下无法保持接合，不引人注目。
鸠尾榫：对外行人来说可能并不清楚，但每一个木匠都明白。它是一个坚固，可靠，美观的榫，如果制作精良，会很美观，但制作复杂，成本也较高。。
第一种情形，木匠乙讨论的事榫的实现细节，反而使气真正的问题变得模糊不清，在第二中情形中，木匠甲要根据榫的成本和接合性质来决定使用哪种榫。
谁更有效呢？你更愿意和谁一起工作？
6． 目标
体会优秀设计的策略：
· 按接口编程
· 尽量用聚合代替继承
· 找出变化并封装之
-End-
1． 找教室
假设你要在一个会议上担任讲师，听课的人在课后还要去听其他课，但他们不知道听课地点。你的责任之一，就是确保大家都知道下一堂课去哪上。
· 结构化程序设计
也就是功能分解，通常会让一个“主”程序负责控制子程序。主程序要密切关注大量细节，除你之外没有其他人负责。
· 另外一种方法
你只给出通用的提示“我已经把下一堂课的地点和其他教室的位置贴到教室后面了，请根据它找到你们下一堂课的教室”，然后期待每个人会自己弄清怎样完成任务。
2． 新视角
引用Martin folwer 在<UML Distilled〉书中将的3个视角：
· 概念：软件要负责什么
· 规约：软件要怎么使用
· 实现：怎样履行自己的责任
3． 美与丑
1979年一位伟大的建筑师Christopher Alexander写了一本经典著作：The Timeless Way of Building, <建筑的永恒之道>。书中提到一个问题：“质量能客观评价吗？”
也就是说真的是情人眼里出西施还是人们能够就哪些东西美哪些东西丑取得共识？
大量的工作说明在一种文化中，不同的人在很大程度上会就“何为优秀的设计，何为美”之类的问题达成共识。
那么应该怎样进行优秀的设计呢？我们可以扪心自问：
在优秀的设计中具备的，而在劣质的设计中不具备的是什么？
以及
在劣质的设计中具备，而在优秀的设计中不具备的是什么？
我们要找出设计因何优秀，又因何拙劣。
4． 模式
设计与要解决的问题密不可分，观察解决相似问题的不同设计，可以看清优秀设计之间的相似之处。这种相似之处就是所谓的模式。
因此模式的定义是：“在某一背景下某个问题的解决方案”。
“每个模式都描述了一个在我们的环境中会不断重复出现的问题，并进而叙述了这个问题的解决方案的要素，通过这种方式，解决方案可以上百次的反复应用，但具体方式又不会完全相同”。
模式的关键特征
项目 描述
名称 每个模式都有唯一的用于标识的名称
意图 模式的目的
问题 模式要解决的问题
解决方案 模式怎样为问题提供适合其背景的解决方案
参与者和协作者 模式所涉及的实体
效果 使用模式的效果，研究模式中期作用的各种因素
实现 模式的实现方式
注意：实现只是模式的具体应用，不能视为模式本身
一般性结构 显示模式典型结构的标准图
5． 模式应用举例
· 木匠对话
想象一下，有两个木匠在讨论怎样为橱柜制作抽屉。
木匠甲：你认为我们应该怎样制作这些抽屉？
木匠乙：这个嘛，在木料上直接锯下去，然后回转45度再锯，接着再直着锯，然后换一个方向45度往回锯，接着再直着锯下去，然后。。。
这段话让人不知所云，木匠乙到底给出什么建议？细节往往就是如此。你获得的是对细节的具体描述，而对“到底要做成什么”和“为什么这么做”毫无头绪！
当然，真正的职业木匠可不会这样说话，真实的情形如此：
木匠甲：我们应该用鸠尾榫还是斜榫？
和上面对话本质的区别是他们在讨论问题的解决方案的差别，外行听不出来，而其中含义却非常丰富。
斜榫：更容易制作，只需将制作榫的木料锯出45度的斜面，然后用钉子或木胶结合起来既可。重压下无法保持接合，不引人注目。
鸠尾榫：对外行人来说可能并不清楚，但每一个木匠都明白。它是一个坚固，可靠，美观的榫，如果制作精良，会很美观，但制作复杂，成本也较高。。
第一种情形，木匠乙讨论的事榫的实现细节，反而使气真正的问题变得模糊不清，在第二中情形中，木匠甲要根据榫的成本和接合性质来决定使用哪种榫。
谁更有效呢？你更愿意和谁一起工作？
6． 目标
体会优秀设计的策略：
· 按接口编程
· 尽量用聚合代替继承
· 找出变化并封装之
-End-
