设计模式的艺术读书笔记

面向对象设计原则概述

单一职责原则

单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下：
单一职责原则（Single Responsibility Principle，SRP）：一个类只负责一个功能领域中的相应职责。或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

单一职责原则的核心思想是：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中；如果多个职责总是同时发生改变，则可将它们封装在同一类中。

开闭原则

开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则。开闭原则由Bertrand Meyer于1988年提出，其定义如下：
开闭原则（Open-Closed Principle，OCP）：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

里氏代换原则

其严格表述如下：如果对每个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。这个定义比较拗口且难以理解，因此一般使用它的另一个通俗版定义：
里氏代换原则（Liskov Substitution Principle，LSP）：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

在运用里氏代换原则时，应该将父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。程序运行时，子类实例替换父类实例，可以很方便地扩展系统的功能，无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。

依赖倒转原则

依赖倒转原则（Dependency Inversion Principle，DIP）：抽象不应该依赖于细节，细节应该依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

接口隔离原则

接口隔离原则（Interface Segregation Principle，ISP）：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

合成复用原则

合成复用原则（Composite Reuse Principle，CRP）：尽量使用对象组合，而不是继承来达到复用的目的。(继承更容易引起来复杂性，而且Java单继承的也有限制)

迪米特法则

迪米特法则（Law of Demeter，LoD）：一个软件实体应当尽可能少地与其他实体发生相互作用。
如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易。这是对软件实体之间通信的限制。迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。

创建的艺术

创建型模式

创建型模式（Creational Pattern）关注对象的创建过程，是一类最常用的设计模式，在软件开发中应用非常广泛。创建型模式将对象的创建和使用分离，在使用对象时无须关心对象的创建细节，从而降低系统的耦合度，让设计方案更易于修改和扩展。每个创建型模式都通过采用不同的解决方案来回答3个问题：创建什么（What）​，由谁创建（Who）和何时创建（When）​。

单例模式

单例模式（Singleton Pattern）​：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。

饿汉式单例与懒汉式单例的讨论

饿汉式单例就是类加载的时候直接创建，由类加载的机制确保线程安全性。
懒汉式单例是用到的时候再去创建，不过要确保线程安全性：
假如某一瞬间线程A和线程B都在调用getInstance（​）方法，此时instance对象为null值，均能通过“instance＝＝null”的判断。由于实现了synchronized加锁机制，线程A进入synchronized锁定的代码中执行实例创建代码，线程B处于排队等待状态，必须等待线程A执行完毕后才可以进入synchronized锁定代码。但当A执行完毕时，线程B并不知道实例已经创建，将继续创建新的实例，导致产生多个单例对象，违背单例模式的设计思想。因此需要进行进一步改进，在synchronized锁定代码中再进行一次“instance＝＝null”判断，这种方式称为双重检查锁定（Double-Check Locking），代码示例如下：

通过静态内部类实现的更好办法

饿汉式单例类不能实现延迟加载，不管将来用不用，它始终占据内存；懒汉式单例类线程安全控制烦琐，而且性能受影响。可见，无论是饿汉式单例还是懒汉式单例都存在这样那样的问题。有没有一种方法，能够将两种单例的缺点都克服，而将两者的优点合二为一呢？答案是肯定的。下面来学习这种更好的被称为**Initialization on Demand Holder（IoDH）**的技术。
实现IoDH时，需在单例类中增加一个静态（static）内部类，在该内部类中创建单例对象，再将该单例对象通过getInstance（​）方法返回给外部使用，实现代码如下：

简单工厂模式

简单工厂模式并不属于GoF 23个经典设计模式，但通常将它作为学习其他工厂模式的基础，它的设计思想很简单。

简单工厂模式（Simple Factory Pattern）：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态（static）方法，因此简单工厂模式又被称为静态工厂方法（Static Factory Method）模式，它属于类创建型模式。

所有的工厂模式都强调一点：两个类A和B之间的关系应该仅仅是A创建B或是A使用B，而不能两种关系都有。将对象的创建和使用分离，也使得系统更加符合单一职责原则，有利于对功能的复用和系统的维护。

