# 《Head First设计模式》
设计模式是某些问题、场景的代码解决方案，这些方案是业界已经存在的，然后归纳起来方便沟通的，如同建筑行业房屋设计有不同的设计风格实现客户的不同需求。
读这本书的脑力消耗还是挺多的，如果不是用了Java一段时间的还真不适合阅读，哎呀，我又要去补充Java知识了！
阅读时间：2020年9月6日 耗时：3小时5分
# 第1章：设计模式入门
在软件开发上，一直伴随你的那个不变真理是什么？ CHANGE
第一个设计原则：找出应用中可能需要改变之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
第二个设计原则：针对接口编程，而不是针对实现编程。
"针对接口编程"，关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状态执行到真正的行为，不会被绑死在超类型的行为上。
第三个设计原则：多用组合，少用继承。
策略模式：定义了算法族，分别封装起来，让它们之间可以互相替换， 此模式让算法的变化独立于使用算法的客户。
良好的OO设计必须具备可复用、可扩充、可维护三个特性。
# 第2章：观察者模式
观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者迪欧回收到通知并自动更新。
第四个设计原则：为了交互对象之间的松耦合设计而努力。
# 第3章：装饰对象
第四个设计原则：类应该对扩展开放，对修改关闭。
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
通常装饰者模式是采用抽象类，但是在Java中可以使用接口。
# 第4章：工厂模式
工厂方法模式能够封装具体类型的实例化。
工厂方法让子类决定要实例化的类是哪一个。希望不要理解错误，所谓的"决定"，并不是指模式允许子类本身在运行时做决定，而是指在编写创建者类时，不需要知道实际创建的产品时哪一个。选择了使用哪个子类，自然就决定了实际创建的产品时什么。
第五个设计原则：要依赖抽象，不要依赖具体类。
避免违反依赖倒置原则：
- 变量不可以持有具体类的引用
- 不要让类派生自具体类
- 不要覆盖基类中已实现的方法
抽象工厂模式提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
利用工厂方法创建对象，需要扩展一个类，并覆盖它的工厂方法。
# 第5章：单件模式
单件模式确保一个类只有一个实例，并提供一个全局访问点。
单件模式构造器时声明为私有的。
# 第6章：命令模式
命令模式将『请求』封装成对象，以便使用不同的请求，队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
# 第7章：适配器模式与外观模式
适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
适配器模式的意图是，『改变』接口符合客户的期望；而外观模式的意图是提供子系统的一个简化接口。
外观模式提供一个一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
第六个设计原则：最少知识原则：只和你的密友谈话。
- 当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器。
- 当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。
# 第8章：模板方法模式——封装算法
模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟在子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
abstract class AbstractClass {
final void template method() {
primitiveOperation1();
primitiveOperation2();
concreteOperation();
}
abstract void primitiveOperation1();
abstract void primitiveOperation2();
void concreteOperation() {
// 这里是实现
}
}
2
3
4
5
6
7
8
9
10
11
12
当你的子类『必须』提供算法中某个方法或步骤的实现时，就使用抽象方法。如果算法的这个部分是可选的，就用钩子。如果是钩子的话，子类可以选择实现这个钩子，但并不强制这么做。
好莱坞原则：别调用我们，我们会调用你。
# 第9章：迭代器与组合模式
迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。
第七个设计原则：一个类应该只有一个引起变化的原因。
组合模式：允许你将对象组合成树形结构来表现『整体/部分』层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。
# 第10章：状态模式
状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
# 第11章：代理模式
代理模式：为另一个对象提供一个替身或占位符以控制对这个对象的访问。
# 第12章：复合模式
复合模式：结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。
# 第13章：与设计模式相处
模式是在某情景（context）下，针对某问题的某种解决方案。
如果你发现自己处于某个情境下，面对着所欲达到的目标被一群约束影响着的问题，然而，你能够应用某个设计，克服这些约束并达到该目标，将你领向某个解决方案。
模式是一种被证实过的设计经验，可以避免某些常见的错误。模式也是一种共享的词汇，能够让我们和其他开发人员沟通我们的设计。
警告：过度使用设计模式可能导致代码被过度工程化。应该总是用最简单的解决方案完成工作，并在真正需要模式的地方才使用它。
反模式告诉你如何采用一个不好的解决方案解决一个问题。
# 附录：剩下的模式
- 桥接
- 生成器
- 责任链
- 蝇量
- 解释器
- 中介者
- 备忘录
- 原型