设计模式详解
1.七大设计原则
1.1 单一职责原则
单一原则表明,如果你有多个原因去改变一个类,那么应该把这些引起变化的原因分离开,把这个类分成多个类,每个类只负责处理一种改变。
你做出某种改变时,只需要修改负责处理该改变的类。当我们去改变一个具有多个职责的类时可能会影响该类的其他功能。
单一职责原则代表了设计应用程序时一种很好的识别类的方式,并且它提醒你思考一个类的所有演化方式。只有对应用程序的工作方式有了很
好的理解,才能很好的分离职责。
1.2 开闭原则
- 对扩展开放:模块的行为可以被扩展从而满足新的需求。
- 对修改关闭:不允许修改模块的源代码(或者尽量使修改最小化)
开闭原则是说我们应该努力设计不需要修改的模块。在实际应用将变化的代码和不需要变化的代码进行隔离,将变化的代码抽象成稳定接口,
针对
接口进行编程。在扩展系统的行为时,我们只需要添加新的代码,而不需要修改已有的代码。一般可以通过添加新的子类和重写父类的方法来
实现。
开闭原则是面向对象设计的核心,满足该原则可以达到最大限度的复用性和可维护性。
1.3 接口隔离原则
接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口,应该把肥胖接口中的方法分组,然后用多个接口代替它,每个接口服务
于一个子模块。
如果已经设计成了胖接口,可以使用适配器模式隔离它。像其他设计原则一样,接口隔离原则需要额外的时间和努力,并且会增加代码的复杂
性,但是可以产生更灵活的设计。如果我们过度的使用它将会产生大量的包含单一方法的接口,所以需要根据经验并且识别出那些将来需要扩
展的代码来使用它。
1.4 里氏替换原则
里氏替换原则是对开闭原则的扩展,它表明我们在创建基类的新的子类时,不应该改变基类的行为。
当我们设计程序模块时,我们会创建一些类层次结构,然后我们通过扩展一些类来创建它们的子类。我们必须确保子类只是扩展而没有替换父
类的功能,否则当我们在已有程序模块中使用它们时将会产生不可预料的结果。里氏代换原则表明当一个程序模块使用基类时,基类的引用可
以被子类替换而不影响模块的功能。
1.5 依赖倒转原则
- 上层模块不应该依赖于底层模块,它们都应该依赖于抽象。
- 抽象不应该依赖于细节,细节应该依赖于抽象。
应用该原则意味着上层类不直接使用底层类,他们使用接口作为抽象层。这种情况下上层类中创建底层类的对象的代码不能直接使用new 操作
符。可以使用一些创建型设计模式,例如工厂方法,抽象工厂和原型模式。模版设计模式是应用依赖倒转原则的一个例子。当然,使用该模式
需要额外的努力和更复杂的代码,不过可以带来更灵活的设计。不应该随意使用该原则,如果我们有一个类的功能很有可能在将来不会改变,
那么我们就不需要使用该原则。
1.6 迪米特法则
迪米特法则(Law of Demeter)又叫最少知识原(Least Knowledge Principle LKP),就是说一个对象应当对其他对象有尽可能少的了解。
迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块相互独立,相互之间不存在依赖关系。
应用迪米特法则有可能造成的一个后果就是,系统中存在的大量的中介类,这些类只所以存在完全是为了传递类之间的相互调用关系—这在一定程度上增加系统的复杂度。
设计模式中的门面模式(Facade)和中介模式(Mediator)都是迪米特法则的应用的例子。
狭义的迪米特法则的缺点:
- 在系统里面造出大量的小方法,这些方法仅仅是传递间接的调用,与系统的商业逻辑无关。
- 遵循类之间的迪米特法则会使一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有之间的关联。但是,这也会造成系统的不同模块之间的通信效率降低,也会使系统的不同模块之间不容易协调。
广义的迪米特法则在类的设计上的体现:
- 优先考虑将一个类设置成不变类。
- 尽量降低一个类的访问权限。
- 尽量降低成员的访问权限。
1.7 组合/聚合复用原则
- 聚合表示整体与部分的关系,表示“含有”,整体由部分组合而成,部分可以脱离整体作为一个独立的个体存在。
- 组合则是一种更强的聚合,部分组成整体,而且不可分割,部分不能脱离整体而单独存在。
在合成关系中,部分和整体的生命周期一样,组合的新的对象完全支配其组成部分,包括他们的创建和销毁。
组合/聚合和继承是实现复用的两个基本途径。合成复用原则是指尽量使用组合/聚合,而不是使用继承。只有当以下的条件全部被满足时,才
应当使用继承关系:
- 子类是超类的一个特殊种类,而不是超类的一个角色,也就是区分“Has-A”和“Is-A”.只有“Is-A”关系才符合继承关系,“Has-A”关系应当使用聚合来描述。
- 永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话,就不要使用继承。
- 子类具有扩展超类的责任,而不是具有置换掉或注销掉超类的责任。如果一个子类需要大量的置换掉超类的行为,那么这个类就不应该是这个超类的子类。
2.UML类图
+
表示public-
表示private#
表示protected
属性的完整表示方式是: 可见性 名称:类型 = 缺省值
方法的完整表示方式是: 可见性 名称(参数列表) : 返回类型
⚠️注意:
抽象类的类名以及抽象方法的名字都用斜体
接口在类图中的第一层顶端会用
<<interface>>
标注这是一个接口
在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)
2.1 关联关系
关联关系是对象之间的一种引用关系,用于表示一类对象与另一类对象之间的联系,如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系,分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。
关联又可以分为单向关联,双向关联,自关联。
2.1.1 单向关联
在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址,这通过让Customer类持有一个类型为Address的成员变量类实现。
2.1.2 双向关联
从上图中我们很容易看出,所谓的双向关联就是双方各自持有对方类型的成员变量。
在UML类图中,双向关联用一个不带箭头的直线表示。上图中在Teacher类中维护一个List<Student>
,表示一个老师可以有多个学生;在Student类中维护一个Teacher类型的成员变量表示这个学生的老师是谁
2.2 聚合关系
聚合关系是关联关系的一种,是强关联关系,是整体和部分之间的关系。
聚合关系也是通过成员对象来实现的,其中成员对象是整体对象的一部分,但是成员对象可以脱离整体对象而独立存在。例如,学校与老师的关系,学校包含老师,但如果学校停办了,老师依然存在。
在 UML 类图中,聚合关系可以用带空心菱形的实线来表示,菱形指向整体。下图所示是大学和教师的关系图:
2.3 组合关系
组合表示类之间的整体与部分的关系,但它是一种更强烈的聚合关系。
在组合关系中,整体对象可以控制部分对象的生命周期,一旦整体对象不存在,部分对象也将不存在,部分对象不能脱离整体对象而存在。例如,头和嘴的关系,没有了头,嘴也就不存在了。
在 UML 类图中,组合关系用带实心菱形的实线来表示,菱形指向整体。下图所示是头和嘴的关系图:
2.4 依赖关系
依赖关系是一种使用关系,它是对象之间耦合度最弱的一种关联方式,是临时性的关联。在代码中,某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类(被依赖类)中的某些方法来完成一些职责。
在 UML 类图中,依赖关系使用带箭头的虚线来表示,箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图,司机驾驶汽车:
2.5 继承(泛化)关系
继承关系是对象之间耦合度最大的一种关系,表示一般与特殊的关系,是父类与子类之间的关系,是一种继承关系。
在 UML 类图中,泛化关系用带空心三角箭头的实线来表示,箭头从子类指向父类。在代码实现时,使用面向对象的继承机制来实现泛化关系。例如,Student 类和 Teacher 类都是 Person 类的子类,其类图如下图所示:
2.6 实现关系
实现关系是接口与实现类之间的关系。在这种关系中,类实现了接口,类中的操作实现了接口中所声明的所有的抽象操作。
在 UML 类图中,实现关系使用带空心三角箭头的虚线来表示,箭头从实现类指向接口。例如,汽车和船实现了交通工具
3.设计模式
3.1 创建型模式
创建型模式的作用就是创建对象,说到创建一个对象,最熟悉的就是 new 一个对象,然后 set 相关属性。但是,在很多场景下,我们需要给客户端提供更加友好的创建对象的方式,尤其是那种我们定义了类,但是需要提供给其他开发者用的时候。
3.1.1 工厂模式🌟
3.1.1.1 简单工厂模式
public class FoodFactory {
public static Food makeFood(String name) {
if (name.equals("noodle")) {
Food noodle = new LanZhouNoodle();
noodle.addSpicy("more");
return noodle;
} else if (name.equals("chicken")) {
Food chicken = new HuangMenChicken();
chicken.addCondiment("potato");
return chicken;
} else {
return null;
}
}
}
其中,LanZhouNoodle
和 HuangMenChicken
都继承自 Food
。
简单地说,简单工厂模式通常就是这样,一个工厂类 XxxFactory,里面有一个静态方法,根据我们不同的参数,返回不同的派生自同一个父类(或实现同一接口)的实例对象。
3.1.1.2 工厂方法模式
简单工厂模式很简单,如果它能满足我们的需要,我觉得就不要折腾了。之所以需要引入工厂模式,是因为我们往往需要使用两个或两个以上的工厂。
public interface FoodFactory {
Food makeFood(String name);
}
public class ChineseFoodFactory implements FoodFactory {
@Override
public Food makeFood(String name) {
if (name.equals("A")) {
return new ChineseFoodA();
} else if (name.equals("B")) {
return new ChineseFoodB();
} else {
return null;
}
}
}
public class AmericanFoodFactory implements FoodFactory {
@Override
public Food makeFood(String name) {
if (name.equals("A")) {
return new AmericanFoodA();
} else if (name.equals("B")) {
return new AmericanFoodB();
} else {
return null;
}
}
}
其中,ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB
都派生自 Food
。
客户端调用:
public class APP {
public static void main(String[] args) {
// 先选择一个具体的工厂
FoodFactory factory = new ChineseFoodFactory();
// 由第一步的工厂产生具体的对象,不同的工厂造出不一样的对象
Food food = factory.makeFood("A");
}
}
虽然都是调用 makeFood("A") 制作 A 类食物,但是,不同的工厂生产出来的完全不一样。
第一步,我们需要选取合适的工厂,然后第二步基本上和简单工厂一样。
核心在于,我们需要在第一步选好我们需要的工厂。比如,我们有 LogFactory 接口,实现类有 FileLogFactory和KafkaLogFactory,
分别对应将日志写入文件和写入 Kafka 中,显然,我们客户端第一步就需要决定到底要实例化 FileLogFactory 还是
KafkaLogFactory,这将决定之后的所有的操作。
3.1.1.3 抽象工厂模式
当涉及到产品族的时候,就需要引入抽象工厂模式了。
一个经典的例子是造一台电脑。我们先不引入抽象工厂模式,看看怎么实现。
因为电脑是由许多的构件组成的,我们将 CPU 和主板进行抽象,然后 CPU 由 CPUFactory 生产,主板由 MainBoardFactory 生产,然
后,我们再将 CPU 和主板搭配起来组合在一起,如下图:
单独看 CPU 工厂和主板工厂,它们分别是前面我们说的工厂模式。这种方式也容易扩展,因为要给电脑加硬盘的话,只需要加一个 HardDiskFactory 和相应的实现即可,不需要修改现有的工厂。
但是,这种方式有一个问题,那就是如果 Intel 家产的 CPU 和 AMD 产的主板不能兼容使用,那么这代码就容易出错,因为客户端并不知道它们不兼容,也就会错误地出现随意组合。
下面就是我们要说的产品族的概念,它代表了组成某个产品的一系列附件的集合:
当涉及到这种产品族的问题的时候,就需要抽象工厂模式来支持了。我们不再定义 CPU 工厂、主板工厂、硬盘工厂、显示屏工厂等等,我们直接定义电脑工厂,每个电脑工厂负责生产所有的设备,这样能保证肯定不存在兼容问题。
这个时候,对于客户端来说,不再需要单独挑选 CPU厂商、主板厂商、硬盘厂商等,直接选择一家品牌工厂,品牌工厂会负责生产所有的东西,而且能保证肯定是兼容可用的。
public static void main(String[] args) {
// 第一步就要选定一个“大厂”
ComputerFactory cf = new AmdFactory();
// 从这个大厂造 CPU
CPU cpu = cf.makeCPU();
// 从这个大厂造主板
MainBoard board = cf.makeMainBoard();
// 从这个大厂造硬盘
HardDisk hardDisk = cf.makeHardDisk();
// 将同一个厂子出来的 CPU、主板、硬盘组装在一起
Computer result = new Computer(cpu, board, hardDisk);
}
当然,抽象工厂的问题也是显而易见的,比如我们要加个显示器,就需要修改所有的工厂,给所有的工厂都加上制造显示器的方法。这有点违
反了对修改关闭,对扩展开放这个设计原则。
3.1.1.4 总结
工厂模式总结:
在工厂模式中首先所有的对象都是由工厂生产,而不是手动创建
- **简单工厂:**只有一个工厂,工厂内提供一个静态方法,通过此静态方法根据不同的参数创建不同的对象,这些对象都来自同一父类。创建对象时直接通过
工厂.静态方法(参数)
创建创建对象即可- 当需要进行扩展时,耦合性较高,且需要多个工厂时即不能满足需求
- 工厂方法: 当需要多个工厂时,即能根据不同工厂创建各自工厂所属的对象,这些工厂都继承或实现同一父类,生产的对象也都要继承同一父类。创建对象首先要选择并创建实例化一个工厂,然后调用工厂对象中的实例方法根据不同参数创建各自工厂的不同对象。
- 当需要进行扩展时,只需要再新建一个工厂即可,可能造成工厂泛滥
- **抽象工厂:**当涉及到产品族的概念时,就需要使用抽象工厂了,即不同的工厂生产的对象都是一系列的,即每个工厂各自有一套自己的生产标准,这些工厂也都要继承或实现同一工厂
- 当需要进行扩展时,需要修改工厂类,违反开闭原则
3.1.1.5 Spring工厂模式
Spring工厂模式使用:
在Spring的IOC中使用工厂模式
+反射
实现对象的创建并放到IOC容器中。
顶层BeanFactor
工厂类有提供最基本的依赖注入支持,其实现常用的有ApplicationContext
,它扩展了除BeanFactoy
方法内部的其它额外功能,所以一般用ApplicationContext
比较多
ApplicationContext
的三个实现类:
ClassPathXmlApplication
:把上下文文件当成类路径资源。FileSystemXmlApplication
:从文件系统中的 XML 文件载入上下文定义信息。XmlWebApplicationContext
:从Web系统中的XML文件载入上下文定义信息。
例如:ClassPathXmlApplication使用:
ClassPathXmlApplication会读取XML中的内容,获取bean标签中id属性值和class属性值后,使用class属性值通过反射创建出实例对象,并使用id属性值作为key,将创建的对象放入ConcurrentHashMap容器中。当获取IOC容器中的对象时,调用其getBean方法,传入bean的类型或者名称即可从容器中获取。
3.1.4 单例模式🌟
3.1.4.1 饿汉式
类加载就会导致该单实例对象被创建,即不会存在线程安全问题
//可以加final防止子类的干扰
public final class Singleton {
//不允许通过new实例化
private Singleton() {
}
//创建该类时就会创建此实例
//在类加载的时候,该对象即被jvm创建,所以为线程安全的
private static Singleton singleton=new Singleton();
//只能通过静态方法获取
public static Singleton getInstance() {
return singleton;
}
}
3.1.4.2 懒汉式
👎不推荐的写法:存在线程安全问题
public final class Singleton {
//不允许通过new实例化
private Singleton() {
}
//默认不创建
private static Singleton singleton=null;
//只能通过静态方法获取
public static Singleton getInstance() {
if (singleton == null) {
singleton=new Singleton();
return singleton;
}
return singleton;
}
}
👎不推荐的写法:性能较低
public final class Singleton {
//不允许通过new实例化
private Singleton() {
}
//默认不创建
private static Singleton singleton=null;
//只能通过静态方法获取
//直接对方法加synchronized,性能较低
public static synchronized Singleton getInstance() {
if (singleton == null) {
singleton=new Singleton();
return singleton;
}
return singleton;
}
}
👍推荐的经典写法:双重校验锁
public final class Singleton {
//不允许通过new实例化
private Singleton() {
}
//默认不创建
//使用volatile禁止指令重排
private static volatile Singleton singleton=null;
//只能通过静态方法获取
public static Singleton getInstance() {
if (singleton == null) {
synchronized (Singleton.class) {
//有可能在进入synchronized之前对象以及创建完毕,所以这里要再判断一次
if (singleton == null) {
singleton=new Singleton();
}
}
}
return singleton;
}
}
⚠️ **volatile作用:**当调用静态方法获取对象实例的时候,第一个线程在第一处判断对象是否为空时,第二个线程已经进入到正在创建对象的阶段,此时对象的创建分为三个步骤:
1⃣️创建并复制一份对象的引用
2⃣️使用对象引用调用构造方法
3⃣️将该对象引用赋值给单例对象。
但是由于JVM指令重排的关系,步骤可能为1⃣️3⃣️2⃣️,此时第二个线程执行到步骤3⃣️后,导致第一个线程判断该实例不为空,但实际上改对象还未创建完毕,导致第一个线程获取到对象不完整。
👍推荐的其它写法:静态内部类
public class Singleton {
//使用私有的静态内部类,对外部不可见。
//jvm本身对类加载是懒惰的,即只调用到getInstance方法时,使用到LazyHolder对象时该内部类才会被加载,里面的实例才会被加载
private static class LazyHolder{
static final Singleton INSTANCE=new Singleton();
}
//调用时才会加载此内部类
public static Singleton getInstance() {
return LazyHolder.INSTANCE;
}
}
👍推荐的其它写法:枚举
//反编译:继承Enum枚举类
//final enum Singleton extends Enum{
// 类加载时创建对象
// public final static enum Singleton INSTANCE;
// }
//1、枚举单例是如何实现限制实例个数的? 每个枚举实例,都是一个单例对象
//2、枚举单例在创建时是否有有并发问题? 没有,final static实例会在类初始化的时候创建
//3、枚举单例能否被反序列化破坏单例? 枚举类默认实现序列化接口,可被序列化和反序列,但是不破坏单例
//4、枚举能否通过反射破坏单例? 不能。
//5、枚举单例属于饿汉式
//6、枚举单例中可以加入一些字段和构造方法,来初始化单例的属性
public enum Singleton {
INSTANCE;
public static Singleton GetInstance(){
return INSTANCE;
}
}
class SingleTest{
public static void main(String[] args) {
Singleton instance = Singleton.GetInstance();
Singleton instance1 = Singleton.INSTANCE;
// true
System.out.println(instance==instance1);
}
}
3.1.5 建造者模式
经常碰见的 XxxBuilder 的类,通常都是建造者模式的产物。建造者模式其实有很多的变种,但是对于客户端来说,我们的使用通常都是一个模式的:
Food food = new FoodBuilder().a().b().c().build();
Food food = Food.builder().a().b().c().build();
套路就是先 new 一个 Builder,然后可以链式地调用一堆方法,最后再调用一次 build() 方法,我们需要的对象就有了。
来一个中规中矩的建造者模式:
public class User {
private String id;
private String name;
private int age;
//不允许通过new创建
private User() {
}
public User(String id, String name, int age) {
this.id = id;
this.name = name;
this.age = age;
}
//获取建造者对象
public static UserBuilder builder() {
return new UserBuilder();
}
//使用静态内部类
public static class UserBuilder {
private String id;
private String name;
private int age;
public UserBuilder id(String id) {
this.id=id;
return this;
}
public UserBuilder name(String name) {
this.name=name;
return this;
}
public UserBuilder age(int age) {
this.age=age;
return this;
}
// build() 方法负责将 UserBuilder 中设置好的属性“复制”到 User 中。
// 当然,可以在 “复制” 之前做点检验
public User build() {
if (id == null) {
throw new RuntimeException("id不能为空");
}
if (name == null || "".equals(name)) {
throw new RuntimeException("姓名不能为空");
}
return new User(id, name, age);
}
}
//使用
public static void main(String[] args) {
User user = User.builder()
.id("1001")
.name("张三")
.age(18).build();
}
}
核心是:先把所有的属性都设置给 Builder,然后 build() 方法的时候,将这些属性复制给实际产生的对象。
强烈建议读者使用 lombok
,用了 lombok
以后,上面的一大堆代码会变成如下这样:
@Builder
public class User {
private String id;
private String name;
private int age;
//使用
public static void main(String[] args) {
User user = User.builder()
.id("1001")
.name("张三")
.age(18).build();
}
}
3.1.6 原型模式
原型模式很简单:有一个原型实例,基于这个原型实例产生新的实例,也就是“克隆”了。
Object 类中有一个 clone() 方法,它用于生成一个新的对象,当然,如果我们要调用这个方法,java 要求我们的类必须先实现 Cloneable 接口,此接口没有定义任何方法,但是不这么做的话,在 clone() 的时候,会抛出 CloneNotSupportedException 异常。
protected native Object clone() throws CloneNotSupportedException;
java 的克隆是浅克隆,碰到对象引用的时候,克隆出来的对象和原对象中的引用将指向同一个对象。通常实现深克隆的方法是将**
对象进行序列化,然后再进行反序列化
。**
创建型模式总结
创建型模式总体上比较简单,它们的作用就是为了产生实例对象,算是各种工作的第一步了,因为我们写的是面向对象的代码,所以我们第一步当然是需要创建一个对象了。
工厂方法模式在简单工厂模式的基础上增加了选择工厂的维度,需要第一步选择合适的工厂;
抽象工厂模式有产品族的概念,如果各个产品是存在兼容性问题的,就要用抽象工厂模式。
单例模式就不说了,为了保证全局使用的是同一对象,一方面是安全性考虑,一方面是为了节省资源;
建造者模式专门对付属性很多的那种类,为了让代码更优美;
原型模式用得最少,了解和 Object 类中的 clone() 方法相关的知识即可。
3.2 结构型模式
3.2.1 代理模式🌟
用一个代理来隐藏具体实现类的实现细节,通常还用于在真实的实现的前后添加一部分逻辑。既然说是代理,那就要对客户端隐藏真实实现,由代理来负责客户端的所有请求。当然,代理只是个代理,它不会完成实际的业务逻辑,而是一层皮而已,但是对于客户端来说,它必须表现得就是客户端需要的真实实现。
3.2.1.1 静态代理
- 代理类和目标对象的类都是在编译期间确定下来的叫静态代理。
- 静态代理模式在不改变目标对象的前提下,实现了对目标对象的功能扩展。
- 因为代理对象需要与目标对象实现一样的接口,所以会有很多代理类,类太多.同时,一旦接口增加方法,目标对象与代理对象都要维护.
public interface FoodService {
Food makeChicken();
Food makeNoodle();
}
public class FoodServiceImpl implements FoodService {
public Food makeChicken() {
Food f = new Chicken()
f.setChicken("1kg");
f.setSpicy("1g");
f.setSalt("3g");
return f;
}
public Food makeNoodle() {
Food f = new Noodle();
f.setNoodle("500g");
f.setSalt("5g");
return f;
}
}
// 代理要表现得“就像是”真实实现类,所以需要实现 FoodService
public class FoodServiceProxy implements FoodService {
// 内部一定要有一个真实的实现类,当然也可以通过构造方法注入
private FoodService foodService = new FoodServiceImpl();
public Food makeChicken() {
System.out.println("我们马上要开始制作鸡肉了");
// 如果我们定义这句为核心代码的话,那么,核心代码是真实实现类做的,
// 代理只是在核心代码前后做些“无足轻重”的事情
Food food = foodService.makeChicken();
System.out.println("鸡肉制作完成啦,加点胡椒粉"); // 增强
food.addCondiment("pepper");
return food;
}
public Food makeNoodle() {
System.out.println("准备制作拉面~");
Food food = foodService.makeNoodle();
System.out.println("制作完成啦")
return food;
}
}
客户端调用,注意,我们要用代理来实例化接口:
// 这里用代理类来实例化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();
3.2.1.2 JDK动态代理
- 代理对象不需要实现目标对象的接口。
- 代理对象的生成,是利用JDK的API,动态的在内存中构建代理对象(需要我们指定创建代理对象/目标对象实现的接口的类型)
- 代理对象不需要实现接口,但是目标对象一定要实现接口,否则不能用动态代理
- 动态代理也叫做:JDK代理,接口代理
Proxy中的newProxyInstance
方法
/**
* 获取代理对象
* @param loader 获取目标对象的类加载器。指定当前目标对象使用类加载器,获取加载器的方法是固定的
* @param interfaces 目标对象实现的接口的类型,使用泛型方式确认类型
* @param h 回调方法处理器。事件处理,执行目标对象的方法时,会触发事件处理器的方法,会把当前执行目标对象的方法作为参数传入
* @return 返回代理对象
*/
public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h){}
回调处理器InvocationHandler中的invoke
方法
public interface InvocationHandler {
/**
* 回调方法处理器
* @param proxy 代指当前代理对象 由jdk调用,我们无需操作
* @param method 当前要执行目标对象的方法
* @param args 方法的实际参数
* @return 返回方法的结果
* @throws Throwable
*/
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable;
}
示例:
//目标对象抽象接口
public interface IUserDao {
void save(String id);
String getUser();
}
//目标对象类
public class UserDao implements IUserDao {
@Override
public void save(String id) {
System.out.println("存储学生学号:"+id);
}
@Override
public String getUser() {
return "我是张三";
}
}
//代理工厂(获取代理对象)
public class ProxyFactory {
//被代理对象(目标对象)
private Object object;
//传入目标对象
public ProxyFactory(Object object) {
this.object = object;
}
//获取代理对象
public Object getProxyInstance() {
//利用反射获取代理对象
return Proxy.newProxyInstance(object.getClass().getClassLoader(), object.getClass().getInterfaces(), new InvocationHandler() {
//回调方法。相当于代理对象中对目标对象的方法调用
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
//回调方法之前执行的代码
System.out.println("transcation start...");
//回调当前目标对象执行的方法
//object 当前目标对象
//args 当前目标方法执行时传入的参数
//有值则返回,无则返回null
Object invokeValue = method.invoke(object, args);
//回调方法之后执行的代码
System.out.println("-----"+invokeValue);
System.out.println("transcation ending...");
//返回方法的执行结果
return invokeValue;
}
});
}
}
//测试
public class Main {
public static void main(String[] args) {
//创建代理工厂并传入目标对象
ProxyFactory proxyFactory = new ProxyFactory(new UserDao());
//获取代理对象(注意这里的对象必须为接口对象)
IUserDao proxyInstance = (IUserDao) proxyFactory.getProxyInstance();
//调用代理对象中的方法
proxyInstance.save("1001");
//若代理对象中的方法有返回值则返回此值。
String user = proxyInstance.getUser();
//我是张三
System.out.println(user);
}
}
//结果
transcation start...
存储学生学号:1001
-----null
transcation ending...
transcation start...
-----我是张三
transcation ending...
我是张三
3.2.1.3 CGLIB代理
上面的静态代理和动态代理模式都是要求目标对象是实现一个接口的目标对象,但是有时候目标对象只是一个单独的对象,并没有实现任何的接口,这个时候就可以使用以目标对象子类的方式类实现代理,这种方法就叫做:Cglib代理
Cglib代理,也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能的扩展.
- JDK的动态代理有一个限制,就是使用动态代理的对象必须实现一个或多个接口,如果想代理没有实现接口的类,就可以使用Cglib实现.
- Cglib是一个强大的高性能的代码生成包,它可以在运行期扩展java类与实现java接口.它广泛的被许多AOP的框架使用,例如Spring AOP和synaop,为他们提供方法的interception(拦截)
- Cglib包的底层是通过使用一个小而块的字节码处理框架ASM来转换字节码并生成新的类.不鼓励直接使用ASM,因为它要求你必须对JVM内部结构包括class文件的格式和指令集都很熟悉.
Cglib子类代理实现方法:
- 需要引入cglib的jar文件,但是Spring的核心包中已经包括了Cglib功能,所以直接引入
spring-core-3.2.5.jar
即可.
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>2.2.2</version>
</dependency>
- 引入功能包后,就可以在内存中动态构建子类
- 代理的类不能为final,否则报错
- 目标对象的方法如果为final/static,那么就不会被拦截,即不会执行目标对象额外的业务方法.
在Spring的AOP编程中:
- 如果加入容器的目标对象有实现接口,用JDK代理
- 如果目标对象没有实现接口,用Cglib代理
示例:
//目标对象类
public class UserDao {
public void save(String id) {
System.out.println("存储学生学号:"+id);
}
public String getUser() {
return "我是张三";
}
}
//代理工厂(基于目标对象的子类代理)
public class ProxyFactory implements MethodInterceptor {
//目标对象
private Object object;
//传入目标对象
public ProxyFactory(Object object) {
this.object = object;
}
//获取代理对象
public Object getProxyInstance() {
//1、工具类
Enhancer enhancer=new Enhancer();
//2、设置父类
enhancer.setSuperclass(object.getClass());
//3、设置回调函数(当前代理工厂)
enhancer.setCallback(this);
//4、创建子类(子类代理)
return enhancer.create();
}
@Override
public Object intercept(Object o, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
System.out.println("开始事务...");
//回调的方法
Object invokeValue = method.invoke(object, args);
System.out.println("----"+invokeValue);
System.out.println("事务结束...");
return invokeValue;
}
}
//测试
public class Main {
public static void main(String[] args) {
//创建代理工厂并传入目标对象
ProxyFactory proxyFactory = new ProxyFactory(new UserDao());
//获取代理对象(基于目标对象的子类代理)
UserDao userDao = (UserDao) proxyFactory.getProxyInstance();
userDao.save("019321");
String user = userDao.getUser();
System.out.println(user);
}
}
3.2.1.4 总结
**代理模式:**用一个代理类,在不改变原来目标方法的情况下,动态对目标方法进行扩展或增强。
静态代理:目标类和代理类都需要实现同一接口,并且在代理类中必须要有一个目标类的对象,代理类重写的方法中执行目标类对象的真正方法,并在目标类对象方法的前后加上代理增强的操作。
- 特点:代理类和目标类都是在编译期间确定下来的,所有叫静态代理
- **优点:在不改变目标类的情况下,**可以对目标对象功能进行扩展
- **缺点:因为目标类和代理类都需要实现同一接口,**所以一旦接口增加方法,则目标类和代理类都要维护。
JDK动态代理:也叫接口代理。代理对象的生成,是利用JVM在运行时动态生成字节码,即动态在内存中构建代理对象。使用的是Proxy.newProxyInstance获取代理对象,内部使用InvocationHandler 的invoke方法执行目标对象方法,并在invoke前后加上代理增强的操作。
- 特点:目标类必须实现接口,代理对象动态生成,无需手动实现接口类。
CGLIB动态代理:也叫子类代理。静态代理和JDK动态代理都需要目标类实现一个接口,而cglib代理无需目标对象实现接口。cglib是一个基于ASM的字节码生成库,也能在运行时动态生成字节码。使用的是Enhancer工具类实现的。
特点:目标类无需生成接口,cglib会在运行时为动态为目标对象生成子类对象,该子类对象即为代理类。因为代理对象中的方法增强是基于拦截目标对象,所以目标对象方法和类不能被final修饰。
3.2.2 适配器模式🌟
适配器模式做的就是,有一个接口需要实现,但是我们现成的对象都不满足,需要加一层适配器来进行适配。
适配器模式总体来说分三种:默认适配器模式、对象适配器模式、类适配器模式
3.2.2.1 默认适配器模式
Appache commons-io 包中的 FileAlterationListener 做例子,此接口定义了很多的方法,用于对文件或文件夹进行监控,一旦发生了对应的操作,就会触发相应的方法。
public interface FileAlterationListener {
void onStart(final FileAlterationObserver observer);
void onDirectoryCreate(final File directory);
void onDirectoryChange(final File directory);
void onDirectoryDelete(final File directory);
void onFileCreate(final File file);
void onFileChange(final File file);
void onFileDelete(final File file);
void onStop(final FileAlterationObserver observer);
}
此接口的一大问题是抽象方法太多了,如果我们要用这个接口,意味着我们要实现每一个抽象方法,如果我们只是想要监控文件夹中的文件创建和文件删除事件,可是我们还是不得不实现所有的方法,很明显,这不是我们想要的。
所以,我们需要下面的一个适配器,它用于实现上面的接口,但是所有的方法都是空方法,这样,我们就可以转而定义自己的类来继承下面这个类即可。
public class FileAlterationListenerAdaptor implements FileAlterationListener {
public FileAlterationListenerAdaptor() {
}
public void onStart(FileAlterationObserver observer) {
}
public void onDirectoryCreate(File directory) {
}
public void onDirectoryChange(File directory) {
}
public void onDirectoryDelete(File directory) {
}
public void onFileCreate(File file) {
}
public void onFileChange(File file) {
}
public void onFileDelete(File file) {
}
public void onStop(FileAlterationObserver observer) {
}
}
比如我们可以定义以下类,我们仅仅需要实现我们想实现的方法就可以了:
public class FileMonitor extends FileAlterationListenerAdaptor {
public void onFileCreate(final File file) {
// 文件创建
doSomething();
}
public void onFileDelete(final File file) {
// 文件删除
doSomething();
}
}
3.2.2.2 对象适配器模式
《Head First 设计模式》中的一个例子,看看怎么将鸡适配成鸭,这样鸡也能当鸭来用。因为,现在鸭这个接口,我们没有合适的实现类可以用,所以需要适配器。
//鸭类
interface Duck{
// 鸭子可以呱呱叫
public void quack();
// 鸭子可以飞
public void fly();
}
//鸡类
interface Cock{
// 鸡可以咕咕叫
public void gobble();
// 鸡可以飞
public void fly();
}
//野鸡实现鸡类
class WildCock implements Cock {
@Override
public void gobble() {
System.out.println("咕咕叫");
}
@Override
public void fly() {
System.out.println("鸡也会飞哦");
}
}
鸭接口有 fly() 和 quare() 两个方法,鸡 Cock 如果要冒充鸭,fly() 方法是现成的,但是鸡不会鸭的呱呱叫,没有 quack() 方法。这个时候就需要适配了:
class CockAdapter implements Duck{
//内部通过鸡适配
private Cock cock;
//通过构造器传进来
public CockAdapter(Cock cock) {
this.cock = cock;
}
//鸭的呱呱叫
@Override
public void quack() {
//内部还是鸡叫
cock.gobble();
}
@Override
public void fly() {
cock.fly();
}
}
客户端调用很简单了:
public static void main(String[] args) {
//一只野鸡
WildCock cock = new WildCock();
//将野鸡放进装饰器中
Duck duck = new CockAdapter(cock);
duck.quack();
}
3.2.2.3 类适配器模式
类适配器模式只是把装饰类中通过构造器传进来的需要转换的类替代为继承实现。
//鸭类
interface Duck{
// 鸭子可以呱呱叫
public void quack();
// 鸭子可以飞
public void fly();
}
//鸡类
interface Cock{
// 鸡可以咕咕叫
public void gobble();
// 鸡可以飞
public void fly();
}
//野鸡实现鸡类
class WildCock implements Cock {
@Override
public void gobble() {
System.out.println("咕咕叫");
}
@Override
public void fly() {
System.out.println("鸡也会飞哦");
}
}
//装饰类直接继承
class CockAdapter extends WildCock implements Duck{
//鸭的呱呱叫
@Override
public void quack() {
//内部还是鸡叫
gobble();
}
@Override
public void fly() {
super.fly();
}
}
客户端调用:
public static void main(String[] args) {
Duck duck = new CockAdapter();
duck.quack();
}
通过继承的方法,适配器自动获得了所需要的大部分方法。这个时候,客户端使用更加简单,直接 Target t = new SomeAdapter();
就可以了。
3.2.2.4 总结
类适配和对象适配的异同:
一个采用继承,一个采用组合;
类适配属于静态实现,对象适配属于组合的动态实现,对象适配需要多实例化一个对象。
总体来说,对象适配用得比较多。
适配器模式和代理模式的异同:
比较这两种模式,其实是比较对象适配器模式和代理模式,在代码结构上,它们很相似,都需要一个具体的实现类的实例。但是它们的目的不一样,代理模式做的是增强原方法的活;适配器做的是适配的活,为的是提供“把鸡包装成鸭,然后当做鸭来使用”,而鸡和鸭它们之间原本没有继承关系。
3.2.3 桥梁模式
理解桥梁模式,其实就是理解代码抽象和解耦。
我们首先需要一个桥梁,它是一个接口,定义提供的接口方法。
public interface DrawAPI {
public void draw(int radius, int x, int y);
}
然后是一系列实现类
public class RedPen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class GreenPen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class BluePen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用蓝色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
}
}
定义一个抽象类,此类的实现类都需要使用 DrawAPI:
public abstract class Shape {
protected DrawAPI drawAPI;
protected Shape(DrawAPI drawAPI) {
this.drawAPI = drawAPI;
}
public abstract void draw();
}
定义抽象类的子类:
// 圆形
public class Circle extends Shape {
private int radius;
public Circle(int radius, DrawAPI drawAPI) {
super(drawAPI);
this.radius = radius;
}
public void draw() {
drawAPI.draw(radius, 0, 0);
}
}
// 长方形
public class Rectangle extends Shape {
private int x;
private int y;
public Rectangle(int x, int y, DrawAPI drawAPI) {
super(drawAPI);
this.x = x;
this.y = y;
}
public void draw() {
drawAPI.draw(0, x, y);
}
}
最后,我们来看客户端演示:
public static void main(String[] args) {
Shape greenCircle = new Circle(10, new GreenPen());
Shape redRectangle = new Rectangle(4, 8, new RedPen());
greenCircle.draw();
redRectangle.draw();
}
3.2.4 装饰模式🌟
从图中可以看到,接口 Component
其实已经有了 ConcreteComponentA
和 ConcreteComponentB
两个实现类了,但是,如果我们要增强这两个实现类的话,我们就可以采用装饰模式,用具体的装饰器来装饰实现类,以达到增强的目的。
从名字来简单解释下装饰器。既然说是装饰,那么往往就是添加小功能这种,而且,我们要满足可以添加多个小功能。最简单的,代理模式就可以实现功能的增强,但是
代理不容易实现多个功能的增强
,当然你可以说用代理包装代理的多层包装方式,但是那样的话代码就复杂了。
首先明白一些简单的概念,从图中我们看到,所有的具体装饰者们 ConcreteDecorator* 都可以作为 Component 来使用,因为它们都实现了 Component 中的所有接口。它们和 Component 实现类 ConcreteComponent* 的区别是,它们只是装饰者,起装饰作用,也就是即使它们看上去牛逼轰轰,但是它们都只是在具体的实现中加了层皮来装饰而已。
下面来看看一个例子,先把装饰模式弄清楚,然后再介绍下 java io 中的装饰模式的应用。
最近大街上流行起来了“快乐柠檬”,我们把快乐柠檬的饮料分为三类:红茶、绿茶、咖啡,在这三大类的基础上,又增加了许多的口味,什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等,每家店都有很长的菜单,但是仔细看下,其实原料也没几样,但是可以搭配出很多组合,如果顾客需要,很多没出现在菜单中的饮料他们也是可以做的。
在这个例子中,红茶、绿茶、咖啡是最基础的饮料,其他的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。当然,在开发中,我们确实可以像门店一样,开发这些类:LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是,很快我们就发现,这样子干肯定是不行的,这会导致我们需要组合出所有的可能,而且如果客人需要在红茶中加双份柠檬怎么办?三份柠檬怎么办?
首先,定义饮料抽象基类:
/**
* 饮料类
*/
public abstract class Beverage {
//获取描述
public abstract String description();
//获取价格
public abstract double cost();
}
然后是三个基础饮料实现类,红茶、绿茶和咖啡:
public class BlackTea extends Beverage {
@Override
public String description() {
return "红茶";
}
@Override
public double cost() {
return 10;
}
}
public class GreenTea extends Beverage{
@Override
public String description() {
return "绿茶";
}
@Override
public double cost() {
return 11;
}
}
public class Coffee extends Beverage{
@Override
public String description() {
return "咖啡";
}
@Override
public double cost() {
return 12;
}
}
定义调料,也就是装饰者的基类,此类必须继承自 Beverage:
/**
* 调料类
*/
public abstract class Condiment extends Beverage{
}
然后我们来定义柠檬、芒果等具体的调料,它们属于装饰者,毫无疑问,这些调料肯定都需要继承调料 Condiment 类:
/**
* 柠檬
*/
public class Lemon extends Condiment{
private Beverage beverage;
// 这里很关键,需要传入具体的饮料,如需要传入没有被装饰的红茶或绿茶,
// 当然也可以传入已经装饰好的芒果绿茶,这样可以做芒果柠檬绿茶
public Lemon(Beverage beverage) {
this.beverage = beverage;
}
@Override
public String description() {
return beverage.description() + ",加柠檬";
}
@Override
public double cost() {
return beverage.cost() + 2; //加柠檬需要加2元
}
}
public class Mango extends Condiment{
private Beverage beverage;
public Mango(Beverage beverage) {
this.beverage = beverage;
}
@Override
public String description() {
return beverage.description()+",加芒果";
}
@Override
public double cost() {
return beverage.cost() + 3;//芒果加3元
}
}
看客户端调用:
public class Test {
public static void main(String[] args) {
//来一种茶
Beverage beverage = new GreenTea();
//加一个柠檬
beverage = new Lemon(beverage);
//加一个芒果
beverage = new Mango(beverage);
System.out.println("饮料:" + beverage.description() + " 价格:" + beverage.cost());
}
}
看下图 InputStream 派生出来的部分类:
我们知道 InputStream 代表了输入流,具体的输入来源可以是文件(FileInputStream)、管道(PipedInputStream)、数组(ByteArrayInputStream)等,这些就像前面奶茶的例子中的红茶、绿茶,属于基础输入流。
FilterInputStream 承接了装饰模式的关键节点,它的实现类是一系列装饰器,比如 BufferedInputStream 代表用缓冲来装饰,也就使得输入流具有了缓冲的功能,LineNumberInputStream 代表用行号来装饰,在操作的时候就可以取得行号了,DataInputStream 的装饰,使得我们可以从输入流转换为 java 中的基本类型值。
3.2.5 门面模式
门面模式(也叫外观模式,Facade Pattern)在许多源码中有使用,比如 slf4j 就可以理解为是门面模式的应用
首先,我们定义一个接口:
public interface Shape {
void draw();
}
定义几个实现类:
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Circle::draw()");
}
}
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}
客户端调用:
public static void main(String[] args) {
// 画一个圆形
Shape circle = new Circle();
circle.draw();
// 画一个长方形
Shape rectangle = new Rectangle();
rectangle.draw();
}
以上是我们常写的代码,我们需要画圆就要先实例化圆,画长方形就需要先实例化一个长方形,然后再调用相应的 draw() 方法。
使用门面模式来让客户端调用:
我们先定义一个门面:
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
/**
* 下面定义一堆方法,具体应该调用什么方法,由这个门面来决定
*/
public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}
看看现在客户端怎么调用:
public static void main(String[] args) {
ShapeMaker shapeMaker = new ShapeMaker();
// 客户端调用现在更加清晰了
shapeMaker.drawCircle();
shapeMaker.drawRectangle();
shapeMaker.drawSquare();
}
门面模式的优点显而易见,客户端不再需要关注实例化时应该使用哪个实现类,直接调用门面提供的方法就可以了,因为门面类提供的方法的方法名对于客户端来说已经很友好了。
3.2.6 组合模式
组合模式用于表示具有层次结构的数据,使得我们对单个对象和组合对象的访问具有一致性。
直接看一个例子吧,每个员工都有姓名、部门、薪水这些属性,同时还有下属员工集合(虽然可能集合为空),而下属员工和自己的结构是一样的,也有姓名、部门这些属性,同时也有他们的下属员工集合。
public class Employee {
private String name;
private String dept;
private int salary;
private List<Employee> subordinates; // 下属
public Employee(String name,String dept, int sal) {
this.name = name;
this.dept = dept;
this.salary = sal;
subordinates = new ArrayList<Employee>();
}
public void add(Employee e) {
subordinates.add(e);
}
public void remove(Employee e) {
subordinates.remove(e);
}
public List<Employee> getSubordinates(){
return subordinates;
}
public String toString(){
return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
}
}
通常,这种类需要定义 add(node)、remove(node)、getChildren() 这些方法。
3.2.7 享元模式
英文是 Flyweight Pattern,不知道是谁最先翻译的这个词,感觉这翻译真的不好理解,我们试着强行关联起来吧。Flyweight 是轻量级的意思,享元分开来说就是 共享 元器件,也就是复用已经生成的对象,这种做法当然也就是轻量级的了。
复用对象最简单的方式是,用一个 HashMap 来存放每次新生成的对象。每次需要一个对象的时候,先到 HashMap 中看看有没有,如果没有,再生成新的对象,然后将这个对象放入 HashMap 中。
结构型模式总结
代理模式是做方法增强的
适配器模式是把鸡包装成鸭这种用来适配接口的
桥梁模式做到了很好的解耦
装饰模式从名字上就看得出来,适合于装饰类或者说是增强类的场景
门面模式的优点是客户端不需要关心实例化过程,只要调用需要的方法即可
组合模式用于描述具有层次结构的数据
享元模式是为了在特定的场景中缓存已经创建的对象,用于提高性能。
3.3 行为型模式
行为型模式关注的是各个类之间的相互作用,将职责划分清楚,使得我们的代码更加地清晰。
3.3.1 策略模式🌟
下面设计的场景是,我们需要画一个图形,可选的策略就是用红色笔来画,还是绿色笔来画,或者蓝色笔来画。
首先,先定义一个策略接口:
public interface Strategy {
public void draw(int radius, int x, int y);
}
然后我们定义具体的几个策略:
public class RedPen implements Strategy {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class GreenPen implements Strategy {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class BluePen implements Strategy {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用蓝色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
}
}
使用策略的类:
public class Context {
private Strategy strategy;
public Context(Strategy strategy) {
this.strategy = strategy;
}
public void executeDraw(int radius, int x, int y){
strategy.draw(radius, x, y);
}
}
客户端演示:
public static void main(String[] args) {
Context context = new Context(new BluePen()); // 使用绿色笔来画
context.executeDraw(10, 0, 0);
}
策略模式如图:
这个时候,大家有没有联想到结构型模式中的桥梁模式,它们其实非常相似,我把桥梁模式的图拿过来大家对比下:
桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低,结构更复杂一些。
3.3.2 观察者模式🌟
观察者模式对于我们来说,真是再简单不过了。无外乎两个操作,观察者订阅自己关心的主题和主题有数据变化后通知观察者们。
首先,需要定义主题,每个主题需要持有观察者列表的引用,用于在数据变更的时候通知各个观察者:
public class Subject {
private List<Observer> observers = new ArrayList<Observer>();
private int state;
public int getState() {
return state;
}
public void setState(int state) {
this.state = state;
// 数据已变更,通知观察者们
notifyAllObservers();
}
// 注册观察者
public void attach(Observer observer) {
observers.add(observer);
}
// 通知观察者们
public void notifyAllObservers() {
for (Observer observer : observers) {
observer.update();
}
}
}
定义观察者接口:
public abstract class Observer {
protected Subject subject;
public abstract void update();
}
其实如果只有一个观察者类的话,接口都不用定义了,不过,通常场景下,既然用到了观察者模式,我们就是希望一个事件出来了,会有多个不同的类需要处理相应的信息。比如,订单修改成功事件,我们希望发短信的类得到通知、发邮件的类得到通知、处理物流信息的类得到通知等。
我们来定义具体的几个观察者类:
public class BinaryObserver extends Observer {
// 在构造方法中进行订阅主题
public BinaryObserver(Subject subject) {
this.subject = subject;
// 通常在构造方法中将 this 发布出去的操作一定要小心
this.subject.attach(this);
}
// 该方法由主题类在数据变更的时候进行调用
@Override
public void update() {
String result = Integer.toBinaryString(subject.getState());
System.out.println("订阅的数据发生变化,新的数据处理为二进制值为:" + result);
}
}
public class HexaObserver extends Observer {
public HexaObserver(Subject subject) {
this.subject = subject;
this.subject.attach(this);
}
@Override
public void update() {
String result = Integer.toHexString(subject.getState()).toUpperCase();
System.out.println("订阅的数据发生变化,新的数据处理为十六进制值为:" + result);
}
}
客户端使用也非常简单:
public static void main(String[] args) {
// 先定义一个主题
Subject subject1 = new Subject();
// 定义观察者
new BinaryObserver(subject1);
new HexaObserver(subject1);
// 模拟数据变更,这个时候,观察者们的 update 方法将会被调用
subject.setState(11);
}
订阅的数据发生变化,新的数据处理为二进制值为:1011
订阅的数据发生变化,新的数据处理为十六进制值为:B
当然,jdk 也提供了相似的支持,具体的大家可以参考 java.util.Observable 和 java.util.Observer 这两个类。
实际生产过程中,观察者模式往往用消息中间件来实现,如果要实现单机观察者模式,笔者建议读者使用 Guava 中的 EventBus,它有同步实现也有异步实现,本文主要介绍设计模式,就不展开说了。
还有,即使是上面的这个代码,也会有很多变种,大家只要记住核心的部分,那就是一定有一个地方存放了所有的观察者,然后在事件发生的时候,遍历观察者,调用它们的回调函数。
3.3.3 责任链模式
责任链通常需要先建立一个单向链表,然后调用方只需要调用头部节点就可以了,后面会自动流转下去。比如流程审批就是一个很好的例子,只要终端用户提交申请,根据申请的内容信息,自动建立一条责任链,然后就可以开始流转了。
有这么一个场景,用户参加一个活动可以领取奖品,但是活动需要进行很多的规则校验然后才能放行,比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后,才能让用户领走奖品。
首先,我们要定义流程上节点的基类:
public abstract class RuleHandler {
// 后继节点
protected RuleHandler successor;
public abstract void apply(Context context);
public void setSuccessor(RuleHandler successor) {
this.successor = successor;
}
public RuleHandler getSuccessor() {
return successor;
}
}
接下来,我们需要定义具体的每个节点了。
校验用户是否是新用户:
public class NewUserRuleHandler extends RuleHandler {
public void apply(Context context) {
if (context.isNewUser()) {
// 如果有后继节点的话,传递下去
if (this.getSuccessor() != null) {
this.getSuccessor().apply(context);
}
} else {
throw new RuntimeException("该活动仅限新用户参与");
}
}
}
校验用户所在地区是否可以参与:
public class LocationRuleHandler extends RuleHandler {
public void apply(Context context) {
boolean allowed = activityService.isSupportedLocation(context.getLocation);
if (allowed) {
if (this.getSuccessor() != null) {
this.getSuccessor().apply(context);
}
} else {
throw new RuntimeException("非常抱歉,您所在的地区无法参与本次活动");
}
}
}
校验奖品是否已领完:
public class LimitRuleHandler extends RuleHandler {
public void apply(Context context) {
int remainedTimes = activityService.queryRemainedTimes(context); // 查询剩余奖品
if (remainedTimes > 0) {
if (this.getSuccessor() != null) {
this.getSuccessor().apply(userInfo);
}
} else {
throw new RuntimeException("您来得太晚了,奖品被领完了");
}
}
}
客户端:
public static void main(String[] args) {
RuleHandler newUserHandler = new NewUserRuleHandler();
RuleHandler locationHandler = new LocationRuleHandler();
RuleHandler limitHandler = new LimitRuleHandler();
// 假设本次活动仅校验地区和奖品数量,不校验新老用户
locationHandler.setSuccessor(limitHandler);
locationHandler.apply(context);
}
代码其实很简单,就是先定义好一个链表,然后在通过任意一节点后,如果此节点有后继节点,那么传递下去。
3.3.4 模版方法模式🌟
在含有继承结构的代码中,模板方法模式是非常常用的。
通常会有一个抽象类:
public abstract class AbstractTemplate {
// 这就是模板方法
public void templateMethod() {
init();
apply(); // 这个是重点
end(); // 可以作为钩子方法
}
protected void init() {
System.out.println("init 抽象层已经实现,子类也可以选择覆写");
}
// 留给子类实现
protected abstract void apply();
protected void end() {
}
}
模板方法中调用了 3 个方法,其中 apply() 是抽象方法,子类必须实现它,其实模板方法中有几个抽象方法完全是自由的,我们也可以将三个方法都设置为抽象方法,让子类来实现。也就是说,模板方法只负责定义第一步应该要做什么,第二步应该做什么,第三步应该做什么,至于怎么做,由子类来实现。
我们写一个实现类:
public class ConcreteTemplate extends AbstractTemplate {
public void apply() {
System.out.println("子类实现抽象方法 apply");
}
public void end() {
System.out.println("我们可以把 method3 当做钩子方法来使用,需要的时候覆写就可以了");
}
}
客户端调用演示:
public static void main(String[] args) {
AbstractTemplate t = new ConcreteTemplate();
// 调用模板方法
t.templateMethod();
}
3.3.5 状态模式
商品库存中心有个最基本的需求是减库存和补库存,我们看看怎么用状态模式来写。
核心在于,我们的关注点不再是 Context 是该进行哪种操作,而是关注在这个 Context 会有哪些操作。
定义状态接口:
public interface State {
public void doAction(Context context);
}
定义减库存的状态:
public class DeductState implements State {
public void doAction(Context context) {
System.out.println("商品卖出,准备减库存");
context.setState(this);
//... 执行减库存的具体操作
}
public String toString() {
return "Deduct State";
}
}
定义补库存状态:
public class RevertState implements State {
public void doAction(Context context) {
System.out.println("给此商品补库存");
context.setState(this);
//... 执行加库存的具体操作
}
public String toString() {
return "Revert State";
}
}
前面用到了 context.setState(this)
,我们来看看怎么定义 Context 类:
public class Context {
private State state;
private String name;
public Context(String name) {
this.name = name;
}
public void setState(State state) {
this.state = state;
}
public void getState() {
return this.state;
}
}
我们来看下客户端调用,大家就一清二楚了:
public static void main(String[] args) {
// 我们需要操作的是 iPhone X
Context context = new Context("iPhone X");
// 看看怎么进行补库存操作
State revertState = new RevertState();
revertState.doAction(context);
// 同样的,减库存操作也非常简单
State deductState = new DeductState();
deductState.doAction(context);
// 如果需要我们可以获取当前的状态
// context.getState().toString();
}
读者可能会发现,在上面这个例子中,如果我们不关心当前 context 处于什么状态,那么 Context 就可以不用维护 state 属性了,那样代码会简单很多。