工厂方法模式

工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。工厂方法模式又简称为工厂模式（Factory Pattern），又可称作虚拟构造器模式（Virtual Constructor Pattern）或多态工厂模式（Polymorphic Factory Pattern）。工厂方法模式是一种类创建型模式。

工厂方法模式结构图中包含以下4个角色：

• Product（抽象产品）​：它是定义产品的接口，是工厂方法模式所创建对象的超类型，也就是产品对象的公共父类。
• ConcreteProduct（具体产品）​：它实现了抽象产品接口，某种类型的具体产品由专门的具体工厂创建，具体工厂和具体产品之间一一对应。
• Factory（抽象工厂）​：在抽象工厂类中，声明了工厂方法（Factory Method）​，用于返回一个产品。抽象工厂是工厂方法模式的核心，所有创建对象的工厂类都必须实现该接口。
• ConcreteFactory（具体工厂）​：它是抽象工厂类的子类，实现了抽象工厂中定义的工厂方法，并可由客户端调用，返回一个具体产品类的实例。

与简单工厂模式相比，工厂方法模式最重要的区别是引入了抽象工厂角色。抽象工厂可以是接口，也可以是抽象类。

重载的工厂方法

在抽象工厂中可以定义多个重载的工厂方法，在具体工厂中实现了这些工厂方法，这些方法可以包含不同的业务逻辑，以满足对不同产品对象的需求。

工厂方法的隐藏

有时候，为了进一步简化客户端的使用，还可以对客户端隐藏工厂方法。此时，在工厂类中将直接调用产品类的业务方法，客户端无须调用工厂方法创建产品，直接通过工厂即可使用所创建的对象中的业务方法。

工厂方法模式总结

工厂方法模式是简单工厂模式的延伸，它继承了简单工厂模式的优点，同时还弥补了简单工厂模式的不足。工厂方法模式是使用频率最高的设计模式之一，是很多开源框架和API类库的核心模式。

在以下情况下可以考虑使用工厂方法模式：

1. 客户端不知道其所需要的对象的类。在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建，可将具体工厂类的类名存储在配置文件或数据库中。
2. 抽象工厂类通过其子类来指定创建哪个对象。在工厂方法模式中，抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。

抽象工厂模式

产品等级结构与产品族

在工厂方法模式中，具体工厂负责生产具体的产品，每个具体工厂对应一种具体产品，工厂方法具有唯一性。一般情况下，一个具体工厂中只有一个或者一组重载的工厂方法。但是，有时希望一个工厂可以提供多个产品对象，而不是单一的产品对象。例如一个电器工厂，它可以生产电视机、电冰箱、空调等多种电器，而不是只生产某一种电器。为了更好地理解抽象工厂模式，这里先引入如下两个概念：

• 产品等级结构。产品等级结构即产品的继承结构，例如一个抽象类是电视机，其子类有海尔电视机、海信电视机、TCL电视机，则抽象电视机与具体品牌的电视机之间构成了一个产品等级结构，抽象电视机是父类，而具体品牌的电视机是其子类。
• 产品族。在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品。例如海尔电器工厂生产的海尔电视机、海尔电冰箱，海尔电视机位于电视机产品等级结构中，海尔电冰箱位于电冰箱产品等级结构中，海尔电视机、海尔电冰箱构成了一个产品族。

抽象工厂模式概述

**抽象工厂模式（Abstract Factory Pattern）**​：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。
在抽象工厂模式结构中包含以下4个角色：

• AbstractFactory（抽象工厂）​：它声明了一组用于创建一族产品的方法，每个方法对应一种产品。
• ConcreteFactory（具体工厂）​：它实现了在抽象工厂中声明的创建产品的方法，生成一组具体产品，这些产品构成了一个产品族，每种产品都位于某个产品等级结构中。
• AbstractProduct（抽象产品）​：它为每种产品声明接口，在抽象产品中声明了产品所具有的业务方法。
• ConcreteProduct（具体产品）​：它定义具体工厂生产的具体产品对象，实现在抽象产品接口中声明的业务方法。

