25000 字详解 23 种设计模式(多图 + 代码)

核心提示一直想写一篇介绍设计模式的文章,让读者可以很快看完,而且一看就懂,看懂就会用,同时不会将各个模式搞混。自认为本文还是写得不错的 ,花了不少心思来写这文章和做图,力求让读者真的能看着简单同时有所收获。设计模式是对大家实际工作中写的各种代码

一直想写一篇介绍设计模式的文章,让读者可以很快看完,而且一看就懂,看懂就会用,同时不会将各个模式搞混。自认为本文还是写得不错的 ,花了不少心思来写这文章和做图,力求让读者真的能看着简单同时有所收获。

设计模式是对大家实际工作中写的各种代码进行高层次抽象的总结,其中最出名的当属 Gang of Four 的分类了,他们将设计模式分类为 23 种经典的模式,根据用途我们又可以分为三大类,分别为创建型模式、结构型模式和行为型模式。

有一些重要的设计原则在开篇和大家分享下,这些原则将贯通全文:

  1. 面向接口编程,而不是面向实现。这个很重要,也是优雅的、可扩展的代码的第一步,这就不需要多说了吧。
  2. 职责单一原则。每个类都应该只有一个单一的功能,并且该功能应该由这个类完全封装起来。
  3. 对修改关闭,对扩展开放。对修改关闭是说,我们辛辛苦苦加班写出来的代码,该实现的功能和该修复的 bug 都完成了,别人可不能说改就改;对扩展开放就比较好理解了,也就是说在我们写好的代码基础上,很容易实现扩展。

创建型模式比较简单,但是会比较没有意思,结构型和行为型比较有意思。

创建型模式

创建型模式的作用就是创建对象,说到创建一个对象,最熟悉的就是 new 一个对象,然后 set 相关属性。但是,在很多场景下,我们需要给客户端提供更加友好的创建对象的方式,尤其是那种我们定义了类,但是需要提供给其他开发者用的时候。

简单工厂模式

和名字一样简单,非常简单,直接上代码吧:

public class FoodFactory { public static Food makeFood { if ) { Food noodle = new LanZhouNoodle; noodle.addSpicy; return noodle; } else if ) { Food chicken = new HuangMenChicken; chicken.addCondiment; return chicken; } else { return null; } } }

其中,LanZhouNoodle 和 HuangMenChicken 都继承自 Food。

简单地说,简单工厂模式通常就是这样,一个工厂类 XxxFactory,里面有一个静态方法,根据我们不同的参数,返回不同的派生自同一个父类(或实现同一接口)的实例对象。

我们强调职责单一原则,一个类只提供一种功能,FoodFactory 的功能就是只要负责生产各种 Food。
工厂模式

简单工厂模式很简单,如果它能满足我们的需要,我觉得就不要折腾了。之所以需要引入工厂模式,是因为我们往往需要使用两个或两个以上的工厂。

public interface FoodFactory { Food makeFood; } public class ChineseFoodFactory implements FoodFactory { @Override public Food makeFood { if ) { return new ChineseFoodA; } else if ) { return new ChineseFoodB; } else { return null; } } } public class AmericanFoodFactory implements FoodFactory { @Override public Food makeFood { if ) { return new AmericanFoodA; } else if ) { return new AmericanFoodB; } else { return null; } } }

其中,ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB 都派生自 Food。

客户端调用:

