设计模式
设计模式
自用，大量内容来源于https://www.runoob.com/design-pattern/
设计原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
创建模式
单例模式 Singleton
一般使用spring中的bean工厂
1. 饿汉式
类加载到内存后，就实例化一个单例，JVM保证线程安全
简单实用
唯一缺点：不管用到与否，类装裁时就完成实例化
public class Singleton1{
private static final Singleton1 INSTANCE = new Singleton1();
private Singleton1(){};
public static Singleton1 getInstance(){return INSTANCE;}
// Singleton1 s1 = Singleton1.getInstance();
}
public class Singleton1{
private static final Singleton1 INSTANCE;
static{INSTANCE = new Singleton1();}
private Singleton1(){};
public static Singleton1 getInstance(){return INSTANCE;}
}
2. 懒汉式
懒加载
按需初始化，用到时才初始化
缺点：线程不安全(优化为在getInstance时加上synchronized,会使效率下降)
public class Singleton2{
private static Singleton2 INSTANCE;
private Singleton2(){};
public static Singleton2 getInstance(){
if(INSTANCE==null){
INSTANCE = new Singleton2();
}
return INSTANCE;
}
}
public class Singleton2{
private static Singleton2 INSTANCE;
private Singleton2(){};
public static synchronized Singleton2 getInstance(){
if(INSTANCE==null){
INSTANCE = new Singleton2();
}
return INSTANCE;
}
}
public class Singleton2{
private static Singleton2 INSTANCE;
private Singleton2(){};
public static Singleton2 getInstance(){
if(INSTANCE==null){
//双重检查,减少加锁代码量提升效率
synchronized(Singleton2.class){
if(INSTANCE==null){
INSTANCE = new Singleton2();
}
}
}
return INSTANCE;
}
}
3. 静态内部类方法
JVM保证单例
加载外部类时不会加载内部类,实现懒加载
public class Singleton3{
private Singleton3(){}
private static class Singleton3Holder{
private static final Singleton3 INSTANCE = new Singleton3();
}
public static Singleton3 getInstance(){
return Singleton3Holder.INSTANCE;
}
}
4. 枚举单例
枚举底层保证线程安全(枚举在第一次被真正用到的时候，会被虚拟机加载并初始化，而这个初始化过程是线程安全的)
解决线程同步,防止反序列化
public enum Singleton4{
INSTANCE;
public void whateverMethod() {
}
//Singleton4.INSTANCE;
}
工厂模式 Factory
工厂模式是用工厂方法代替new操作的一种模式。
简单工厂模式
简单工厂模式不属于GOF的23种经典设计模式，相当于一种编程习惯。
简单工厂模式包含如下三种角色：
- 抽象产品：定义了产品的规范，描述了产品的主要特性和功能。
- 具体产品：实现或者继承抽象产品的子类。
- 具体工厂：提供了创建产品的方法，使用者通过该方法来获取产品。
/**
* 创建一个抽象类：抽象子类的共有方法
* 创建子类实现父类的抽象方法
* 在工厂方法中根据类型创建不同的具体对象
**/
public class SimpleCoffeeFactory {
// 根据type判断类型，实例化并返回对应对象
public Coffee createCoffee(String type) {
Coffee coffee = null;
if("americano".equals(type)) {
coffee = new AmericanoCoffee();
} else if("latte".equals(type)) {
coffee = new LatteCoffee();
}
return coffee;
}
}
工厂处理创建对象的细节，一旦有了工厂，后期如果需要对象直接从工厂中获取即可。这样也就解除了和实现类的耦合，但同时又产生了新的耦合。后期如果再添加新的类，就必须修改工厂类的代码，违反了开闭原则。
静态工厂模式
在开发中也有一部分人将工厂类中的创建对象的功能定义为静态的，这个就是静态工厂模式，它也不是23种设计模式中的。
public class SimpleCoffeeFactory {
public static Coffee createCoffee(String type) {
Coffee coffee = null;
if("americano".equals(type)) {
coffee = new AmericanoCoffee();
} else if("latte".equals(type)) {
coffee = new LatteCoffee();
}
return coffe;
}
}
工厂方法模式
针对简单工厂模式的缺点，使用工厂方法模式就可以完美的解决，完全遵循开闭原则。
工厂方法模式（FACTORY METHOD）是一种常用的类创建型设计模式,此模式的核心精神是封装类中变化的部分，提取其中个性化善变的部分为独立类，通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。它的核心结构有四个角色，分别是抽象工厂、具体工厂、抽象产品、具体产品。
四个角色：
-
抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。
-
具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
-
抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
-
具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。
/**
* 抽象工厂
**/
public interface CoffeeFactory {
Coffee createCoffee();
}
/**
* 具体工厂
*
* 抽象产品为coffee，具体产品为LatteCoffee和AmericanCoffee
* 这种工厂模式可以通过不同的具体工厂创建出不同的具体产品
**/
public class LatteCoffeeFactory implements CoffeeFactory {
public Coffee createCoffee() {
return new LatteCoffee();
}
}
public class AmericanCoffeeFactory implements CoffeeFactory {
public Coffee createCoffee() {
return new AmericanCoffee();
}
}
工厂方法模式是简单工厂模式的进一步抽象。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。
优点：
在获取对象时只需要知道具体工厂的名称就可以得到对应的对象，无须知道具体创建过程；在系统增加新的类时只需要添加对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；
缺点：
每增加一个类就要增加一个对应的具体工厂类，增加了系统的复杂度。
抽象工厂模式
抽象工厂是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂是指当有多个抽象角色时使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体情况下，创建多个产品族中的产品对象。
工厂模式中的每一个形态都是针对一定问题的解决方案，工厂方法针对的是多个产品系列结构；而抽象工厂模式针对的是多个产品族结构，一个产品族内有多个产品系列。
抽象工厂模式的主要角色如下：
- 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法，可以创建多个不同等级的产品。
- 具体工厂（Concrete Factory）：主要是实现抽象工厂中的多个抽象方法，完成具体产品的创建。
- 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。
- 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它 同具体工厂之间是多对一的关系。
/**
* 抽象工厂
**/
public interface DessertFactory {
Coffee createCoffee();
Dessert createDessert();
}
/**
* 具体工厂
**/
public class AmericanDessertFactory implements DessertFactory {
public Coffee createCoffee() {
return new AmericanCoffee();
}
public Dessert createDessert() {
return new MatchaMousse();
}
}
public class ItalyDessertFactory implements DessertFactory {
public Coffee createCoffee() {
return new LatteCoffee();
}
public Dessert createDessert() {
return new Tiramisu();
}
}
优点：
当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
缺点：
当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。
抽象工厂和行为工厂最主要的区别是使用场景以及产品和工厂的对应关系
构造者模式 Builder
建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。
意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
主要解决：主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
何时使用：一些基本部件不会变，而其组合经常变化的时候。
如何解决：将变与不变分离开。
关键代码：建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。
应用实例： 1、去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"。 2、JAVA 中的 StringBuilder。
优点： 1、建造者独立，易扩展。 2、便于控制细节风险。
缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。
使用场景： 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。
注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
原型模式 Prototype
原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。
意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
主要解决：在运行期建立和删除原型。
何时使用： 1、当一个系统应该独立于它的产品创建，构成和表示时。 2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。 3、为了避免创建一个与产品类层次平行的工厂类层次时。 4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
如何解决：利用已有的一个原型对象，快速地生成和原型对象一样的实例。
关键代码： 1、实现克隆操作，在 JAVA 实现 Cloneable 接口，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。 2、原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些"易变类"拥有稳定的接口。
应用实例： JAVA 中的 Object clone() 方法。
优点： 1、性能提高。 2、逃避构造函数的约束。
缺点： 1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 2、必须实现 Cloneable 接口。
使用场景： 1、资源优化场景。 2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 3、性能和安全要求的场景。 4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5、一个对象多个修改者的场景。 6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。 7、在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。
注意事项：与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。
行为模式
策略模式 Strategy
本质：分离算法，选择实现。
策略模式：针对一组算法，将每一个算法封装到具有共同接口的独立的类中，使得它们可以互换。
封装了做一件事不同的执行方式
比如通过泛型指定不同类的多种排序方式
也可以通过抽象类的多种继承实现,使得算法部分解耦且可以快速自由切换
和工厂模式有一定类似,相比更偏向策略的切换,工厂模式更偏向于对象的创建
策略模式的收银软件
抽象类CashStrategy：定义收银的计算方法
CashContext角色：引用CashStrategy的一个实例
CashNormal是正常收费，CashRebate是打折收费，CashReturn是返利收费，是三个具体策略，客户端判断决定选择使用哪一个。
public abstract class CashStrategy {
public abstract double acceptCash(double money);
}
public class CashContext {
private CashStrategy cs;
public CashContext(CashStrategy cs) {
this.cs = cs;
}
public double getResult(double money) {
return cs.acceptCash(money);
}
}
public class CashNormal extends CashStrategy{
@Override
public double acceptCash(double money) {
// TODO Auto-generated method stub
return money;
}
}
public class CashRebate extends CashStrategy{
private double moneyRebate=0;
public CashRebate(double moneyRebate) {
this.moneyRebate = moneyRebate;
}
@Override
public double acceptCash(double money) {
return money*moneyRebate;
}
}
public class CashRetrun extends CashStrategy{
private double moneyCondition=0.0;
private double moneyReturn=0.0;
public CashRetrun(double moneyCondition, double moneyReturn) {
this.moneyCondition = moneyCondition;
this.moneyReturn = moneyReturn;
}
@Override
public double acceptCash(double money) {
double result=money;
if(money>moneyCondition)
result=money-Math.floor(money/moneyCondition)*moneyReturn;
//floor():向下取整
return result;
}
}
import java.util.Scanner;
public class Test {
static double total=0.0;
public static void main(String[] args) {
Scanner cin=new Scanner(System.in);
System.out.println("请输入优惠方案：");
String str=cin.next();
CashContext cc=null;
switch(str) {
case "正常收费":
cc=new CashContext(new CashNormal());
break;
case "满300返100":
cc=new CashContext(new CashRetrun(300,100));
break;
case "打8折":
cc=new CashContext(new CashRebate(0.8));
break;
}
System.out.println("请输入消费金额：");
double price=cin.nextInt();
total=cc.getResult(price);
System.out.println("最后共消费："+total);
cin.close();
}
}
策略模式的特点
功能：具体算法从具体业务处理中独立
多个if-else出现考虑使用策略模式
策略算法是形同行为的不同实现（多态）
客户端选择，上下文来具体实现策略算法
使用场景
同一个算法，有很多不同的实现情况。
一个定义了很多行为的类，通过多个if-else语句来选择这些行为的情况
优缺点
优点：
-
避免让客户端涉及到重要算法和数据
-
避免使用难以维护的多重条件选择语句
-
易扩展
缺点：
- 判断逻辑在客户端，需求改变时，要更改客户端的程序。
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。
- 增加了对象的数目
- 只适合扁平的算法结构
策略模式和工厂模式的结合
把分支判断从客户端移动到到环境CashContext类中，此时CashContext相当于一个工厂，选择实例化不同的具体策略类
public class CashContext {
private CashStrategy cs=null;
//简单工厂：将实例化具体策略从客户端放入Context类中
public CashContext(String type) {
switch(type) {
case "正常收费":
CashNormal cs0=new CashNormal();
cs=cs0;
break;
case "满300返100":
CashRetrun cr1=new CashRetrun(300,100);
cs=cr1;
break;
case "打8折":
CashRebate cr2=new CashRebate(0.8);
cs=cr2;
break;
}
}
public double getResult(double money) {
return cs.acceptCash(money);
}
}
import java.util.Scanner;
public class Test {
public static void main(String[] args) {
Scanner cin=new Scanner(System.in);
System.out.println("请输入优惠方案：");
String str=cin.next();
CashContext cc=new CashContext(str);
System.out.println("请输入消费金额：");
double price=cin.nextInt();
double total=cc.getResult(price);
System.out.println("最终消费："+total);
cin.close();
}
}
中介模式 | 调停者模式 Mediator
调节对象间内部关系
中介者模式（Mediator Pattern）提供了一个中介类，该类通常处理不同类之间的通信，降低多个对象和类之间的通信复杂性，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。
意图：中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
主要解决：对象与对象之间存在大量的关联关系
何时使用：多个类相互耦合，形成了网状结构。
如何解决：将上述网状结构分离为星型结构。
**应用实例： **MVC 框架，其中C（控制器）就是 M（模型）和 V（视图）的中介者。 消息中间件也属于中介模式
优点：
- 降低了类的复杂度，将一对多转化成了一对一。
- 各个类之间的解耦。
- 符合迪米特原则。
缺点：中介者会庞大，变得复杂难以维护。
使用场景：
-
系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。
-
想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。
注意事项：不应当在职责混乱的时候使用。
责任链模式 Chain of Responsibility
责任链（chain of responsibility）模式很像异常的捕获和处理，当一个问题发生的时候，当前对象看一下自己是否能够处理，不能的话将问题抛给自己的上级去处理，但是要注意这里的上级不一定指的是继承关系的父类，这点和异常的处理是不一样的。所以可以这样说，当问题不能解决的时候，将问题交给另一个对象去处理，就这样一直传递下去直至当前对象找不到下线了，处理结束。
通过责任链，我们可以将问题与处理问题的对象分离出来，特别适合用于不知道发生的问题到底是什么（有很多选择）但是又必须处理的情况（按照每个选择情况设计相应的处理类），这样就弱化了请求问题的人和回答问题的人的关系，如果不得不让发出请求的人知道处理请求的人，这样就不利于代码的复用，因为需要在请求问题的对象之中调用处理请求的对象，而使用责任链模式就能很好的规避这一点，便于将这部分代码独立出来，当做组件使用，符合开闭原则。
责任链模式主要是解耦了请求与处理，客户只需要将请求发送到链上即可，无序关心请求的是具体内容和处理细节，请求会自动进行传递直至有节点对象进行处理。适用与以下场景：
- 多个对象可以处理同一请求，但具体由那个对象处理则在运行时动态决定。
- 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
- 可动态指定一组对象处理请求。
案例
- 普通实现
import lombok.Data;
import java.util.ArrayList;
import java.util.List;
public class ChainOfResponsibility {
public static void main(String[] args) {
Msg msg = new Msg();
msg.setMsg("");
FilterChain fc = new FilterChain();
FilterChain fc2 = new FilterChain();
fc.add(new AFileter());
fc.add(new BFileter());
fc2.add(new CFileter());
fc2.add(new DFileter());
fc.add(fc2);
fc.doFileter(msg);
}
}
@Data
class Msg{
String msg;
String name;
}
interface Filter{
boolean doFileter(Msg m);
}
class FilterChain implements Filter{
List<Filter> filters = new ArrayList<>();
@Override
public boolean doFileter(Msg m) {
filters.forEach(x->x.doFileter(m));
return true;
}
public FilterChain add(Filter filter){
this.filters.add(filter);
return this;
}
}
class AFileter implements Filter{
@Override
public boolean doFileter(Msg m) {
System.out.println("A");
return true;
}
}
class BFileter implements Filter{
@Override
public boolean doFileter(Msg m) {
System.out.println("B");
return true;
}
}
class CFileter implements Filter{
@Override
public boolean doFileter(Msg m) {
System.out.println("C");
return true;
}
}
class DFileter implements Filter{
@Override
public boolean doFileter(Msg m) {
System.out.println("D");
return true;
}
}
- 责任链模式过滤request的时候是顺序，过滤response的时候是逆序的实现思路
//某个具体过滤器的实现
class FFilter implements Filter{
@Override
public boolean doFileter(Request request,Response response,FilterChain fc) {
//递归保证执行顺序为request顺序执行,response逆序执行
xxxMethod4Request(request);
fc.doFileter(Request request,Response response,FilterChain fc);
xxxMethod4Response(response);
return true;
}
}
//某个过滤链的实现
class FilterChain implements Filter{
List<Filter> filters = new ArrayList<>();
int idx = 0;
@Override
public boolean doFileter(Request request,Response response,FilterChain fc) {
//建立一个索引，保证每次执行的都是下一个过滤器
if(idx>filters.size()-1) {
return false;
}
Filter f = filters.get(idx)
idx++;
return f.doFileter(request,response,fc);
}
public FilterChain add(Filter filter){
this.filters.add(filter);
return this;
}
}
观察者模式 Observer
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。
意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
如何解决：使用面向对象技术，可以将这种依赖关系弱化。
关键代码：在抽象类里有一个 ArrayList 存放观察者们。
优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。
缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
使用场景：
- 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
- 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
- 一个对象必须通知其他对象，而并不知道这些对象是谁。
- 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。
注意事项： 1、JAVA 中已经有了对观察者模式的支持类。 2、避免循环引用。 3、如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。
aop切面也可以理解为一种观察者模式(并不是说它就是,思路上有相似之处)
以下内容都属于观察者模式
- Observer
- Linstener
- Hook
- Callback
迭代器模式 Iterator
迭代器模式（Iterator Pattern）是 Java 和 .Net 编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。
意图：提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
主要解决：不同的方式来遍历整个整合对象。
何时使用：遍历一个聚合对象。
如何解决：把在元素之间游走的责任交给迭代器，而不是聚合对象。
关键代码：定义接口：hasNext, next。
应用实例：JAVA 中的 iterator。
优点： 1、它支持以不同的方式遍历一个聚合对象。 2、迭代器简化了聚合类。 3、在同一个聚合上可以有多个遍历。 4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
缺点：由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
使用场景： 1、访问一个聚合对象的内容而无须暴露它的内部表示。 2、需要为聚合对象提供多种遍历方式。 3、为遍历不同的聚合结构提供一个统一的接口。
注意事项：迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。
访问者模式 Visitor
在访问者模式（Visitor Pattern）中，我们使用了一个访问者类，它改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者改变而改变。这种类型的设计模式属于行为型模式。根据模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象上的操作。
意图：主要将数据结构与数据操作分离。
主要解决：稳定的数据结构和易变的操作耦合问题。
何时使用：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。最主要用于编译器的实现
如何解决：在被访问的类里面加一个对外提供接待访问者的接口。
关键代码：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。
应用实例：您在朋友家做客，您是访问者，朋友接受您的访问，您通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。
优点： 1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。
缺点： 1、具体元素对访问者公布细节，违反了迪米特原则。 2、具体元素变更比较困难。 3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
使用场景： 1、对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作。 2、需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，也不希望在增加新操作时修改这些类。
注意事项：访问者可以对功能进行统一，可以做报表、UI、拦截器与过滤器。
命令模式 Command | Action | Transaction
命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。do() undo()
意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决：通过调用者调用接受者执行命令，顺序：调用者→命令→接受者。
关键代码：定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口
应用实例：struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。
优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
使用场景：认为是命令的地方都可以使用命令模式，比如： 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。
注意事项：系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作，也可以考虑使用命令模式，见命令模式的扩展。
备忘录模式 Memento
备忘录模式（Memento Pattern）保存一个对象的某个状态，以便在适当的时候恢复对象。备忘录模式属于行为型模式。
意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
主要解决：所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
何时使用：很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有"后悔药"可吃。
如何解决：通过一个备忘录类专门存储对象状态。
关键代码：客户不与备忘录类耦合，与备忘录管理类耦合。
应用实例： 1、打游戏时的存档。 2、Windows 里的 ctrl + z。 3、IE 中的后退。 4、数据库的事务管理。5、快照机制
优点： 1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
使用场景： 1、需要保存/恢复数据的相关状态场景。 2、提供一个可回滚的操作。
注意事项： 1、为了符合迪米特原则，还要增加一个管理备忘录的类。 2、为了节约内存，可使用原型模式+备忘录模式。
模板模式 Template
在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
主要解决：一些方法通用，却在每一个子类都重新写了这一方法。
何时使用：有一些通用的方法。
如何解决：将这些通用算法抽象出来。
关键代码：在抽象类实现，其他步骤在子类实现。
应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。3、钩子函数
优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。
缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。
注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。
状态模式 State
在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。
意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
何时使用：代码中包含大量与对象状态有关的条件语句。
如何解决：将各种具体的状态类抽象出来。
关键代码：通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。
应用实例： 1、tcpconnection 2、有限状态机FSM 3、线程状态
优点： 1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点： 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
使用场景： 1、行为随状态改变而改变的场景。 2、条件、分支语句的代替者。
注意事项：在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。
TcpConnection在不同状态下调用open()与close()会产生不同的操作,对于TcpState的创建解决了在open\close中各自进行if-else判断的高耦合
解释器模式 Interpreter
几乎不会使用
解释器模式（Interpreter Pattern）提供了评估语言的语法或表达式的方式，它属于行为型模式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在 SQL 解析、符号处理引擎等。
意图：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。
主要解决：对于一些固定文法构建一个解释句子的解释器。
何时使用：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
如何解决：构建语法树，定义终结符与非终结符。
关键代码：构建环境类，包含解释器之外的一些全局信息，一般是 HashMap。
应用实例：编译器、运算表达式计算。
优点： 1、可扩展性比较好，灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法。
缺点： 1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。
使用场景： 1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。 2、一些重复出现的问题可以用一种简单的语言来进行表达。 3、一个简单语法需要解释的场景。
注意事项：可利用场景比较少，JAVA 中如果碰到可以用 expression4J 代替。
结构模式
门面模式 | 外观模式 Facade
外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。门面模式又称为外观模式，它是一种对象结构型模式。
门面模式一共有两种角色：
门面角色：客户端调用这个角色的方法。此角色知晓相关的子系统的功能和责任。正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统中去。
子系统角色：可以同时有一个或者多个子系统。每个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色直接调用。子系统并不知道门面的存在，罪域子系统而言，门面仅仅是另一个客户端而已。
优缺点
优点：
- 对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入门面模式，客户代码将变得很简单，与之关联的对象也很少。
- 实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
- 降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
- 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。
缺点：
- 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
- 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
使用场景
- 当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求，而且用户也可以越过外观类直接访问子系统。
- 客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦，可以提高子系统的独立性和可移植性。
- 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。
注意事项
一个系统有多个外观类
在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。
不要试图通过外观类为子系统增加新行为
不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
外观模式与迪米特法则
外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少，使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
抽象外观类的引入
外观模式最大的缺点在于违背了“开闭原则”，当增加新的子系统或者移除子系统时需要修改外观类，可以通过引入抽象外观类在一定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。
装饰器模式 Decorator
指在不改变原有对象结构的基础情况下，动态地给该对象增加一些额外功能的职责。装饰器模式相比生成子类更加灵活。它属于对象结构型模式。
通常情况下，扩展一个类的功能会使用继承方式来实现。但继承具有静态特征，耦合度高，并且随着扩展功能的增多，子类会很膨胀。如果使用组合关系来创建一个包装对象（即装饰对象）来包裹真实对象，并在保持真实对象的类结构不变的前提下，为其提供额外的功能，这就是装饰模式的目标。
装饰模式主要包含四个角色:
- 抽象构件（Component）： 可以是一个接口或者抽象类，充当被装饰类的原始对象，规定了被装饰类的行为。
- 具体构件（ConcreteComponent）： 实现/继承 Component的一个具体对象，即被装饰对象。通过装饰角色为其添加一些职责。
- 抽象装饰器（Decorator）： 实现/继承 Component。通用的 ConcreteComponent的装饰列，其内部必然有一个属性指向 Component，主要是可以通过其子类扩展具体组件的功能。
- 具体装饰器（ConcreteDecorator）： Decorator的具体实现类，并给具体构件对象添加附加的责任，一般为其特有的功能。
优缺点
优点：
- 装饰器是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用
- 通过使用不用装饰类及这些装饰类的排列组合，可以实现不同效果
- 装饰器模式完全遵守开闭原则
缺点：
- 会出现更多的代码、更多的类，增加程序的复杂性。
使用场景
- 当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。
- 当对象的功能要求可以动态地添加，也可以再动态地被撤销时。
- 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰模式却很好实现。
在框架源码中使用也很广泛，比如：
- JDK中的处理流 IO中包装流类等
- Spring 中处理事务缓存的 TransactionAwareCacheDecorator类
- Mybatis 中处理缓存设计的 Cache类等
//日志装饰器
public class LogDecorator implements DataService {
private final DataServiceImpl dataService;
public LogDecorator(DataServiceImpl dataService) {
this.dataService = dataService;
}
@Override
public String getData() {
System.out.println("method invoke");
final String data = dataService.getData();
System.out.println("method finish");
return data;
}
}
//缓存装饰器
public class CacheDecorator implements DataService {
private final LogDecorator logDecorator;
private final Map<String, String> map;
public CacheDecorator(LogDecorator logDecorator) {
this.logDecorator = logDecorator;
this.map = new HashMap<>();
}
@Override
public String getData() {
String value = map.get("getData");
if (value == null) {
value = logDecorator.getData();
map.put("getData", value);
}
return value;
}
}
aop与decorator
装饰器强调不改变原有内容的情况下进行拓展,aop更属于原有内容的增强
Aop我个人觉得应该是动态代理(代理模式) + 责任链模式的产物，仅有动态代理，没有责任链模式是难以完成aop的设计的，或者说aop的功能是不完善的。
装饰器模式:装饰器是指对原有对类进行了一次装饰，并且增添了新对功能，实际案例，参考mybatis对缓存设计，在SimpleExector对上一层添加了CacheExector，在CacheExector中对实际操作还是委托给SimpleExector去完成，只是在操作前增加了缓存，这个就是装饰器模式的典型运用。
代理模式:代理模式也能够做到一层缓存的功能，但是实现的功能可以是一样的，但是实现的过程是不一致的，一个是切切实实的写了一个类，一个是运行期生成的一个类，真要纠结的话，只能说代理模式可以产生装饰器模式的功能，还是已mybatis举例，参考mybatis-spring包下的SqlSessionTemplate，这个类的内部就存在一次动态代理，他的功能就是调用Session的方法，你说我用装饰器模式能不能实现，也能啊，没有那么方便，我要是多装饰器几次，类的关系就乱了。
综合来说，就是两个或者3个设计模式各有各的使用场景。
链接：https://www.zhihu.com/question/301769728/answer/527932258
组合模式 Composite
组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。
这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。
意图：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。
何时使用： 1、您想表示对象的部分-整体层次结构（树形结构）。 2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
如何解决：树枝和叶子实现统一接口，树枝内部组合该接口。
关键代码：树枝内部组合该接口，并且含有内部属性 List，里面放 Component。
应用实例： 1、算术表达式包括操作数、操作符和另一个操作数，其中，另一个操作数也可以是操作数、操作符和另一个操作数。 2、在 JAVA AWT 和 SWING 中，对于 Button 和 Checkbox 是树叶，Container 是树枝。
优点： 1、高层模块调用简单。 2、节点自由增加。
缺点：在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。
使用场景：部分、整体场景，如树形菜单，文件、文件夹的管理。
注意事项：定义时为具体类。
享元模式 FlyWeight
享元模式（Flyweight Pattern）主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。
享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。我们将通过创建 5 个对象来画出 20 个分布于不同位置的圆来演示这种模式。由于只有 5 种可用的颜色，所以 color 属性被用来检查现有的 Circle 对象。
意图：运用共享技术有效地支持大量细粒度的对象。
主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。
何时使用： 1、系统中有大量对象。 2、这些对象消耗大量内存。 3、这些对象的状态大部分可以外部化。 4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。 5、系统不依赖于这些对象身份，这些对象是不可分辨的。
如何解决：用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。
关键代码：用 HashMap 存储这些对象。
应用实例： 1、JAVA 中的 String，如果有则返回，如果没有则创建一个字符串保存在字符串缓存池里面。 2、数据库的数据池。
优点：大大减少对象的创建，降低系统的内存，使效率提高。
缺点：提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。
使用场景： 1、系统有大量相似对象。 2、需要缓冲池的场景。
注意事项： 1、注意划分外部状态和内部状态，否则可能会引起线程安全问题。 2、这些类必须有一个工厂对象加以控制。
代理模式 Proxy
静态代理 | 动态代理 | spring-aop
在代理模式（Proxy Pattern）中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。
在代理模式中，我们创建具有现有对象的对象，以便向外界提供功能接口。
意图：为其他对象提供一种代理以控制对这个对象的访问。
主要解决：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。
何时使用：想在访问一个类时做一些控制。
如何解决：增加中间层。
关键代码：实现与被代理类组合。
应用实例： 1、Windows 里面的快捷方式。 2、买火车票不一定在火车站买，也可以去代售点。3、一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。 4、spring aop 5、java.lang.reflect.Proxy动态代理 6、Instrument拦截修改二进制码 lombok？ cglib实现动态代理。
优点： 1、职责清晰。 2、高扩展性。 3、智能化。
缺点： 1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。
使用场景：按职责来划分，通常有以下使用场景： 1、远程代理。 2、虚拟代理。 3、Copy-on-Write 代理。 4、保护（Protect or Access）代理。 5、Cache代理。 6、防火墙（Firewall）代理。 7、同步化（Synchronization）代理。 8、智能引用（Smart Reference）代理。
注意事项： 1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。 2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
适配器模式 Adapter | Wrapper
适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。
这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。
意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
主要解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。
何时使用： 1、系统需要使用现有的类，而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）
如何解决：继承或依赖（推荐）。
关键代码：适配器继承或依赖已有的对象，实现想要的目标接口。
应用实例： 1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。
FileInputStream fis = new FileInputStream("x.txt");
//isr的作用就相当于一个适配器
InputStreamReader isr = new InputStreamReader(fis);
BufferedReader br = new BufferedReader(isr);
String line = br.readLine();
while(line!=null&&!line.equals("")){
sout(line);
}
br.clost();
优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。
缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。
使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。
注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。
桥接模式 Bridge
用到不多
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。
意图：将抽象部分与实现部分分离，使它们都可以独立的变化，自主随意切换抽象和具体两边
主要解决：在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。
何时使用：实现系统可能有多个角度分类，每一种角度都可能变化。
如何解决：把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。
关键代码：抽象类依赖实现类。
应用实例：
优点： 1、抽象和实现的分离。 2、优秀的扩展能力。 3、实现细节对客户透明。
缺点：桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。
使用场景： 1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。 2、对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。 3、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。
注意事项：对于两个独立变化的维度，使用桥接模式再适合不过了。