抽象工厂模式的主要缺点是：增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了开闭原则。

原型模式

原型模式（Prototype Pattern）：使用原型实例指定创建对象的种类，并且通过克隆这些原型创建新的对象。原型模式是一种对象创建型模式。

Java语言提供的clone（​）方法

学过Java语言的人都知道，所有的Java类都继承自java.lang.Object。事实上，Object类提供了一个clone（​）方法，可以将一个Java对象克隆一份。因此在Java中可以直接使用Object提供的clone（​）方法来实现对象的克隆，Java语言中的原型模式实现很简单。
需要注意的是能够实现克隆的Java类必须实现一个标识接口Cloneable，表示这个Java类支持被复制。如果一个类没有实现这个接口但是调用了clone（​）方法，Java编译器将抛出一个CloneNotSupportedException异常，不过需要注意一点这是浅克隆的。

浅克隆与深克隆

在浅克隆中，如果原型对象的成员变量是值类型，将复制一份给克隆对象；如果原型对象的成员变量是引用类型，则将引用对象的地址复制一份给克隆对象，也就是说原型对象和克隆对象的成员变量指向相同的内存地址。简单来说，在浅克隆中，当对象被复制时只复制它本身和其中包含的值类型的成员变量，而引用类型的成员对象并没有被复制。

在深克隆中，无论原型对象的成员变量是值类型还是引用类型，都将复制一份给克隆对象，深克隆将原型对象的所有引用对象也复制一份给克隆对象。简单来说，在深克隆中，除了对象本身被复制外，对象所包含的所有成员变量也将被复制。

Java语言提供的Cloneable接口和Serializable接口的代码非常简单，它们都是空接口，这种空接口也称为标识接口。标识接口中没有任何方法的定义，其作用是告诉JRE这些接口的实现类是否具有某个功能，例如是否支持克隆、是否支持序列化等。

原型管理器的引入和实现

原型管理器（Prototype Manager）是将多个原型对象存储在一个集合中供客户端使用，它是一个专门负责克隆对象的工厂，其中定义了一个集合用于存储原型对象，如果需要某个原型对象的一个克隆，可以通过复制集合中对应的原型对象来获得.

建造者模式

**建造者模式（Builder Pattern）**​：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。建造者模式一步一步地创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。

在建造者模式结构中包含以下4个角色：

• Builder（抽象建造者）​：它为创建一个产品Product对象的各个部件指定抽象接口。在该接口中一般声明两类方法：一类方法是buildPartX（​）​，用于创建复杂对象的各个部件；另一类方法是getResult（​）​，用于返回复杂对象。Builder既可以是抽象类，也可以是接口。
• ConcreteBuilder（具体建造者）​：它实现了Builder接口，实现各个部件的具体构造和装配方法，定义并明确其所创建的复杂对象，也可以提供一个方法返回创建好的复杂产品对象。
• Product（产品角色）​：它是被构建的复杂对象，包含多个组成部件。具体建造者创建该产品的内部表示并定义其装配过程。
• Director（指挥者）​：指挥者又称为导演类，它负责安排复杂对象的建造次序。指挥者与抽象建造者之间存在关联关系，可以在其construct（​）建造方法中调用建造者对象的部件构造与装配方法，完成复杂对象的建造。客户端一般只需要与指挥者进行交互，在客户端确定具体建造者的类型，并实例化具体建造者对象（也可以通过配置文件和反射机制）​，然后通过指挥者类的构造函数或者Setter方法将该对象传入指挥者类中。

钩子方法的引入

建造者模式除了逐步构建一个复杂产品对象外，还可以通过Director类来更加精细地控制产品的创建过程，例如增加一类称之为钩子方法（Hook Method）的特殊方法来控制是否调用某个buildPartX（​）方法。

钩子方法的返回类型通常为boolean类型，方法名一般为is×××（​）​。钩子方法定义在抽象建造者类中。

例如，可以在游戏角色的抽象建造者类ActorBuilder中定义一个方法isBareheaded（​）​，用于判断某个角色是否为“光头（Bareheaded）​”​，在ActorBuilder中为之提供一个默认实现，其返回值为false。

