1. 李健忠语录：
   1. 模式间的区别，对OO的理解(封装变化点，当系统在这个地方变化是用这种设计模式，在那个地方变化的时候用那种设计模式)
   2. 系统中总有一种趋势，一部分东西倾向与变化慢，有一部分变化快。找到变化快的，封装起来。
   3. 理解问题的提出更重要。如果系统中没有某种变化的需求，没有必要应用某种设计模式
   4. 在学习和使用设计模式的过程中遵循一个简洁性的原则。
   5. 对一个设计模式理解得非常深刻的情况下，再去用。还有对问题领域的分析。
   6. 简洁性。非常灵活的应对变化。一开始把问题想复杂，等于搬石头砸自己脚
   7. 互联网就是无数个简洁的link
   8. 变化是软件设计的永恒主题，如何管理变化带来的复杂性？设计模式的艺术性和复杂度就在于如何分析，并发现系统中的变化点和稳定点，并使用特定的设计方法来应对这种变化。
   9. 语言与设计模式间的探讨
   10. 变化是绝对的，我们要找出相对变，和相对不变的。
   11. 任何一门技术，仔细的体会，仔细的思考，肯定就会很简单。其中有很多的智慧在里面。
   12. 好的答案不重要，好的问题才重要。好的问题可以让我们思考很久，彻夜不眠。
   13. 模式入门非常重要，跨进模式的门槛和在门槛之外的区别是非常明显的。
   14. 我也是个技术狂。
   15. 初学者注意资源，不要随便去看一本书。
   16. 学会一个正确观念：不管是怎样一项新技术来了。利用我们已有的知识，利用对计算机系统的理解，首先获得一个正确的观念。再次通过一些练习掌握语法层面的东西。
   17. 一定切忌要专不要泛。静下心来学习，宁静至远！
   18. 软件开发两个思维方向：
       1. 底层思维
       2. 抽象思维
       3. 面向对象的最大优势在于抵御变化。好的软件设计一定会有良好的利用性。这是软件设计的金科玉律
   19. 耦合是软件不能抵御变化灾难的根本原因。
   20. 简单不是我们拒绝的理由。对简单性和复杂性有一个更好的态度。应该把代码，软件最好的简单化。
   21. 满足人的需要的前提下，追求一种简单，优雅的方案
   22. 简单性，复杂性是软件界永恒的话题。如何管理，隐藏复杂性。
2. 模式分类
   1. 从目的看:
      1. 创建型模式(Creational)
         1. 单例模式
            1. 动机:
            2. 软件系统中，经常需要一个类只能存在一个实例
            3. 如何绕过常规构造器，提供一种机制解决一个类只有一个实例
            4. 这应该是类设计者的责任，而不是使用者责任
            5. 意图:
            6. 保证一个类仅有一个实例，并提供一个该实例的全局访问点
            7. 实现：
            8. 单线程
            9. 要点：
            10. 实例构造器可设置protected以允许子类派生
            11. 不要支持ICloneable接口，可能导致多个对象实例
            12. 不要支持序列化，也可能导致多个对象实例
            13. 只考虑了对象的创建管理，没有考虑对象销毁的管理(.net支持垃圾回收的机制，一般没有必要对其销毁进行特殊管理)
            14. 不能应对多线程的环境
            15. 多线程
            16. 使用lock锁定
            17. 静态初始化,静态构造函数(不支持参数)
            18. 扩展：
            19. 将一个实例扩展到N个实例（N为固定的个数），如对象池的实现
            20. 将new构造器的调用转移到其它类中
            21. 理解扩展Singleton模式的核心：如何控制用户使用new对一个类的实例构造器的任意调用
         2. 抽象工厂(abstract factory)
            1. new的问题
            2. 实现依赖，不能应对“具体实例化类型”的变化
            3. 常规对象创建方法:Class class=new Class();
            4. 解决思路：封装变化点-哪里变化，封装哪里。
            5. 工厂模式的缘起
            6. 变化点在“对象创建”因此就封装“对象创建”
            7. 面向接口编程-依赖接口，而非依赖实现
            8. 动机
            9. 在软件系统中，经常面临着“一系列相互依赖的对象”的创建；同时由于需求的变化，往往存在更多系列对象的创建工作
            10. 意图:
            11. 提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”无需指定它们具体的类
            12. 要点：
            13. 如果没有“多系列对象”构建的需求，没有必要使用它
            14. 抽象工厂主要应对“新系列”的需求变动，缺点在于难于应对新对象
         3. 生成器模式(Builder)
      2. 结构型模式(Structural)
         1. 适配器模式(adapter)
            1. 动机：
            2. 由于应用环境的变化，常常需要将“一些现存的对象”放到新的环境中应用，但新环境的要求的接口是这些现在对象所不满足的
            3. 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时双能满足新的环境所要求的接口
            4. 意图
            5. 将一个类的接口转换成客户希望的另一个接口。adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
            6. 结构
            7. 对象适配器
            8. 类适配器
         2. Facade外观模式
            1. 系统的复杂度
            2. 多个子系统组成一个大的系统
      3. 行为型模式(Behavioral)
         1. 模板方法(Template Method)
            1. 动机：
            2. 在软件构造过程中，对某项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，而无法和任务的整体结构同时实现。
            3. 比如一个组件平台的开发商，开发出来的东西要给二线的应用程序开发人员使用，其要在组件平台的基础上开发。
            4. 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或晚期实现需求？
            5. 意图：
            6. 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可不改变一个算法的结构即可重定义该算法的某些特定步骤。
            7. 要点：
            8. 非常基础的设计模式。用最简洁的机制(虚函数的多态性)，是代码复用方面的基本实现结构。
            9. “不要调用我，让我来调用你”的反射控制结构是模板方法的典型应用。
            10. 被调用的虚方法可以具有实现，也可以没有实现。一般推荐设为protected方法。
            11. 一个面向对象系统肯定有模板方法模式的一个体现。肯定有大量的应用。
            12. .net架构中的应用
            13. winform中onpaint方法，webform中onload方法等
         2. 命令模式(Command)
            1. 动机：
            2. 子主题 1
   2. 从范围来看:
      1. 类模式
      2. 对象模式
3. 面向对象设计模式与原则
   1. 不熟悉一个模式跟不会一个模式是一样的(掌握其内部结构，灵活复用)
   2. 人是经验性的动物。生活中基于经验的
   3. 每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心——Christopher Alexander
   4. 设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。
   5. 面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间的常见组织关系。
   6. 面向对象设计模式解决的是“类与相互通信的对象之间的组织关系”
   7. 所谓好的面向对象设计是那些可以满足“应对变化，提高复用”的设计。
   8. 设计模式不是只是写一些代码案例，是要用到实际的软件开发中的
   9. 面向对象三大机制
      1. 封装：隐藏内部实现
      2. 继承：利用现有代码
      3. 多态：改写对象行为
   10. 使用面向对象编程语言，可以推动程序员以面向对象的思维来思考软件设计结构，从而强化面向对象的编程范式。
   11. 面向对象首先是设计，其次才是实现
   12. 任何一个的严肃面向对象程序员，都需要系统学习面向对象的知识，单纯地人编程语言上获得面向对象知识，不能够胜任面向对象设计与开发
   13. 认识面向对象
       1. 宏观层面：面向对象更能适应软件的变化
       2. 微观：更强调各个类的“责任”