public class APP { public static void main { // 先选择一个具体的工厂 FoodFactory factory = new ChineseFoodFactory; // 由第一步的工厂产生具体的对象,不同的工厂造出不一样的对象 Food food = factory.makeFood; } }

虽然都是调用 makeFood 制作 A 类食物,但是,不同的工厂生产出来的完全不一样。

第一步,我们需要选取合适的工厂,然后第二步基本上和简单工厂一样。

核心在于,我们需要在第一步选好我们需要的工厂。比如,我们有 LogFactory 接口,实现类有 FileLogFactory 和 KafkaLogFactory,分别对应将日志写入文件和写入 Kafka 中,显然,我们客户端第一步就需要决定到底要实例化 FileLogFactory 还是 KafkaLogFactory,这将决定之后的所有的操作。

虽然简单,不过我也把所有的构件都画到一张图上,这样读者看着比较清晰:

这个时候的客户端调用是这样的:

// 得到 Intel 的 CPU CPUFactory cpuFactory = new IntelCPUFactory; CPU cpu = intelCPUFactory.makeCPU; // 得到 AMD 的主板 MainBoardFactory mainBoardFactory = new AmdMainBoardFactory; MainBoard mainBoard = mainBoardFactory.make; // 组装 CPU 和主板 Computer computer = new Computer;

单独看 CPU 工厂和主板工厂,它们分别是前面我们说的工厂模式。这种方式也容易扩展,因为要给电脑加硬盘的话,只需要加一个 HardDiskFactory 和相应的实现即可,不需要修改现有的工厂。

但是,这种方式有一个问题,那就是如果 Intel 家产的 CPU 和 AMD 产的主板不能兼容使用,那么这代码就容易出错,因为客户端并不知道它们不兼容,也就会错误地出现随意组合。

下面就是我们要说的产品族的概念,它代表了组成某个产品的一系列附件的集合:

这个时候,对于客户端来说,不再需要单独挑选 CPU厂商、主板厂商、硬盘厂商等,直接选择一家品牌工厂,品牌工厂会负责生产所有的东西,而且能保证肯定是兼容可用的。

public static void main { // 第一步就要选定一个“大厂” ComputerFactory cf = new AmdFactory; // 从这个大厂造 CPU CPU cpu = cf.makeCPU; // 从这个大厂造主板 MainBoard board = cf.makeMainBoard; // 从这个大厂造硬盘 HardDisk hardDisk = cf.makeHardDisk; // 将同一个厂子出来的 CPU、主板、硬盘组装在一起 Computer result = new Computer; }

当然,抽象工厂的问题也是显而易见的,比如我们要加个显示器,就需要修改所有的工厂,给所有的工厂都加上制造显示器的方法。这有点违反了对修改关闭,对扩展开放这个设计原则。

单例模式

单例模式用得最多,错得最多。

饿汉模式最简单:

public class Singleton { // 首先,将 new Singleton 堵死 private Singleton {}; // 创建私有静态实例,意味着这个类第一次使用的时候就会进行创建 private static Singleton instance = new Singleton; public static Singleton getInstance { return instance; } // 瞎写一个静态方法。这里想说的是,如果我们只是要调用 Singleton.getDate, // 本来是不想要生成 Singleton 实例的,不过没办法,已经生成了 public static Date getDate {return new Date;} }

很多人都能说出饿汉模式的缺点,可是我觉得生产过程中,很少碰到这种情况:你定义了一个单例的类,不需要其实例,可是你却把一个或几个你会用到的静态方法塞到这个类中。

饱汉模式最容易出错:

public class Singleton { // 首先,也是先堵死 new Singleton 这条路 private Singleton {} // 和饿汉模式相比,这边不需要先实例化出来,注意这里的 volatile,它是必须的 private static volatile Singleton instance = null; public static Singleton getInstance { if { // 加锁 synchronized { // 这一次判断也是必须的,不然会有并发问题 if { instance = new Singleton; } } } return instance; } }

双重检查,指的是两次检查 instance 是否为 null。
volatile 在这里是需要的,希望能引起读者的关注。
很多人不知道怎么写,直接就在 getInstance 方法签名上加上 synchronized,这就不多说了,性能太差。

嵌套类最经典,以后大家就用它吧:

public class Singleton3 { private Singleton3 {} // 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法 的特性 private static class Holder { private static Singleton3 instance = new Singleton3; } public static Singleton3 getInstance { return Holder.instance; } }

注意,很多人都会把这个嵌套类说成是静态内部类,严格地说,内部类和嵌套类是不一样的,它们能访问的外部类权限也是不一样的。

最后,我们说一下枚举,枚举很特殊,它在类加载的时候会初始化里面的所有的实例,而且 JVM 保证了它们不会再被实例化,所以它天生就是单例的。

虽然我们平时很少看到用枚举来实现单例,但是在 RxJava 的源码中,有很多地方都用了枚举来实现单例。

建造者模式

经常碰见的 XxxBuilder 的类,通常都是建造者模式的产物。建造者模式其实有很多的变种,但是对于客户端来说,我们的使用通常都是一个模式的:

Food food = new FoodBuilder.a.b.c.build; Food food = Food.builder.a.b.c.build;

套路就是先 new 一个 Builder,然后可以链式地调用一堆方法,最后再调用一次 build 方法,我们需要的对象就有了。

来一个中规中矩的建造者模式:

class User { // 下面是“一堆”的属性 private String name; private String password; private String nickName; private int age; // 构造方法私有化,不然客户端就会直接调用构造方法了 private User { this.name = name; this.password = password; this.nickName = nickName; this.age = age; } // 静态方法,用于生成一个 Builder,这个不一定要有,不过写这个方法是一个很好的习惯, // 有些代码要求别人写 new User.UserBuilder.a...build 看上去就没那么好 public static UserBuilder builder { return new UserBuilder; } public static class UserBuilder { // 下面是和 User 一模一样的一堆属性 private String name; private String password; private String nickName; private int age; private UserBuilder { } // 链式调用设置各个属性值,返回 this,即 UserBuilder public UserBuilder name { this.name = name; return this; } public UserBuilder password { this.password = password; return this; } public UserBuilder nickName { this.nickName = nickName; return this; } public UserBuilder age { this.age = age; return this; } // build 方法负责将 UserBuilder 中设置好的属性“复制”到 User 中。 // 当然,可以在 “复制” 之前做点检验 public User build { if { throw new RuntimeException; } if { throw new RuntimeException; } // 还可以做赋予”默认值“的功能 if { nickName = name; } return new User; } } }

核心是:先把所有的属性都设置给 Builder,然后 build 方法的时候,将这些属性复制给实际产生的对象。

看看客户端的调用:

public class APP { public static void main { User d = User.builder .name .password .age .build; } }

说实话,建造者模式的链式写法很吸引人,但是,多写了很多“无用”的 builder 的代码,感觉这个模式没什么用。不过,当属性很多,而且有些必填,有些选填的时候,这个模式会使代码清晰很多。我们可以在 Builder 的构造方法中强制让调用者提供必填字段,还有,在 build 方法中校验各个参数比在 User 的构造方法中校验,代码要优雅一些。

题外话,强烈建议读者使用 lombok,用了 lombok 以后,上面的一大堆代码会变成如下这样:

@Builder class User { private String name; private String password; private String nickName; private int age; }

怎么样,省下来的时间是不是又可以干点别的了。

当然,如果你只是想要链式写法,不想要建造者模式,有个很简单的办法,User 的 getter 方法不变,所有的 setter 方法都让其 return this 就可以了,然后就可以像下面这样调用:

User user = new User.setName.setPassword.setAge;

很多人是这么用的,但是笔者觉得其实这种写法非常地不优雅,不是很推荐使用。
原型模式

这是我要说的创建型模式的最后一个设计模式了。

原型模式很简单:有一个原型实例,基于这个原型实例产生新的实例,也就是“克隆”了。

Object 类中有一个 clone 方法,它用于生成一个新的对象,当然,如果我们要调用这个方法,java 要求我们的类必须先实现 Cloneable 接口,此接口没有定义任何方法,但是不这么做的话,在 clone 的时候,会抛出 CloneNotSupportedException 异常。

protected native Object clone throws CloneNotSupportedException;

java 的克隆是浅克隆,碰到对象引用的时候,克隆出来的对象和原对象中的引用将指向同一个对象。通常实现深克隆的方法是将对象进行序列化,然后再进行反序列化。

原型模式了解到这里我觉得就够了,各种变着法子说这种代码或那种代码是原型模式,没什么意义。

创建型模式总结

创建型模式总体上比较简单,它们的作用就是为了产生实例对象,算是各种工作的第一步了,因为我们写的是面向对象的代码,所以我们第一步当然是需要创建一个对象了。

简单工厂模式最简单;工厂模式在简单工厂模式的基础上增加了选择工厂的维度,需要第一步选择合适的工厂;抽象工厂模式有产品族的概念,如果各个产品是存在兼容性问题的,就要用抽象工厂模式。

单例模式就不说了,为了保证全局使用的是同一对象,一方面是安全性考虑,一方面是为了节省资源;建造者模式专门对付属性很多的那种类,为了让代码更优美;原型模式用得最少,了解和 Object 类中的 clone 方法相关的知识即可。

结构型模式

前面创建型模式介绍了创建对象的一些设计模式,这节介绍的结构型模式旨在通过改变代码结构来达到解耦的目的,使得我们的代码容易维护和扩展。

代理模式

第一个要介绍的代理模式是最常使用的模式之一了,用一个代理来隐藏具体实现类的实现细节,通常还用于在真实的实现的前后添加一部分逻辑。

既然说是代理,那就要对客户端隐藏真实实现,由代理来负责客户端的所有请求。当然,代理只是个代理,它不会完成实际的业务逻辑,而是一层皮而已,但是对于客户端来说,它必须表现得就是客户端需要的真实实现。

理解代理这个词,这个模式其实就简单了。

public interface FoodService { Food makeChicken; Food makeNoodle; } public class FoodServiceImpl implements FoodService { public Food makeChicken { Food f = new Chicken f.setChicken; f.setSpicy; f.setSalt; return f; } public Food makeNoodle { Food f = new Noodle; f.setNoodle; f.setSalt; 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; return food; } public Food makeNoodle { System.out.println; Food food = foodService.makeNoodle; System.out.println return food; } }

客户端调用,注意,我们要用代理来实例化接口:

// 这里用代理类来实例化 FoodService foodService = new FoodServiceProxy; foodService.makeChicken;

上图应该还是很容易理解的,我就不做更多的解释了。下面,我们看看类适配模式怎么样的。

类适配器模式

废话少说,直接上图:

桥梁模式

理解桥梁模式,其实就是理解代码抽象和解耦。

我们首先需要一个桥梁,它是一个接口,定义提供的接口方法。

public interface DrawAPI { public void draw; }

然后是一系列实现类:

public class RedPen implements DrawAPI { @Override public void draw { System.out.println; } } public class GreenPen implements DrawAPI { @Override public void draw { System.out.println; } } public class BluePen implements DrawAPI { @Override public void draw { System.out.println; } }

定义一个抽象类,此类的实现类都需要使用 DrawAPI:

public abstract class Shape { protected DrawAPI drawAPI; protected Shape { this.drawAPI = drawAPI; } public abstract void draw; }

定义抽象类的子类:

// 圆形 public class Circle extends Shape { private int radius; public Circle { super; this.radius = radius; } public void draw { drawAPI.draw; } } // 长方形 public class Rectangle extends Shape { private int x; private int y; public Rectangle { super; this.x = x; this.y = y; } public void draw { drawAPI.draw; } }

最后,我们来看客户端演示:

public static void main { Shape greenCircle = new Circle); Shape redRectangle = new Rectangle); greenCircle.draw; redRectangle.draw; }

可能大家看上面一步步还不是特别清晰,我把所有的东西整合到一张图上:

我们来说说装饰模式的出发点,从图中可以看到,接口 Component 其实已经有了 ConcreteComponentAConcreteComponentB 两个实现类了,但是,如果我们要增强这两个实现类的话,我们就可以采用装饰模式,用具体的装饰器来装饰实现类,以达到增强的目的。

从名字来简单解释下装饰器。既然说是装饰,那么往往就是添加小功能这种,而且,我们要满足可以添加多个小功能。最简单的,代理模式就可以实现功能的增强,但是代理不容易实现多个功能的增强,当然你可以说用代理包装代理的多层包装方式,但是那样的话代码就复杂了。

首先明白一些简单的概念,从图中我们看到,所有的具体装饰者们 ConcreteDecorator* 都可以作为 Component 来使用,因为它们都实现了 Component 中的所有接口。它们和 Component 实现类 ConcreteComponent* 的区别是,它们只是装饰者,起装饰作用,也就是即使它们看上去牛逼轰轰,但是它们都只是在具体的实现中加了层皮来装饰而已。

注意这段话中混杂在各个名词中的 Component 和 Decorator,别搞混了。

下面来看看一个例子,先把装饰模式弄清楚,然后再介绍下 java io 中的装饰模式的应用。

最近大街上流行起来了“快乐柠檬”,我们把快乐柠檬的饮料分为三类:红茶、绿茶、咖啡,在这三大类的基础上,又增加了许多的口味,什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等,每家店都有很长的菜单,但是仔细看下,其实原料也没几样,但是可以搭配出很多组合,如果顾客需要,很多没出现在菜单中的饮料他们也是可以做的。

在这个例子中,红茶、绿茶、咖啡是最基础的饮料,其他的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。当然,在开发中,我们确实可以像门店一样,开发这些类:LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea……但是,很快我们就发现,这样子干肯定是不行的,这会导致我们需要组合出所有的可能,而且如果客人需要在红茶中加双份柠檬怎么办?三份柠檬怎么办?

不说废话了,上代码。

首先,定义饮料抽象基类:

public abstract class Beverage { // 返回描述 public abstract String getDescription; // 返回价格 public abstract double cost; }

然后是三个基础饮料实现类,红茶、绿茶和咖啡:

public class BlackTea extends Beverage { public String getDescription { return "红茶"; } public double cost { return 10; } } public class GreenTea extends Beverage { public String getDescription { return "绿茶"; } public double cost { return 11; } } ...// 咖啡省略

定义调料,也就是装饰者的基类,此类必须继承自 Beverage:

// 调料 public abstract class Condiment extends Beverage { }

然后我们来定义柠檬、芒果等具体的调料,它们属于装饰者,毫无疑问,这些调料肯定都需要继承调料 Condiment 类:

public class Lemon extends Condiment { private Beverage bevarage; // 这里很关键,需要传入具体的饮料,如需要传入没有被装饰的红茶或绿茶, // 当然也可以传入已经装饰好的芒果绿茶,这样可以做芒果柠檬绿茶 public Lemon { this.bevarage = bevarage; } public String getDescription { // 装饰 return bevarage.getDescription + ", 加柠檬"; } public double cost { // 装饰 return beverage.cost + 2; // 加柠檬需要 2 元 } } public class Mango extends Condiment { private Beverage bevarage; public Mango { this.bevarage = bevarage; } public String getDescription { return bevarage.getDescription + ", 加芒果"; } public double cost { return beverage.cost + 3; // 加芒果需要 3 元 } } ...// 给每一种调料都加一个类

看客户端调用:

public static void main { // 首先,我们需要一个基础饮料,红茶、绿茶或咖啡 Beverage beverage = new GreenTea; // 开始装饰 beverage = new Lemon; // 先加一份柠檬 beverage = new Mongo; // 再加一份芒果 System.out.println + " 价格:¥" + beverage.cost); //"绿茶, 加柠檬, 加芒果 价格:¥16" }

如果我们需要 芒果-珍珠-双份柠檬-红茶

Beverage beverage = new Mongo))));

是不是很变态?

看看下图可能会清晰一些:

我们知道 InputStream 代表了输入流,具体的输入来源可以是文件(FileInputStream)、管道(PipedInputStream)、数组(ByteArrayInputStream)等,这些就像前面奶茶的例子中的红茶、绿茶,属于基础输入流。

FilterInputStream 承接了装饰模式的关键节点,它的实现类是一系列装饰器,比如 BufferedInputStream 代表用缓冲来装饰,也就使得输入流具有了缓冲的功能,LineNumberInputStream 代表用行号来装饰,在操作的时候就可以取得行号了,DataInputStream 的装饰,使得我们可以从输入流转换为 java 中的基本类型值。

当然,在 java IO 中,如果我们使用装饰器的话,就不太适合面向接口编程了,如:

InputStream inputStream = new LineNumberInputStream));

这样的结果是,InputStream 还是不具有读取行号的功能,因为读取行号的方法定义在 LineNumberInputStream 类中。

我们应该像下面这样使用:

DataInputStream is = new DataInputStream));