组合的艺术

结构型模式

在面向对象软件系统中，每个类／对象都承担着一定的职责，它们相互协作，可以实现一些复杂的功能。结构型模式（Structural Pattern）关注如何将现有类或对象组织在一起形成更加强大的结构。不同的结构型模式从不同的角度来组合类或对象，在尽可能满足各种面向对象设计原则的同时，为类或对象的组合提供一系列巧妙的解决方案。

适配器模式

适配器模式（Adapter Pattern）：将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，**其别名为包装器（Wrapper）**​。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

注：在适配器模式定义中所提及的接口是指广义的接口，它可以表示一个方法或者一组方法的集合。

类适配器模式

除了对象适配器模式之外，适配器模式还有一种形式，那就是类适配器模式。类适配器模式与对象适配器模式最大的区别在于其适配器和适配者之间的关系是继承关系。

由于Java、C＃等语言不支持多重类继承，因此类适配器模式的使用受到很多限制。例如，如果目标抽象类Target不是接口，而是一个类，就无法使用类适配器模式。此外，如果适配者Adaptee为最终（Final）类，也无法使用类适配器模式。在Java等面向对象编程语言中，大部分情况下使用的是对象适配器模式，类适配器模式较少使用。

双向适配器模式

在对象适配器模式的使用过程中，如果在适配器中同时包含对目标类和适配者类的引用，适配者可以通过它调用目标类中的方法，目标类也可以通过它调用适配者类中的方法，那么该适配器就是一个双向适配器

缺省适配器模式

缺省适配器模式（Default Adapter Pattern）：当不需要实现一个接口所提供的所有方法时，可先设计一个抽象类实现该接口，并为接口中每个方法提供一个默认实现（空方法）​，那么该抽象类的子类可以选择性地覆盖父类的某些方法来实现需求。它适用于不想使用一个接口中的所有方法的情况，又称为单接口适配器模式。

适用场景

在以下情况下可以考虑使用适配器模式：

• 系统需要使用一些现有的类，而这些类的接口（例如方法名）不符合系统的需要，甚至没有这些类的源代码。
• 想创建一个可以重复使用的类，用于与一些彼此之间没有太大关联的类，包括一些可能在将来引进的类一起工作。

桥接模式

桥接模式用一种巧妙的方式处理多层继承存在的问题。桥接模式采用抽象关联取代了传统的多层继承，将类之间的静态继承关系转换为动态的对象组合关系，使得系统更加灵活，并易于扩展，同时有效控制了系统中类的个数。桥接模式定义如下：
桥接模式（Bridge Pattern）：将抽象部分与其实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体（Handle and Body）模式或接口（Interface）模式。

桥接模式是一个非常有用的模式，在桥接模式中体现了很多面向对象设计原则的思想，包括单一职责原则、开闭原则、合成复用原则、里氏代换原则、依赖倒转原则等。熟悉桥接模式有助于深入理解这些设计原则，也有助于形成正确的设计思想和培养良好的设计风格。

桥接模式和适配器模式用于设计的不同阶段。桥接模式用于系统的初步设计，对于存在两个独立变化维度的类可以将其分为抽象类和实现类两个角色，使它们可以分别进行变化；而在初步设计完成之后，当发现系统与已有类无法协同工作时，可以采用适配器模式。但有时候在设计初期也需要考虑适配器模式，特别是那些涉及大量第三方应用接口的情况。

桥接模式是设计Java虚拟机和实现JDBC等驱动程序的核心模式之一，应用较为广泛。在软件开发中，如果一个类或一个系统有多个变化维度时，都可以尝试使用桥接模式对其进行设计。桥接模式为具有多维度变化的系统提供了一套完整的解决方案，并且降低了系统的复杂度。

装饰模式

装饰模式是一种用于替代继承的技术，它通过一种无须定义子类的方式来给对象动态增加职责，使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类，在装饰类中既可以调用待装饰的原有类的方法，还可以增加新的方法，以扩充原有类的功能。装饰模式定义如下：
装饰模式（Decorator Pattern）：动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。

