第一章 理解设计模式
1.1 模式的定义
什么是模式？
模式是被命名的有组织的信息，他捕获了在一定语境（场景）中包含相关作用力的问题的解决方案的本质结构和内在含义，这种解决方案被证明是成功的。
模式包括3个部分：相关的上下文，与上下文相关的作用力系统和解决问题的方案。
*其实简单说也就是：模式的使用是在特定的环境下，处理特定问题的解决方案的通用思想。只有在环境和处理确定的情况下才可以选择正确的解决方案。
模式体现的就是平衡的思想。
模式的书写包括很多中，主要包括以下几个组成部分：
1.Name: 模式的名称反映描述的结构。但因长度有限不可能包含模式所描述的所有含义。
2.Problem：问题描述了模式的意图。（要解决的问题）
3.Context：即模式所适用的环境。
4.Forces：为了达到目标，各因素之间的相互作迎合制约，揭示了解决问题时需要考虑的各种代价。
5.Solution：解决方案给出问题的解决方法。
6.Example：实例。
7.Consenquence：在结果中需要描述应用魔术后系统的情况，其中既要描述模式的应用的效果，也要描述所付出的代价。
8.Relation Pattern：相关模式给出与这个模式相关的部分。
9.Known use：已知应用在现实中使用的实例。
1.2 GOF的设计模式与模式
GOF的实际模式与一般意义上的模式有很大区别。
GOF的设计模式与模式理论的区别是前者偏重于解决方案，而后者的描述更偏重于问题的描述。
在理解设计模式时，重点应该放在每个模式解决的场合和使用模式需要靠了的因素上。
1.3 理解模式的名称
1.4 理解模式的场景
1.5 理解模式中的作用力
1.6 理解模式的结果和代价
1.61 对象过多
1.62 更复杂的装配关系
1.63 测试难度加大
1.64 程序结构复杂
1.7 设计模式不能做什么
1.71 设计模式不是法则
模式理论的精髓之一就是模式的使用时有前提和代价的，模式是在某种前提下综合各方面因素后考虑得出的结果。
1.72 不能提高开发速度或者形象开发速度
在很多情况下关注的目标不是开发速度，而是程序的健壮性和可维护性。（不断的抽象、封装。对象、接口越来越多，结构越来越复杂。调试、测试越来越麻烦。当然快不了。）
1.73 不是万能的
设计模式的使用是自然而然的事情，很多情况下不使用模式是因为不需要，问题没有复杂到费用不可的程度。我们是为了设计而适用设计模式，而不是为了设计模式而设计。
当你的项目发现如有下列问题之一时，就要考虑重构代码，可能会有某种模式适合。
（1）代码无法进行单元测试。
（2）需求的变动总是导致代码的变动。
（3）有重复的代码存在。
（4）继承层次过多。
（5）隐藏的依赖过多。
*以上的话让人深有同感。
1.8 设计模式的非软件示例
1.9 小结
＝＝＝＝＝
模式是从解决具体问题抽象出来的，这种具体问题在特定的上下文中重复出现。也就是说，每个具体形式都对一种重复的问题采用重复的解决方案。