所以说嘛,要找到纯的严格符合设计模式的代码还是比较难的。
门面模式

门面模式(也叫外观模式,Facade Pattern)在许多源码中有使用,比如 slf4j 就可以理解为是门面模式的应用。这是一个简单的设计模式,我们直接上代码再说吧。

首先,我们定义一个接口:

public interface Shape { void draw; }

定义几个实现类:

public class Circle implements Shape { @Override public void draw { System.out.println"); } } public class Rectangle implements Shape { @Override public void draw { System.out.println"); } }

客户端调用:

public static void main { // 画一个圆形 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 { ShapeMaker shapeMaker = new ShapeMaker; // 客户端调用现在更加清晰了 shapeMaker.drawCircle; shapeMaker.drawRectangle; shapeMaker.drawSquare; }

门面模式的优点显而易见,客户端不再需要关注实例化时应该使用哪个实现类,直接调用门面提供的方法就可以了,因为门面类提供的方法的方法名对于客户端来说已经很友好了。

组合模式

组合模式用于表示具有层次结构的数据,使得我们对单个对象和组合对象的访问具有一致性。

直接看一个例子吧,每个员工都有姓名、部门、薪水这些属性,同时还有下属员工集合(虽然可能集合为空),而下属员工和自己的结构是一样的,也有姓名、部门这些属性,同时也有他们的下属员工集合。

public class Employee { private String name; private String dept; private int salary; private List subordinates; // 下属 public Employee { this.name = name; this.dept = dept; this.salary = sal; subordinates = new ArrayList; } public void add { subordinates.add; } public void remove { subordinates.remove; } public List getSubordinates{ return subordinates; } public String toString{ return ; } }

通常,这种类需要定义 add、remove、getChildren 这些方法。

这说的其实就是组合模式,这种简单的模式我就不做过多介绍了,相信各位读者也不喜欢看我写废话。

享元模式

英文是 Flyweight Pattern,不知道是谁最先翻译的这个词,感觉这翻译真的不好理解,我们试着强行关联起来吧。Flyweight 是轻量级的意思,享元分开来说就是 共享 元器件,也就是复用已经生成的对象,这种做法当然也就是轻量级的了。

复用对象最简单的方式是,用一个 HashMap 来存放每次新生成的对象。每次需要一个对象的时候,先到 HashMap 中看看有没有,如果没有,再生成新的对象,然后将这个对象放入 HashMap 中。

这种简单的代码我就不演示了。

结构型模式总结

前面,我们说了代理模式、适配器模式、桥梁模式、装饰模式、门面模式、组合模式和享元模式。读者是否可以分别把这几个模式说清楚了呢?在说到这些模式的时候,心中是否有一个清晰的图或处理流程在脑海里呢?

代理模式是做方法增强的,适配器模式是把鸡包装成鸭这种用来适配接口的,桥梁模式做到了很好的解耦,装饰模式从名字上就看得出来,适合于装饰类或者说是增强类的场景,门面模式的优点是客户端不需要关心实例化过程,只要调用需要的方法即可,组合模式用于描述具有层次结构的数据,享元模式是为了在特定的场景中缓存已经创建的对象,用于提高性能。

行为型模式

行为型模式关注的是各个类之间的相互作用,将职责划分清楚,使得我们的代码更加地清晰。

策略模式

策略模式太常用了,所以把它放到最前面进行介绍。它比较简单,我就不废话,直接用代码说事吧。

下面设计的场景是,我们需要画一个图形,可选的策略就是用红色笔来画,还是绿色笔来画,或者蓝色笔来画。

首先,先定义一个策略接口:

public interface Strategy { public void draw; }

然后我们定义具体的几个策略:

public class RedPen implements Strategy { @Override public void draw { System.out.println; } } public class GreenPen implements Strategy { @Override public void draw { System.out.println; } } public class BluePen implements Strategy { @Override public void draw { System.out.println; } }

使用策略的类:

public class Context { private Strategy strategy; public Context{ this.strategy = strategy; } public int executeDraw{ return strategy.draw; } }

客户端演示:

public static void main { Context context = new Context); // 使用绿色笔来画 context.executeDraw; }

放到一张图上,让大家看得清晰些:

要我说的话,它们非常相似,桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低,结构更复杂一些。

观察者模式

观察者模式对于我们来说,真是再简单不过了。无外乎两个操作,观察者订阅自己关心的主题和主题有数据变化后通知观察者们。

首先,需要定义主题,每个主题需要持有观察者列表的引用,用于在数据变更的时候通知各个观察者:

public class Subject { private List observers = new ArrayList; private int state; public int getState { return state; } public void setState { this.state = state; // 数据已变更,通知观察者们 notifyAllObservers; } // 注册观察者 public void attach { observers.add; } // 通知观察者们 public void notifyAllObservers { for { observer.update; } } }

定义观察者接口:

public abstract class Observer { protected Subject subject; public abstract void update; }

其实如果只有一个观察者类的话,接口都不用定义了,不过,通常场景下,既然用到了观察者模式,我们就是希望一个事件出来了,会有多个不同的类需要处理相应的信息。比如,订单修改成功事件,我们希望发短信的类得到通知、发邮件的类得到通知、处理物流信息的类得到通知等。

我们来定义具体的几个观察者类:

public class BinaryObserver extends Observer { // 在构造方法中进行订阅主题 public BinaryObserver { this.subject = subject; // 通常在构造方法中将 this 发布出去的操作一定要小心 this.subject.attach; } // 该方法由主题类在数据变更的时候进行调用 @Override public void update { String result = Integer.toBinaryString); System.out.println; } } public class HexaObserver extends Observer { public HexaObserver { this.subject = subject; this.subject.attach; } @Override public void update { String result = Integer.toHexString).toUpperCase; System.out.println; } }

客户端使用也非常简单:

public static void main { // 先定义一个主题 Subject subject1 = new Subject; // 定义观察者 new BinaryObserver; new HexaObserver; // 模拟数据变更,这个时候,观察者们的 update 方法将会被调用 subject.setState; }

output:

订阅的数据发生变化,新的数据处理为二进制值为:1011 订阅的数据发生变化,新的数据处理为十六进制值为:B

当然,jdk 也提供了相似的支持,具体的大家可以参考 java.util.Observablejava.util.Observer 这两个类。

实际生产过程中,观察者模式往往用消息中间件来实现,如果要实现单机观察者模式,笔者建议读者使用 Guava 中的 EventBus,它有同步实现也有异步实现,本文主要介绍设计模式,就不展开说了。

还有,即使是上面的这个代码,也会有很多变种,大家只要记住核心的部分,那就是一定有一个地方存放了所有的观察者,然后在事件发生的时候,遍历观察者,调用它们的回调函数。

责任链模式

责任链通常需要先建立一个单向链表,然后调用方只需要调用头部节点就可以了,后面会自动流转下去。比如流程审批就是一个很好的例子,只要终端用户提交申请,根据申请的内容信息,自动建立一条责任链,然后就可以开始流转了。

有这么一个场景,用户参加一个活动可以领取奖品,但是活动需要进行很多的规则校验然后才能放行,比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后,才能让用户领走奖品。

如果产品给你这个需求的话,我想大部分人一开始肯定想的就是,用一个 List 来存放所有的规则,然后 foreach 执行一下每个规则就好了。不过,读者也先别急,看看责任链模式和我们说的这个有什么不一样?

首先,我们要定义流程上节点的基类:

public abstract class RuleHandler { // 后继节点 protected RuleHandler successor; public abstract void apply; public void setSuccessor { this.successor = successor; } public RuleHandler getSuccessor { return successor; } }

接下来,我们需要定义具体的每个节点了。

校验用户是否是新用户:

public class NewUserRuleHandler extends RuleHandler { public void apply { if ) { // 如果有后继节点的话,传递下去 if != null) { this.getSuccessor.apply; } } else { throw new RuntimeException; } } }

校验用户所在地区是否可以参与:

public class LocationRuleHandler extends RuleHandler { public void apply { boolean allowed = activityService.isSupportedLocation; if { if != null) { this.getSuccessor.apply; } } else { throw new RuntimeException; } } }

校验奖品是否已领完:

public class LimitRuleHandler extends RuleHandler { public void apply { int remainedTimes = activityService.queryRemainedTimes; // 查询剩余奖品 if { if != null) { this.getSuccessor.apply; } } else { throw new RuntimeException; } } }

客户端:

public static void main { RuleHandler newUserHandler = new NewUserRuleHandler; RuleHandler locationHandler = new LocationRuleHandler; RuleHandler limitHandler = new LimitRuleHandler; // 假设本次活动仅校验地区和奖品数量,不校验新老用户 locationHandler.setSuccessor; locationHandler.apply; }

代码其实很简单,就是先定义好一个链表,然后在通过任意一节点后,如果此节点有后继节点,那么传递下去。

至于它和我们前面说的用一个 List 存放需要执行的规则的做法有什么异同,留给读者自己琢磨吧。

模板方法模式

在含有继承结构的代码中,模板方法模式是非常常用的。

通常会有一个抽象类:

public abstract class AbstractTemplate { // 这就是模板方法 public void templateMethod { init; apply; // 这个是重点 end; // 可以作为钩子方法 } protected void init { System.out.println; } // 留给子类实现 protected abstract void apply; protected void end { } }

模板方法中调用了 3 个方法,其中 apply 是抽象方法,子类必须实现它,其实模板方法中有几个抽象方法完全是自由的,我们也可以将三个方法都设置为抽象方法,让子类来实现。也就是说,模板方法只负责定义第一步应该要做什么,第二步应该做什么,第三步应该做什么,至于怎么做,由子类来实现。

我们写一个实现类:

public class ConcreteTemplate extends AbstractTemplate { public void apply { System.out.println; } public void end { System.out.println; } }

客户端调用演示:

public static void main { AbstractTemplate t = new ConcreteTemplate; // 调用模板方法 t.templateMethod; }

代码其实很简单,基本上看到就懂了,关键是要学会用到自己的代码中。

状态模式

废话我就不说了,我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存,我们看看怎么用状态模式来写。

核心在于,我们的关注点不再是 Context 是该进行哪种操作,而是关注在这个 Context 会有哪些操作。

定义状态接口:

public interface State { public void doAction; }

定义减库存的状态:

public class DeductState implements State { public void doAction { System.out.println; context.setState; //... 执行减库存的具体操作 } public String toString { return "Deduct State"; } }

定义补库存状态:

public class RevertState implements State { public void doAction { System.out.println; context.setState; //... 执行加库存的具体操作 } public String toString { return "Revert State"; } }

前面用到了 context.setState,我们来看看怎么定义 Context 类:

public class Context { private State state; private String name; public Context { this.name = name; } public void setState { this.state = state; } public void getState { return this.state; } }

我们来看下客户端调用,大家就一清二楚了:

public static void main { // 我们需要操作的是 iPhone X Context context = new Context; // 看看怎么进行补库存操作 State revertState = new RevertState; revertState.doAction; // 同样的,减库存操作也非常简单 State deductState = new DeductState; deductState.doAction; // 如果需要我们可以获取当前的状态 // context.getState.toString; }

读者可能会发现,在上面这个例子中,如果我们不关心当前 context 处于什么状态,那么 Context 就可以不用维护 state 属性了,那样代码会简单很多。

不过,商品库存这个例子毕竟只是个例,我们还有很多实例是需要知道当前 context 处于什么状态的。

行为型模式总结

行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式,其实,经典的行为型模式还包括备忘录模式、命令模式等,但是它们的使用场景比较有限,而且本文篇幅也挺大了,我就不进行介绍了。

总结

学习设计模式的目的是为了让我们的代码更加的优雅、易维护、易扩展。这次整理这篇文章,让我重新审视了一下各个设计模式,对我自己而言收获还是挺大的。

我想,文章的最大收益者一般都是作者本人,为了写一篇文章,需要巩固自己的知识,需要寻找各种资料,而且,自己写过的才最容易记住,也算是我给读者的建议吧。

来源:http://javadoop.com/post/design-pattern
 
友情链接
鄂ICP备19019357号-22