在装饰模式结构图中包含以下4个角色：

• Component（抽象构件）​：它是具体构件和抽象装饰类的共同父类，声明了在具体构件中实现的业务方法。它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象，实现客户端的透明操作。
• ConcreteComponent（具体构件）​：它是抽象构件类的子类，用于定义具体的构件对象，实现了在抽象构件中声明的方法，装饰器可以给它增加额外的职责（方法）​。
• Decorator（抽象装饰类）​：它也是抽象构件类的子类，用于给具体构件增加职责，但是具体职责在其子类中实现。它维护一个指向抽象构件对象的引用，通过该引用可以调用装饰之前构件对象的方法，并通过其子类扩展该方法，以达到装饰的目的。
• ConcreteDecorator（具体装饰类）​：它是抽象装饰类的子类，负责向构件添加新的职责。每一个具体装饰类都定义了一些新的行为，可以调用在抽象装饰类中定义的方法，并可以增加新的方法用以扩充对象的行为。

外观模式

外观模式（Facade Pattern）：外部与一个子系统的通信通过一个统一的外观角色进行，为子系统中的一组接口提供一个一致的入口。外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。（常说的门户就是类似的概念）

抽象外观类的引入

在标准的外观模式结构图中，如果需要增加、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则。因此，可以通过引入抽象外观类来对系统进行改进，在一定程度上解决该问题。在引入抽象外观类之后，客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类。由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的。

享元模式

享元模式（Flyweight Pattern）：运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，是一种对象结构型模式。

在享元模式结构图中包含以下4个角色：

• Flyweight（抽象享元类）：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态）​，同时也可以通过这些方法来设置外部数据（外部状态）​。
• ConcreteFlyweight（具体享元类）：它实现了抽象享元类，其实例称为享元对象。在具体享元类中为内部状态提供了存储空间。通常，可以结合单例模式来设计具体享元类，为每个具体享元类提供唯一的享元对象。
• UnsharedConcreteFlyweight（非共享具体享元类）：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类。当需要一个非共享具体享元类的对象时可以直接通过实例化创建。
• FlyweightFactory（享元工厂类）：享元工厂类用于创建并管理享元对象，它针对抽象享元类编程，将各种类型的具体享元对象存储在一个享元池中。享元池一般设计为一个存储“键值对”的集合（也可以是其他类型的集合）​，可以结合工厂模式进行设计。当用户请求一个具体享元对象时，享元工厂提供一个存储在享元池中已创建的实例，或者创建一个新的实例（如果不存在的话）并返回新创建的实例，同时将其存储在享元池中。

单纯享元模式和复合享元模式

• 在单纯享元模式中，所有的具体享元类都是可以共享的，不存在非共享具体享元类。
• 将一些单纯享元对象使用组合模式加以组合，还可以形成复合享元对象。这样的复合享元对象本身不能共享，但是它们可以包括单纯享元对象，而后者则可以共享。

享元模式与String类

JDK类库中的String类使用了享元模式。在Java语言中，如果每次执行类似String str1＝＂abcd＂的操作时都创建一个新的字符串对象，将导致内存开销很大。因此，如果第一次创建了内容为＂abcd＂的字符串对象str1，下一次再创建内容相同的字符串对象str2时会将它的引用指向＂abcd＂，不会重新分配内存空间，从而实现了＂abcd＂在内存中的共享

Java String类这种在修改享元对象时，先将原有对象复制一份，然后在新对象上再实施修改操作的机制称为“Copy On Write”​。

代理模式

代理模式（Proxy Pattern）​：给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式是一种对象结构型模式。
在代理模式结构图中包含以下3个角色:

