《大话设计模式》笔记摘要 （一）

前言

1. 知道精彩的代码时如何想出来的，要比看到精彩的代码更加令人期待。
2. 如果想要成为一名更优秀的软件设计师，了解优秀软件的演变过程比学习优秀设计本身更有价值，因为优秀的演变过程中蕴含着大智慧。

3. 重要的不是你将来会不会用到这些设计模式， 而是通过这些设计模式让你找到封装变化、对象间松耦合、针对接口编程的感觉。从而设计出易维护、易拓展、易复用、灵活性好的程序。

4. 设计模式 四种境界：

   • 没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕
   • 学了几个模式后，很开心，于是到处想着要用到自己学过的模式，于是时常造成误用模式而不自知。
   • 学完全部模式时，感觉诸多模式极为相似，无法分清模式间的差异，有困惑，但深知误用之害，应用之时有所犹豫。
   • 灵活应用模式，甚至不应用具体的某种模式也能设计出非常优秀的代码，以达到无剑胜有剑的境界。

第一章 简单工厂模式

1. 通过 封装、 继承、 多态把程序的耦合度降低。
2. 让业务逻辑和界面逻辑分离开。
3. 很容易变化的地方，应该考虑用一个单独的类来做这个创造实例的过程，这就是工厂。
4. 聚合(Aggregation)表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。
5. 合成(Composition,也有翻译为“组合”)是一种强“拥有”关系，体现在严格的部分和整体的关系，部分和整体的生命周期一样。
6. 编程是一门技术，更加是一门艺术。时常考虑如何让自己的代码更加简练，更加容易维护，容易拓展和复用，只有这样才可以真正得到提高。写出优秀的代码真的是一种很爽的事情。

第二章 策略模式

1. 面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同的属性和功能的对象的抽象集合才是类。
2. 策略模式(Strategy)：它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响使用算法的客户。
3. 策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。
4. 策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公用功能。
5. 策略模式的另一个优点就是简化了单元测试，因为每个算法都有自己的类，可以自己的接口单独测试。
6. 当不同的行为堆砌在一个类中，就很难避免使用条件语句来选择适合的行为。将这些行为封装在一个个独立的Strategy类中，可以在使用这些行为的类中消除条件语句。
7. 策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。
8. 基本的策略模式中，选择所用的具体实现的职责由客户端对象承担，并转给策略模式的Context对象。这本身并没有解除客户端需要选择判断的压力，而策略模式与简单工厂模式结合之后，选择具体实现的职责也可以有Context对象来承担，这就最大化的减轻了客户端的职责。
9. 任何变化都是需要成本的。但成本的高低还是有差异的。高手和菜鸟的区别就是高手可以花同样的代价获得最大的收益或者说做同样的事花最小的代价。面对同样的需求，当然是改动越小越好。

第三章 单一职责原则

1. 就一个类而言，应该仅有一个引起它变化的原因。
2. 单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。
3. 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。
4. 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离开。如果你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

第四章 开放－封闭原则

1. 开放－封闭原则： 软件实体（类、模块、函数等等）应该可以扩展但不可修改。
2. 对于扩展开放（Open for extension）,对于更改封闭(Closed for modification)
3. 怎样的设计才能面对需求的改变却可以保持相对的稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？（开闭原则）
4. 无论模块多么“封闭”，都会存在一些无法对之封闭的变化，既然不能完全封闭，设计人员必须对他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最可能发生的变化种类，然后构造抽象来隔离那些变化。等到变化发生的时候，立即采取行动，正所谓，同一个地方，摔第一跤不是你的错，再次在此摔跤就是你的不对了。
5. 在我们最初编写代码时，假设变化不会发生。当变化发生的时候，我们就创建抽象来隔离以后发生的同类变化。
6. 面对需求，对程序的改动是通过增加新代码进行的，而不是通过更改现有的代码。
7. 我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。
8. 开放－封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护，可扩展，可复用，灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

第五章 依赖倒转原则

1. 依赖倒转原则（依赖倒置原则）： A：高层模块不应该依赖于低层模块。两个都应该依赖抽象。 B：抽象不应该依赖细节。细节应该依赖抽象。
2. 抽象不应该依赖细节。细节应该依赖抽象，说白了就是要针对接口编程，不要对实现编程。
3. 世间万物都是遵循某种类似的规律，谁先把握了这些规律，谁就最早成为了强者。
4. 不管高层模块还是低层模块，它们都是依赖于抽象，具体一点就是接口或抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就使得无论高层模块还是低层模块都可以很容易的被复用。
5. 里氏代换原则(LISP)：子类型必须能够替代掉它们的父类型。 一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。
6. 只有子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
7. 由于有里氏替换原则，才使得开放－封闭成为了可能。
8. 由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。
9. 依赖倒转其实可以说是面向对象设计的标志，用哪种语言来实现不重要，如果编写时考虑的都是如何针对接口编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了。

第六章 装饰模式

1. 装饰模式（Decorator）：动态的给一个对象添加一些额外的职责，就增加功能来讲，装饰模式比生成子类要更为灵活。
2. Component是定义了一个对象接口，可以给这些对象动态地添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator，装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。
3. 装饰模式是利用SetComponent来对对象进行包装的。每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何添加到对象链当中。
4. 装饰模式是为已有功能动态地添加更多功能的一种方式。
5. 装饰模式的优点：把类中的装饰功能从类里移出去，简化了原有的类。有效地把类的核心职责和装饰功能区分开，可以去除相关类中重复的装饰逻辑。