设计模式入门：策略模式

使用继承，会有哪些缺点？

代码在多个子类中重复
运行时的行为不容易改变
很难知道所有子类的操作
改动会牵一发而动全身

Java接口不具有实现代码，所以继承接口无法达到代码的复用。这意味着：无论何时你需要修改某个行为，你必须得往下追踪并在每一个定义此行为的类中修改它，一不小心，可能会造成新的错误。

设计原则

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
即：把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分

设计原则

针对接口编程，而不是针对实现编程

针对接口编程

关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上

设计原则

多用组合，少用继承
使用组合建立系统具有很大的弹性，不仅可将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可

策略模式

定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

个人理解：用接口 + 抽象的方式，将常变的和不常变的区分开来，不常变的可以放在抽象类中，常变的放在接口里。同时，如果要支持多态，可以在抽象类中定义接口，通过setter进行改变行为。
Java8中，接口也支持实现具体方法了。使得平时开发中，我更偏向于用接口解决问题。

观察者模式

出版者（主题） + 订阅者（观察者） = 观察者模式

观察者模式

定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

设计原则

为了交互对象之间的松耦合设计而努力
松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低

示例

Java内置的Observer & Observable
Spring的@eventListener

装饰者模式

设计原则

类应该对扩展开放，对修改关闭

装饰者与被装饰对象有相同的超类
可以用一个或多个装饰者包装一个对象
既然装饰者和被装饰对象有相同的超类，所以在任何需要原始对象（被包装的）的场合，可以用装饰过的对象代替它
装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的
对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象

装饰者模式

动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案

缺点

利用装饰者模式，常常造成设计中有大量的小类，数量实在太多，可能会造成使用此API程序员的困扰

工厂模式

工厂方法模式

定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

设计原则 -> 依赖倒置原则

要依赖抽象，不要依赖具体类

指导方针，避免在OO设计中违反依赖倒置原则

变量不可以持有具体类的实现
如果使用new，就会持有具体类的引用。可以改用工厂来避开这样的做法
不要让类派生自具体类
如果派生自具体类，就会依赖具体类。请派生自一个接口/抽象类
不要覆盖基类中已实现的方法
如果覆盖基类已实现的方法，那么你的基类就不是一个真正适合被继承的抽象。基类中已实现的方法，应该由所有的子类共享。

抽象工厂模式

提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类

简单工厂模式、工厂模式、抽象工厂模式的区别

单件模式

确保一个类只有一个实例，并提供一个全局访问点

单例模式中的：懒汉模式、饿汉模式、懒汉加锁模式、双重检查的懒汉加锁模式

命令模式

将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

适配器模式与外观模式

一个适配器只能够封装一个类吗？

适配器模式的工作是将一个接口转换成另一个。虽然大多数的适配器模式所采取的例子都是让一个适配器包装一个被适配者，但我们可能遇到一些状况，需要让一个适配器包装多个被适配者。
这涉及另一个模式，被称为外观模式。

适配器模式

将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

适配器模式和外观模式的区别

两种模式的差异，不在于它们“包装”了几个类，而是在于它们的意图。
适配器模式的意图是，“改变”接口符合客户的期望；
而外观模式的意图是，提供子系统的一个简化接口。

外观模式

提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

设计原则

最少知识原则：只有你的密友谈话。
即：减少对象之间的交互，只留下几个“密友”。

在该对象的方法内，我们只应该调用属于以下范围的方法：

该对象本身
被当做方法的参数而传递进来的对象
此方法所创建或实例化的任何对象
对象的任何组件

如果调用从一个调用中返回的对象的方法，会有什么害处呢？

如果我们这样做，相当于向另一个对象的子部分发请求（而增加我们直接认识的对象数目）。

采用最少知识原则有什么缺点？

采用这个原则会导致更多的“包装”类被制造出来，以处理和其他组件的沟通，这可能会导致复杂度和开发时间的增加，并降低运行时的性能。

模板方法模式

在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

对模板方法进行挂钩

钩子是一种被声明的抽象类中的方法，但只有空的或者默认的实现。钩子的存在，可以让子类有能力对算法的不同点进行挂钩。要不要挂钩，由子类自行决定。

使用钩子真正的目的是什么？

钩子有几种用法。如我们之前所说的，
(1) 钩子可以让子类实现算法中可选的部分，或者在钩子对于子类的实现并不重要的时候，子类可以对此钩子置之不理。
(2) 钩子的另一个用法，是让子类能够有机会对模板方法中某些即将发生的（或刚刚发生的）步骤作出反应。

好莱坞原则

别调用（打电话给）我们，我们会调用（打电话给）你。

★迭代器与组合模式

迭代器模式

提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。

设计原则

一个类应该只有一个引起变化的原因。

★组合模式

允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

Q：组合模式不但要管理层次结构，而且还要执行菜单的操作。破坏了：一个类，一个责任的原则。
A：组合模式以单一责任设计原则换取透明性。什么是透明性？通过让组件的接口同时包含一些管理子节点和叶节点的操作，客户就可以将组合和叶节点一视同仁。也就是说，一个元素究竟是组合还是叶子节点，对客户是透明的。