• Subject（抽象主题角色）​：它声明了真实主题和代理主题的共同接口，使得在任何使用真实主题的地方都可以使用代理主题，客户端通常需要针对抽象主题角色进行编程。
• Proxy（代理主题角色）​：代理主题角色内部包含了对真实主题的引用，从而可以在任何时候操作真实主题对象。在代理主题角色中提供一个与真实主题角色相同的接口，以便在任何时候都可以替代真实主题。代理主题角色还可以控制对真实主题的使用，负责在需要的时候创建和删除真实主题对象，并对真实主题对象的使用加以约束。通常，在代理主题角色中，客户端在调用所引用的真实主题操作之前或之后还需要执行其他操作，而不仅仅是单纯调用真实主题对象中的操作。
• RealSubject（真实主题角色）​：它定义了代理角色所代表的真实对象，在真实主题角色中实现了真实的业务操作，客户端可以通过代理主题角色间接调用真实主题角色中定义的操作。

代理模式和装饰模式在实现时有些类似，但是代理模式主要是给真实主题类增加一些全新的职责，例如权限控制、缓冲处理、智能引用、远程访问等，这些职责与原有职责不属于同一个问题域。而装饰模式是通过装饰类为具体构件类增加一些相关的职责，是对原有职责的扩展，这些职责属于同一问题域。代理模式和装饰模式的目的也不相同，前者是控制对对象的访问，而后者是为对象动态地增加功能。

Java动态代理

动态代理是一种较为高级的代理模式，它在事务管理、AOP（Aspect-Oriented Programming，面向方面编程）等领域都发挥了重要的作用。

Java语言实现动态代理时需要用到位于java.lang.reflect包中的一些类，现简要说明如下。

• Proxy类提供了用于创建动态代理类和实例对象的方法，它是所创建的动态代理类的父类，最常用的方法如下：
  • public static Class<?>getProxyClass（ClassLoader loader，Class<?>…interfaces）​。该方法用于返回一个Class类型的代理类，在参数中需要提供类加载器并需要指定代理的接口数组（与真实主题类的接口列表一致）​。
  • publicstaticObjectnewProxyInstance（ClassLoaderloader，Class<?>[​]interfaces，InvocationHandler h）​。该方法用于返回一个动态创建的代理类的实例，方法中第1个参数loader表示代理类的类加载器，第2个参数interfaces表示代理类所实现的接口列表（与真实主题类的接口列表一致）​，第3个参数h表示所指派的调用处理程序类。
• InvocationHandler接口是代理处理程序类的实现接口，该接口作为代理实例的调用处理者的公共父类。每个代理类的实例都可以提供一个相关的具体调用处理者（InvocationHandler接口的子类
  • public Object invoke（Object proxy，Method method，Object[​]args）​。该方法用于处理对代理类实例的方法调用并返回相应的结果，当一个代理实例中的业务方法被调用时将自动调用该方法。invoke（​）方法包含3个参数，其中，第1个参数proxy表示代理类的实例，第2个参数method表示需要代理的方法，第3个参数args表示代理方法的参数数组。

JDK中提供的动态代理只能代理一个或多个接口，如果需要动态代理具体类或抽象类，可以使用CGLib（Code Generation Library）等工具。CGLib是一个功能较为强大、性能和质量也较好的代码生成包，在许多AOP框架中得到了广泛应用。大家可以自行查阅相关资料来学习CGLib。

交互的艺术

行为型模式

在软件系统运行时，对象并不是孤立存在的，它们可以通过相互通信协作完成某些功能，一个对象在运行时也将影响到其他对象的运行。行为型模式（Behavioral Pattern）关注系统中对象之间的交互，研究系统在运行时对象之间的相互通信与协作，进一步明确对象的职责。行为型模式不仅仅关注类和对象本身，还重点关注它们之间的相互作用和职责划分。

职责链模式

也称为责任链模式，一个意思的。职责链模式（Chain of Responsibility Pattern）​：避免将请求发送者与接收者耦合在一起，让多个对象都有机会接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式是一种对象行为型模式。
在职责链模式结构图中包含以下两个角色：

• Handler（抽象处理者）​：它定义了一个处理请求的接口，一般设计为抽象类。由于不同的具体处理者处理请求的方式不同，因此在其中定义了抽象请求处理方法。因为每个处理者的下家还是一个处理者，因此在抽象处理者中定义了一个抽象处理者类型的对象（结构图中的successor）​，作为其对下家的引用。通过该引用，处理者可以连成一条链。
• ConcreteHandler（具体处理者）​：它是抽象处理者的子类，可以处理用户请求。在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法，在处理请求之前需要进行判断，看是否有相应的处理权限，如果可以处理请求就处理它，否则将请求转发给后继者。在具体处理者中可以访问链中下一个对象，以便请求的转发。

在一个不纯的职责链模式中，允许某个请求被一个具体处理者部分处理后再向下传递，或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求，而且一个请求可以最终不被任何处理者对象所接收。

命令模式

命令模式（Command Pattern）​：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作（Action）模式或事务（Transaction）模式。

解释器模式

解释器模式（Interpreter Pattern）​：定义一个语言的文法，并且建立一个解释器来解释该语言中的句子，这里的“语言”是指使用规定格式和语法的代码。解释器模式是一种类行为型模式。（这些模式用的很少也很枯燥，搞编译和语法树的常用吧）

迭代器模式

迭代器模式（Iterator Pattern）​：提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标（Cursor）​。迭代器模式是一种对象行为型模式。（这个java里面太多实现了）

中介者模式

如果在一个系统中对象之间存在多对多的相互关系，可以将对象之间的一些交互行为从各个对象中分离出来，并集中封装在一个中介者对象中，由该中介者进行统一协调，这样对象之间多对多的复杂关系就转化为相对简单的一对多关系。通过引入中介者来简化对象之间的复杂交互，中介者模式是迪米特法则的一个典型应用。

中介者模式（Mediator Pattern）​：用一个中介对象（中介者）来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式，它是一种对象行为型模式。

备忘录模式

备忘录模式提供了一种状态恢复的实现机制，使得用户可以方便地回到一个特定的历史步骤。当新的状态无效或者存在问题时，可以使用暂时存储起来的备忘录将状态复原。当前很多软件都提供了撤销（Undo）操作，其中就使用了备忘录模式。

备忘录模式（Memento Pattern）​：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它是一种对象行为型模式，其别名为Token。

观察者模式

观察者模式（Observer Pattern）​：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。

状态模式

状态模式用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行为不相同时可以使用状态模式。状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化。对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致性地处理。状态模式定义如下：

状态模式（State Pattern）​：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象（Objects for States）​，状态模式是一种对象行为型模式。

在状态模式结构图中包含以下3个角色：

• Context（环境类）​：环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同，因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象。
• State（抽象状态类）​：它用于定义一个接口以封装与环境类的一个特定状态相关的行为。在抽象状态类中声明各种不同状态对应的方法，而在其子类中实现这些方法。由于不同状态下对象的行为可能不同，因此在不同子类中方法的实现可能存在不同，相同的方法可以写在抽象状态类中。
• ConcreteState（具体状态类）​：它是抽象状态类的子类，每个子类实现一个与环境类的一个状态相关的行为。每个具体状态类对应环境类的一个具体状态，不同的具体状态类其行为有所不同。

策略模式

在策略模式中，可以定义一些独立的类来封装不同的算法，每个类封装一种具体的算法。在这里，每个封装算法的类都可以称之为一种策略（Strategy）​。为了保证这些策略在使用时具有一致性，一般会提供一个抽象的策略类来做规则的定义，而每种算法则对应于一个具体策略类。

策略模式的主要目的是将算法的定义与使用分开，也就是将算法的行为和环境分开。将算法的定义放在专门的策略类中，每个策略类封装了一种实现算法。使用算法的环境类针对抽象策略类进行编程，符合依赖倒转原则。在出现新的算法时，只需要增加一个新的实现了抽象策略类的具体策略类即可。策略模式定义如下：

策略模式（Strategy Pattern）：定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化，也称为政策模式（Policy）​。策略模式是一种对象行为型模式。策略模式包含以下3个角色：

• Context（环境类）：环境类是使用算法的角色，它在解决某个问题（即实现某个方法）时可以采用多种策略。在环境类中维持一个对抽象策略类的引用实例，用于定义所采用的策略。
• Strategy（抽象策略类）：它为所支持的算法声明了抽象方法，是所有策略类的父类。它可以是抽象类或具体类，也可以是接口。环境类通过抽象策略类中声明的方法在运行时调用具体策略类中实现的算法。
• ConcreteStrategy（具体策略类）：它实现了在抽象策略类中声明的算法。在运行时，具体策略类将覆盖在环境类中定义的抽象策略类对象，使用一种具体的算法实现某个业务处理。

策略模式用于算法的自由切换和扩展，它是应用较为广泛的设计模式之一。策略模式对应于解决某一问题的一个算法族，允许用户从该算法族中任选一个算法来解决某一问题，同时可以方便地更换算法或者增加新的算法。只要涉及算法的封装、复用和切换都可以考虑使用策略模式。

模板方法模式

模板方法模式是结构最简单的行为型设计模式，在其结构中只存在父类与子类之间的继承关系。通过使用模板方法模式，可以将一些复杂流程的实现步骤封装在一系列基本方法中。在抽象父类中提供一个称之为模板方法的方法来定义这些基本方法的执行次序，而通过其子类来覆盖某些步骤，从而使得相同的算法框架可以有不同的执行结果。模板方法模式提供了一个模板方法来定义算法框架，而某些具体步骤的实现可以在其子类中完成。

模板方法模式是一种基于继承的代码复用基本技术，其定义如下：
模板方法模式（Template Method Pattern）​：定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式是一种类行为型模式。

在模板方法模式结构图中包含以下两个角色:

• AbstractClass（抽象类）​：在抽象类中定义了一系列基本操作（Primitive Operations）​，这些基本操作可以是具体的，也可以是抽象的。每个基本操作对应算法的一个步骤，在其子类中可以重定义或实现这些步骤。同时，在抽象类中实现了一个模板方法（Template Method）​，用于定义一个算法的框架。模板方法不仅可以调用在抽象类中实现的基本方法，也可以调用在抽象类的子类中实现的基本方法，还可以调用其他对象中的方法。
• ConcreteClass（具体子类）​：它是抽象类的子类，用于实现在父类中声明的抽象基本操作以完成子类特定算法的步骤，也可以覆盖在父类中已经实现的具体基本操作。

模版方法

一个模板方法是定义在抽象类中的、把基本操作方法组合在一起形成一个总算法或一个总行为的方法。这个模板方法定义在抽象类中，并由子类不加以修改地完全继承下来（在Java语言中，可以将模板方法定义为final方法）​。模板方法是一个具体方法，它给出了一个顶层逻辑框架，而逻辑的组成步骤在抽象类中可以是具体方法，也可以是抽象方法。由于模板方法是具体方法，因此模板方法模式中的抽象层只能是抽象类，而不是接口。

基本方法

基本方法是实现算法各个步骤的方法，是模板方法的组成部分。基本方法又可以分为3种：抽象方法（Abstract Method）​、具体方法（Concrete Method）和钩子方法（Hook Method）​：

• 抽象方法：一个抽象方法由抽象类声明，由其具体子类实现。在Java语言里一个抽象方法以abstract关键字标识。
• 具体方法：一个具体方法由一个抽象类或具体类声明并实现，其子类可以进行覆盖也可以直接继承。
• 钩子方法：一个钩子方法由一个抽象类或具体类声明并实现，而其子类可能会加以扩展。通常在父类中给出的实现是一个空实现，并以该空实现作为方法的默认实现，当然钩子方法也可以提供一个非空的默认实现。

模板方法模式是一种基于继承的代码复用技术，它体现了面向对象的诸多重要思想，是一种使用频率较高的模式。模板方法模式广泛应用于框架设计（例如Spring、JUnit等）中，以确保通过父类来控制处理流程的逻辑顺序（例如框架的初始化、测试流程的设置等）​。

这个设计模式有时候会和策略方法混用在一起，用起来很爽。

最终结语

设计模式简而言之就是前人们根据经验总结出来的编程套路，类似于编程界的武功秘籍，但是武功不是死的，而是活学活用的，设计模式不要拘泥于固定的死板套路，而是可以活学活用的，而且最好也不要过度设计，相信每个人努力学习钻研设计模式，最终都会形成自己的武功秘籍。