关注我们有助于升职加薪噢&＃xff01;
点击上方关注 “程序IT圈”
设为“星标”&＃xff0c;和你一起掌握更多知识
设计模式是对大家实际工作中写的各种代码进行高层次抽象的总结&＃xff0c;其中最出名的当属 Gang of Four (GoF) 的分类了&＃xff0c;他们将设计模式分类为 23 种经典的模式&＃xff0c;根据用途我们又可以分为三大类&＃xff0c;分别为创建型模式、结构型模式和行为型模式。
有一些重要的设计原则在开篇和大家分享下&＃xff0c;这些原则将贯通全文&＃xff1a;
面向接口编程&＃xff0c;而不是面向实现。这个很重要&＃xff0c;也是优雅的、可扩展的代码的第一步&＃xff0c;这就不需要多说了吧。
职责单一原则。每个类都应该只有一个单一的功能&＃xff0c;并且该功能应该由这个类完全封装起来。
对修改关闭&＃xff0c;对扩展开放。对修改关闭是说&＃xff0c;我们辛辛苦苦加班写出来的代码&＃xff0c;该实现的功能和该修复的 bug 都完成了&＃xff0c;别人可不能说改就改&＃xff1b;对扩展开放就比较好理解了&＃xff0c;也就是说在我们写好的代码基础上&＃xff0c;很容易实现扩展。
创建型模式比较简单&＃xff0c;但是会比较没有意思&＃xff0c;结构型和行为型比较有意思。
创建型模式的作用就是创建对象&＃xff0c;说到创建一个对象&＃xff0c;最熟悉的就是 new 一个对象&＃xff0c;然后 set 相关属性。但是&＃xff0c;在很多场景下&＃xff0c;我们需要给客户端提供更加友好的创建对象的方式&＃xff0c;尤其是那种我们定义了类&＃xff0c;但是需要提供给其他开发者用的时候。
和名字一样简单&＃xff0c;非常简单&＃xff0c;直接上代码吧&＃xff1a;
public class FoodFactory {public static Food makeFood(String name) {if (name.equals("noodle")) {Food noodle &＃61; new LanZhouNoodle();noodle.addSpicy("more");return noodle;} else if (name.equals("chicken")) {Food chicken &＃61; new HuangMenChicken();chicken.addCondiment("potato");return chicken;} else {return null;}}
}
其中&＃xff0c;LanZhouNoodle 和 HuangMenChicken 都继承自 Food。
简单地说&＃xff0c;简单工厂模式通常就是这样&＃xff0c;一个工厂类 XxxFactory&＃xff0c;里面有一个静态方法&＃xff0c;根据我们不同的参数&＃xff0c;返回不同的派生自同一个父类&＃xff08;或实现同一接口&＃xff09;的实例对象。
我们强调职责单一原则&＃xff0c;一个类只提供一种功能&＃xff0c;FoodFactory 的功能就是只要负责生产各种 Food。
简单工厂模式很简单&＃xff0c;如果它能满足我们的需要&＃xff0c;我觉得就不要折腾了。之所以需要引入工厂模式&＃xff0c;是因为我们往往需要使用两个或两个以上的工厂。
public interface FoodFactory {Food makeFood(String name);
}
public class ChineseFoodFactory implements FoodFactory {&＃64;Overridepublic 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 {&＃64;Overridepublic Food makeFood(String name) {if (name.equals("A")) {return new AmericanFoodA();} else if (name.equals("B")) {return new AmericanFoodB();} else {return null;}}
}
其中&＃xff0c;ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB 都派生自 Food。
客户端调用&＃xff1a;
public class APP {public static void main(String[] args) {// 先选择一个具体的工厂FoodFactory factory &＃61; new ChineseFoodFactory();// 由第一步的工厂产生具体的对象&＃xff0c;不同的工厂造出不一样的对象Food food &＃61; factory.makeFood("A");}
}
虽然都是调用 makeFood("A") 制作 A 类食物&＃xff0c;但是&＃xff0c;不同的工厂生产出来的完全不一样。
第一步&＃xff0c;我们需要选取合适的工厂&＃xff0c;然后第二步基本上和简单工厂一样。
核心在于&＃xff0c;我们需要在第一步选好我们需要的工厂。比如&＃xff0c;我们有 LogFactory 接口&＃xff0c;实现类有 FileLogFactory 和 KafkaLogFactory&＃xff0c;分别对应将日志写入文件和写入 Kafka 中&＃xff0c;显然&＃xff0c;我们客户端第一步就需要决定到底要实例化 FileLogFactory 还是 KafkaLogFactory&＃xff0c;这将决定之后的所有的操作。
虽然简单&＃xff0c;不过我也把所有的构件都画到一张图上&＃xff0c;这样读者看着比较清晰&＃xff1a;
当涉及到产品族的时候&＃xff0c;就需要引入抽象工厂模式了。
一个经典的例子是造一台电脑。我们先不引入抽象工厂模式&＃xff0c;看看怎么实现。
因为电脑是由许多的构件组成的&＃xff0c;我们将 CPU 和主板进行抽象&＃xff0c;然后 CPU 由 CPUFactory 生产&＃xff0c;主板由 MainBoardFactory 生产&＃xff0c;然后&＃xff0c;我们再将 CPU 和主板搭配起来组合在一起&＃xff0c;如下图&＃xff1a;
这个时候的客户端调用是这样的&＃xff1a;
// 得到 Intel 的 CPU
CPUFactory cpuFactory &＃61; new IntelCPUFactory();
CPU cpu &＃61; intelCPUFactory.makeCPU();// 得到 AMD 的主板
MainBoardFactory mainBoardFactory &＃61; new AmdMainBoardFactory();
MainBoard mainBoard &＃61; mainBoardFactory.make();// 组装 CPU 和主板
Computer computer &＃61; new Computer(cpu, mainBoard);
单独看 CPU 工厂和主板工厂&＃xff0c;它们分别是前面我们说的工厂模式。这种方式也容易扩展&＃xff0c;因为要给电脑加硬盘的话&＃xff0c;只需要加一个 HardDiskFactory 和相应的实现即可&＃xff0c;不需要修改现有的工厂。
但是&＃xff0c;这种方式有一个问题&＃xff0c;那就是如果 Intel 家产的 CPU 和 AMD 产的主板不能兼容使用&＃xff0c;那么这代码就容易出错&＃xff0c;因为客户端并不知道它们不兼容&＃xff0c;也就会错误地出现随意组合。
下面就是我们要说的产品族的概念&＃xff0c;它代表了组成某个产品的一系列附件的集合&＃xff1a;
当涉及到这种产品族的问题的时候&＃xff0c;就需要抽象工厂模式来支持了。我们不再定义 CPU 工厂、主板工厂、硬盘工厂、显示屏工厂等等&＃xff0c;我们直接定义电脑工厂&＃xff0c;每个电脑工厂负责生产所有的设备&＃xff0c;这样能保证肯定不存在兼容问题。
这个时候&＃xff0c;对于客户端来说&＃xff0c;不再需要单独挑选 CPU厂商、主板厂商、硬盘厂商等&＃xff0c;直接选择一家品牌工厂&＃xff0c;品牌工厂会负责生产所有的东西&＃xff0c;而且能保证肯定是兼容可用的。
public static void main(String[] args) {// 第一步就要选定一个“大厂”ComputerFactory cf &＃61; new AmdFactory();// 从这个大厂造 CPUCPU cpu &＃61; cf.makeCPU();// 从这个大厂造主板MainBoard board &＃61; cf.makeMainBoard();// 从这个大厂造硬盘HardDisk hardDisk &＃61; cf.makeHardDisk();// 将同一个厂子出来的 CPU、主板、硬盘组装在一起Computer result &＃61; new Computer(cpu, board, hardDisk);
}
当然&＃xff0c;抽象工厂的问题也是显而易见的&＃xff0c;比如我们要加个显示器&＃xff0c;就需要修改所有的工厂&＃xff0c;给所有的工厂都加上制造显示器的方法。这有点违反了对修改关闭&＃xff0c;对扩展开放这个设计原则。
单例模式用得最多&＃xff0c;错得最多。
饿汉模式最简单&＃xff1a;
public class Singleton {// 首先&＃xff0c;将 new Singleton() 堵死private Singleton() {};// 创建私有静态实例&＃xff0c;意味着这个类第一次使用的时候就会进行创建private static Singleton instance &＃61; new Singleton();public static Singleton getInstance() {return instance;}// 瞎写一个静态方法。这里想说的是&＃xff0c;如果我们只是要调用 Singleton.getDate(...)&＃xff0c;// 本来是不想要生成 Singleton 实例的&＃xff0c;不过没办法&＃xff0c;已经生成了public static Date getDate(String mode) {return new Date();}
}
很多人都能说出饿汉模式的缺点&＃xff0c;可是我觉得生产过程中&＃xff0c;很少碰到这种情况&＃xff1a;你定义了一个单例的类&＃xff0c;不需要其实例&＃xff0c;可是你却把一个或几个你会用到的静态方法塞到这个类中。
饱汉模式最容易出错&＃xff1a;
public class Singleton {// 首先&＃xff0c;也是先堵死 new Singleton() 这条路private Singleton() {}// 和饿汉模式相比&＃xff0c;这边不需要先实例化出来&＃xff0c;注意这里的 volatile&＃xff0c;它是必须的private static volatile Singleton instance &＃61; null;public static Singleton getInstance() {if (instance &＃61;&＃61; null) {// 加锁synchronized (Singleton.class) {// 这一次判断也是必须的&＃xff0c;不然会有并发问题if (instance &＃61;&＃61; null) {instance &＃61; new Singleton();}}}return instance;}
}
双重检查&＃xff0c;指的是两次检查 instance 是否为 null。
volatile 在这里是需要的&＃xff0c;希望能引起读者的关注。
很多人不知道怎么写&＃xff0c;直接就在 getInstance() 方法签名上加上 synchronized&＃xff0c;这就不多说了&＃xff0c;性能太差。
嵌套类最经典&＃xff0c;以后大家就用它吧&＃xff1a;
public class Singleton3 {private Singleton3() {}// 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法 的特性private static class Holder {private static Singleton3 instance &＃61; new Singleton3();}public static Singleton3 getInstance() {return Holder.instance;}
}
注意&＃xff0c;很多人都会把这个嵌套类说成是静态内部类&＃xff0c;严格地说&＃xff0c;内部类和嵌套类是不一样的&＃xff0c;它们能访问的外部类权限也是不一样的。
最后&＃xff0c;我们说一下枚举&＃xff0c;枚举很特殊&＃xff0c;它在类加载的时候会初始化里面的所有的实例&＃xff0c;而且 JVM 保证了它们不会再被实例化&＃xff0c;所以它天生就是单例的。
虽然我们平时很少看到用枚举来实现单例&＃xff0c;但是在 RxJava 的源码中&＃xff0c;有很多地方都用了枚举来实现单例。
经常碰见的 XxxBuilder 的类&＃xff0c;通常都是建造者模式的产物。建造者模式其实有很多的变种&＃xff0c;但是对于客户端来说&＃xff0c;我们的使用通常都是一个模式的&＃xff1a;
Food food &＃61; new FoodBuilder().a().b().c().build();
Food food &＃61; Food.builder().a().b().c().build();
套路就是先 new 一个 Builder&＃xff0c;然后可以链式地调用一堆方法&＃xff0c;最后再调用一次 build() 方法&＃xff0c;我们需要的对象就有了。
来一个中规中矩的建造者模式&＃xff1a;
class User {// 下面是“一堆”的属性private String name;private String password;private String nickName;private int age;// 构造方法私有化&＃xff0c;不然客户端就会直接调用构造方法了private User(String name, String password, String nickName, int age) {this.name &＃61; name;this.password &＃61; password;this.nickName &＃61; nickName;this.age &＃61; age;}// 静态方法&＃xff0c;用于生成一个 Builder&＃xff0c;这个不一定要有&＃xff0c;不过写这个方法是一个很好的习惯&＃xff0c;// 有些代码要求别人写 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() {}// 链式调用设置各个属性值&＃xff0c;返回 this&＃xff0c;即 UserBuilderpublic UserBuilder name(String name) {this.name &＃61; name;return this;}public UserBuilder password(String password) {this.password &＃61; password;return this;}public UserBuilder nickName(String nickName) {this.nickName &＃61; nickName;return this;}public UserBuilder age(int age) {this.age &＃61; age;return this;}// build() 方法负责将 UserBuilder 中设置好的属性“复制”到 User 中。// 当然&＃xff0c;可以在 “复制” 之前做点检验public User build() {if (name &＃61;&＃61; null || password &＃61;&＃61; null) {throw new RuntimeException("用户名和密码必填");}if (age <&＃61; 0 || age >&＃61; 150) {throw new RuntimeException("年龄不合法");}// 还可以做赋予”默认值“的功能if (nickName &＃61;&＃61; null) {nickName &＃61; name;}return new User(name, password, nickName, age);}}
}
核心是&＃xff1a;先把所有的属性都设置给 Builder&＃xff0c;然后 build() 方法的时候&＃xff0c;将这些属性复制给实际产生的对象。
看看客户端的调用&＃xff1a;
public class APP {public static void main(String[] args) {User d &＃61; User.builder().name("foo").password("pAss12345").age(25).build();}
}
说实话&＃xff0c;建造者模式的链式写法很吸引人&＃xff0c;但是&＃xff0c;多写了很多“无用”的 builder 的代码&＃xff0c;感觉这个模式没什么用。不过&＃xff0c;当属性很多&＃xff0c;而且有些必填&＃xff0c;有些选填的时候&＃xff0c;这个模式会使代码清晰很多。我们可以在 Builder 的构造方法中强制让调用者提供必填字段&＃xff0c;还有&＃xff0c;在 build() 方法中校验各个参数比在 User 的构造方法中校验&＃xff0c;代码要优雅一些。
题外话&＃xff0c;强烈建议读者使用 lombok&＃xff0c;用了 lombok 以后&＃xff0c;上面的一大堆代码会变成如下这样:
&＃64;Builder
class User {private String name;private String password;private String nickName;private int age;
}
怎么样&＃xff0c;省下来的时间是不是又可以干点别的了。
当然&＃xff0c;如果你只是想要链式写法&＃xff0c;不想要建造者模式&＃xff0c;有个很简单的办法&＃xff0c;User 的 getter 方法不变&＃xff0c;所有的 setter 方法都让其 return this 就可以了&＃xff0c;然后就可以像下面这样调用&＃xff1a;
User user &＃61; new User().setName("").setPassword("").setAge(20);
很多人是这么用的&＃xff0c;但是笔者觉得其实这种写法非常地不优雅&＃xff0c;不是很推荐使用。
这是我要说的创建型模式的最后一个设计模式了。
原型模式很简单&＃xff1a;有一个原型实例&＃xff0c;基于这个原型实例产生新的实例&＃xff0c;也就是“克隆”了。
Object 类中有一个 clone() 方法&＃xff0c;它用于生成一个新的对象&＃xff0c;当然&＃xff0c;如果我们要调用这个方法&＃xff0c;java 要求我们的类必须先实现 Cloneable 接口&＃xff0c;此接口没有定义任何方法&＃xff0c;但是不这么做的话&＃xff0c;在 clone() 的时候&＃xff0c;会抛出 CloneNotSupportedException 异常。
protected native Object clone() throws CloneNotSupportedException;
java 的克隆是浅克隆&＃xff0c;碰到对象引用的时候&＃xff0c;克隆出来的对象和原对象中的引用将指向同一个对象。通常实现深克隆的方法是将对象进行序列化&＃xff0c;然后再进行反序列化。
原型模式了解到这里我觉得就够了&＃xff0c;各种变着法子说这种代码或那种代码是原型模式&＃xff0c;没什么意义。
创建型模式总体上比较简单&＃xff0c;它们的作用就是为了产生实例对象&＃xff0c;算是各种工作的第一步了&＃xff0c;因为我们写的是面向对象的代码&＃xff0c;所以我们第一步当然是需要创建一个对象了。
简单工厂模式最简单&＃xff1b;工厂模式在简单工厂模式的基础上增加了选择工厂的维度&＃xff0c;需要第一步选择合适的工厂&＃xff1b;抽象工厂模式有产品族的概念&＃xff0c;如果各个产品是存在兼容性问题的&＃xff0c;就要用抽象工厂模式。单例模式就不说了&＃xff0c;为了保证全局使用的是同一对象&＃xff0c;一方面是安全性考虑&＃xff0c;一方面是为了节省资源&＃xff1b;建造者模式专门对付属性很多的那种类&＃xff0c;为了让代码更优美&＃xff1b;原型模式用得最少&＃xff0c;了解和 Object 类中的 clone() 方法相关的知识即可。
前面创建型模式介绍了创建对象的一些设计模式&＃xff0c;这节介绍的结构型模式旨在通过改变代码结构来达到解耦的目的&＃xff0c;使得我们的代码容易维护和扩展。
第一个要介绍的代理模式是最常使用的模式之一了&＃xff0c;用一个代理来隐藏具体实现类的实现细节&＃xff0c;通常还用于在真实的实现的前后添加一部分逻辑。
既然说是代理&＃xff0c;那就要对客户端隐藏真实实现&＃xff0c;由代理来负责客户端的所有请求。当然&＃xff0c;代理只是个代理&＃xff0c;它不会完成实际的业务逻辑&＃xff0c;而是一层皮而已&＃xff0c;但是对于客户端来说&＃xff0c;它必须表现得就是客户端需要的真实实现。
理解代理这个词&＃xff0c;这个模式其实就简单了。
public interface FoodService {Food makeChicken();Food makeNoodle();
}public class FoodServiceImpl implements FoodService {public Food makeChicken() {Food f &＃61; new Chicken()f.setChicken("1kg");f.setSpicy("1g");f.setSalt("3g");return f;}public Food makeNoodle() {Food f &＃61; new Noodle();f.setNoodle("500g");f.setSalt("5g");return f;}
}// 代理要表现得“就像是”真实实现类&＃xff0c;所以需要实现 FoodService
public class FoodServiceProxy implements FoodService {// 内部一定要有一个真实的实现类&＃xff0c;当然也可以通过构造方法注入private FoodService foodService &＃61; new FoodServiceImpl();public Food makeChicken() {System.out.println("我们马上要开始制作鸡肉了");// 如果我们定义这句为核心代码的话&＃xff0c;那么&＃xff0c;核心代码是真实实现类做的&＃xff0c;// 代理只是在核心代码前后做些“无足轻重”的事情Food food &＃61; foodService.makeChicken();System.out.println("鸡肉制作完成啦&＃xff0c;加点胡椒粉"); // 增强food.addCondiment("pepper");return food;}public Food makeNoodle() {System.out.println("准备制作拉面~");Food food &＃61; foodService.makeNoodle();System.out.println("制作完成啦")return food;}
}
客户端调用&＃xff0c;注意&＃xff0c;我们要用代理来实例化接口&＃xff1a;
// 这里用代理类来实例化
FoodService foodService &＃61; new FoodServiceProxy();
foodService.makeChicken();
我们发现没有&＃xff0c;代理模式说白了就是做 “方法包装” 或做 “方法增强”。在面向切面编程中&＃xff0c;其实就是动态代理的过程。比如 Spring 中&＃xff0c;我们自己不定义代理类&＃xff0c;但是 Spring 会帮我们动态来定义代理&＃xff0c;然后把我们定义在 &＃64;Before、&＃64;After、&＃64;Around 中的代码逻辑动态添加到代理中。
说到动态代理&＃xff0c;又可以展开说&＃xff0c;Spring 中实现动态代理有两种&＃xff0c;一种是如果我们的类定义了接口&＃xff0c;如 UserService 接口和 UserServiceImpl 实现&＃xff0c;那么采用 JDK 的动态代理&＃xff0c;感兴趣的读者可以去看看 java.lang.reflect.Proxy 类的源码&＃xff1b;另一种是我们自己没有定义接口的&＃xff0c;Spring 会采用 CGLIB 进行动态代理&＃xff0c;它是一个 jar 包&＃xff0c;性能还不错。
说完代理模式&＃xff0c;说适配器模式&＃xff0c;是因为它们很相似&＃xff0c;这里可以做个比较。
适配器模式做的就是&＃xff0c;有一个接口需要实现&＃xff0c;但是我们现成的对象都不满足&＃xff0c;需要加一层适配器来进行适配。
适配器模式总体来说分三种&＃xff1a;默认适配器模式、对象适配器模式、类适配器模式。先不急着分清楚这几个&＃xff0c;先看看例子再说。
首先&＃xff0c;我们先看看最简单的适配器模式**默认适配器模式(Default Adapter)**是怎么样的。
我们用 Appache commons-io 包中的 FileAlterationListener 做例子&＃xff0c;此接口定义了很多的方法&＃xff0c;用于对文件或文件夹进行监控&＃xff0c;一旦发生了对应的操作&＃xff0c;就会触发相应的方法。
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);
}
此接口的一大问题是抽象方法太多了&＃xff0c;如果我们要用这个接口&＃xff0c;意味着我们要实现每一个抽象方法&＃xff0c;如果我们只是想要监控文件夹中的文件创建和文件删除事件&＃xff0c;可是我们还是不得不实现所有的方法&＃xff0c;很明显&＃xff0c;这不是我们想要的。
关注公众号&＃xff1a;Java后端编程&＃xff0c;后台回复&＃xff1a;Java&＃xff0c;获取学习视频。
所以&＃xff0c;我们需要下面的一个适配器&＃xff0c;它用于实现上面的接口&＃xff0c;但是所有的方法都是空方法&＃xff0c;这样&＃xff0c;我们就可以转而定义自己的类来继承下面这个类即可。
public class FileAlterationListenerAdaptor implements FileAlterationListener {public void onStart(final FileAlterationObserver observer) {}public void onDirectoryCreate(final File directory) {}public void onDirectoryChange(final File directory) {}public void onDirectoryDelete(final File directory) {}public void onFileCreate(final File file) {}public void onFileChange(final File file) {}public void onFileDelete(final File file) {}public void onStop(final FileAlterationObserver observer) {}
}
比如我们可以定义以下类&＃xff0c;我们仅仅需要实现我们想实现的方法就可以了&＃xff1a;
public class FileMonitor extends FileAlterationListenerAdaptor {public void onFileCreate(final File file) {// 文件创建doSomething();}public void onFileDelete(final File file) {// 文件删除doSomething();}
}
当然&＃xff0c;上面说的只是适配器模式的其中一种&＃xff0c;也是最简单的一种&＃xff0c;无需多言。下面&＃xff0c;再介绍**“正统的”**适配器模式。
来看一个《Head First 设计模式》中的一个例子&＃xff0c;我稍微修改了一下&＃xff0c;看看怎么将鸡适配成鸭&＃xff0c;这样鸡也能当鸭来用。因为&＃xff0c;现在鸭这个接口&＃xff0c;我们没有合适的实现类可以用&＃xff0c;所以需要适配器。
public interface Duck {public void quack(); // 鸭的呱呱叫public void fly(); // 飞
}public interface Cock {public void gobble(); // 鸡的咕咕叫public void fly(); // 飞
}public class WildCock implements Cock {public void gobble() {System.out.println("咕咕叫");}public void fly() {System.out.println("鸡也会飞哦");}
}
鸭接口有 fly() 和 quare() 两个方法&＃xff0c;鸡 Cock 如果要冒充鸭&＃xff0c;fly() 方法是现成的&＃xff0c;但是鸡不会鸭的呱呱叫&＃xff0c;没有 quack() 方法。这个时候就需要适配了&＃xff1a;
// 毫无疑问&＃xff0c;首先&＃xff0c;这个适配器肯定需要 implements Duck&＃xff0c;这样才能当做鸭来用
public class CockAdapter implements Duck {Cock cock;// 构造方法中需要一个鸡的实例&＃xff0c;此类就是将这只鸡适配成鸭来用public CockAdapter(Cock cock) {this.cock &＃61; cock;}// 实现鸭的呱呱叫方法&＃64;Overridepublic void quack() {// 内部其实是一只鸡的咕咕叫cock.gobble();}&＃64;Overridepublic void fly() {cock.fly();}
}
客户端调用很简单了&＃xff1a;
public static void main(String[] args) {// 有一只野鸡Cock wildCock &＃61; new WildCock();// 成功将野鸡适配成鸭Duck duck &＃61; new CockAdapter(wildCock);...
}
到这里&＃xff0c;大家也就知道了适配器模式是怎么回事了。无非是我们需要一只鸭&＃xff0c;但是我们只有一只鸡&＃xff0c;这个时候就需要定义一个适配器&＃xff0c;由这个适配器来充当鸭&＃xff0c;但是适配器里面的方法还是由鸡来实现的。
我们用一个图来简单说明下&＃xff1a;
上图应该还是很容易理解的&＃xff0c;我就不做更多的解释了。下面&＃xff0c;我们看看类适配模式怎么样的。
废话少说&＃xff0c;直接上图&＃xff1a;
看到这个图&＃xff0c;大家应该很容易理解的吧&＃xff0c;通过继承的方法&＃xff0c;适配器自动获得了所需要的大部分方法。这个时候&＃xff0c;客户端使用更加简单&＃xff0c;直接 Target t &＃61; new SomeAdapter(); 就可以了。
类适配和对象适配的异同
一个采用继承&＃xff0c;一个采用组合&＃xff1b;
类适配属于静态实现&＃xff0c;对象适配属于组合的动态实现&＃xff0c;对象适配需要多实例化一个对象。
总体来说&＃xff0c;对象适配用得比较多。
适配器模式和代理模式的异同
比较这两种模式&＃xff0c;其实是比较对象适配器模式和代理模式&＃xff0c;在代码结构上&＃xff0c;它们很相似&＃xff0c;都需要一个具体的实现类的实例。但是它们的目的不一样&＃xff0c;代理模式做的是增强原方法的活&＃xff1b;适配器做的是适配的活&＃xff0c;为的是提供“把鸡包装成鸭&＃xff0c;然后当做鸭来使用”&＃xff0c;而鸡和鸭它们之间原本没有继承关系。
理解桥梁模式&＃xff0c;其实就是理解代码抽象和解耦。
我们首先需要一个桥梁&＃xff0c;它是一个接口&＃xff0c;定义提供的接口方法。
public interface DrawAPI {public void draw(int radius, int x, int y);
}
然后是一系列实现类&＃xff1a;
public class RedPen implements DrawAPI {&＃64;Overridepublic void draw(int radius, int x, int y) {System.out.println("用红色笔画图&＃xff0c;radius:" &＃43; radius &＃43; ", x:" &＃43; x &＃43; ", y:" &＃43; y);}
}
public class GreenPen implements DrawAPI {&＃64;Overridepublic void draw(int radius, int x, int y) {System.out.println("用绿色笔画图&＃xff0c;radius:" &＃43; radius &＃43; ", x:" &＃43; x &＃43; ", y:" &＃43; y);}
}
public class BluePen implements DrawAPI {&＃64;Overridepublic void draw(int radius, int x, int y) {System.out.println("用蓝色笔画图&＃xff0c;radius:" &＃43; radius &＃43; ", x:" &＃43; x &＃43; ", y:" &＃43; y);}
}
定义一个抽象类&＃xff0c;此类的实现类都需要使用 DrawAPI&＃xff1a;
public abstract class Shape {protected DrawAPI drawAPI;protected Shape(DrawAPI drawAPI) {this.drawAPI &＃61; drawAPI;}public abstract void draw();
}
定义抽象类的子类&＃xff1a;
// 圆形
public class Circle extends Shape {private int radius;public Circle(int radius, DrawAPI drawAPI) {super(drawAPI);this.radius &＃61; 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 &＃61; x;this.y &＃61; y;}public void draw() {drawAPI.draw(0, x, y);}
}
最后&＃xff0c;我们来看客户端演示&＃xff1a;
public static void main(String[] args) {Shape greenCircle &＃61; new Circle(10, new GreenPen());Shape redRectangle &＃61; new Rectangle(4, 8, new RedPen());greenCircle.draw();redRectangle.draw();
}
可能大家看上面一步步还不是特别清晰&＃xff0c;我把所有的东西整合到一张图上&＃xff1a;
这回大家应该就知道抽象在哪里&＃xff0c;怎么解耦了吧。桥梁模式的优点也是显而易见的&＃xff0c;就是非常容易进行扩展。
本节引用了这里的例子&＃xff0c;并对其进行了修改。
要把装饰模式说清楚明白&＃xff0c;不是件容易的事情。也许读者知道 Java IO 中的几个类是典型的装饰模式的应用&＃xff0c;但是读者不一定清楚其中的关系&＃xff0c;也许看完就忘了&＃xff0c;希望看完这节后&＃xff0c;读者可以对其有更深的感悟。
首先&＃xff0c;我们先看一个简单的图&＃xff0c;看这个图的时候&＃xff0c;了解下层次结构就可以了&＃xff1a;
我们来说说装饰模式的出发点&＃xff0c;从图中可以看到&＃xff0c;接口 Component 其实已经有了 ConcreteComponentA 和 ConcreteComponentB 两个实现类了&＃xff0c;但是&＃xff0c;如果我们要增强这两个实现类的话&＃xff0c;我们就可以采用装饰模式&＃xff0c;用具体的装饰器来装饰实现类&＃xff0c;以达到增强的目的。
从名字来简单解释下装饰器。既然说是装饰&＃xff0c;那么往往就是添加小功能这种&＃xff0c;而且&＃xff0c;我们要满足可以添加多个小功能。最简单的&＃xff0c;代理模式就可以实现功能的增强&＃xff0c;但是代理不容易实现多个功能的增强&＃xff0c;当然你可以说用代理包装代理的多层包装方式&＃xff0c;但是那样的话代码就复杂了。
首先明白一些简单的概念&＃xff0c;从图中我们看到&＃xff0c;所有的具体装饰者们 ConcreteDecorator* 都可以作为 Component 来使用&＃xff0c;因为它们都实现了 Component 中的所有接口。它们和 Component 实现类 ConcreteComponent* 的区别是&＃xff0c;它们只是装饰者&＃xff0c;起装饰作用&＃xff0c;也就是即使它们看上去牛逼轰轰&＃xff0c;但是它们都只是在具体的实现中加了层皮来装饰而已。
注意这段话中混杂在各个名词中的 Component 和 Decorator&＃xff0c;别搞混了。
下面来看看一个例子&＃xff0c;先把装饰模式弄清楚&＃xff0c;然后再介绍下 java io 中的装饰模式的应用。
最近大街上流行起来了“快乐柠檬”&＃xff0c;我们把快乐柠檬的饮料分为三类&＃xff1a;红茶、绿茶、咖啡&＃xff0c;在这三大类的基础上&＃xff0c;又增加了许多的口味&＃xff0c;什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等&＃xff0c;每家店都有很长的菜单&＃xff0c;但是仔细看下&＃xff0c;其实原料也没几样&＃xff0c;但是可以搭配出很多组合&＃xff0c;如果顾客需要&＃xff0c;很多没出现在菜单中的饮料他们也是可以做的。
在这个例子中&＃xff0c;红茶、绿茶、咖啡是最基础的饮料&＃xff0c;其他的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。当然&＃xff0c;在开发中&＃xff0c;我们确实可以像门店一样&＃xff0c;开发这些类&＃xff1a;LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是&＃xff0c;很快我们就发现&＃xff0c;这样子干肯定是不行的&＃xff0c;这会导致我们需要组合出所有的可能&＃xff0c;而且如果客人需要在红茶中加双份柠檬怎么办&＃xff1f;三份柠檬怎么办&＃xff1f;
不说废话了&＃xff0c;上代码。
首先&＃xff0c;定义饮料抽象基类&＃xff1a;
public abstract class Beverage {// 返回描述public abstract String getDescription();// 返回价格public abstract double cost();
}
然后是三个基础饮料实现类&＃xff0c;红茶、绿茶和咖啡&＃xff1a;
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;}
}
...// 咖啡省略
定义调料&＃xff0c;也就是装饰者的基类&＃xff0c;此类必须继承自 Beverage&＃xff1a;
// 调料
public abstract class Condiment extends Beverage {}
然后我们来定义柠檬、芒果等具体的调料&＃xff0c;它们属于装饰者&＃xff0c;毫无疑问&＃xff0c;这些调料肯定都需要继承调料 Condiment 类&＃xff1a;
public class Lemon extends Condiment {private Beverage bevarage;// 这里很关键&＃xff0c;需要传入具体的饮料&＃xff0c;如需要传入没有被装饰的红茶或绿茶&＃xff0c;// 当然也可以传入已经装饰好的芒果绿茶&＃xff0c;这样可以做芒果柠檬绿茶public Lemon(Beverage bevarage) {this.bevarage &＃61; bevarage;}public String getDescription() {// 装饰return bevarage.getDescription() &＃43; ", 加柠檬";}public double cost() {// 装饰return beverage.cost() &＃43; 2; // 加柠檬需要 2 元}
}public class Mango extends Condiment {private Beverage bevarage;public Mango(Beverage bevarage) {this.bevarage &＃61; bevarage;}public String getDescription() {return bevarage.getDescription() &＃43; ", 加芒果";}public double cost() {return beverage.cost() &＃43; 3; // 加芒果需要 3 元}
}
...// 给每一种调料都加一个类
看客户端调用&＃xff1a;
public static void main(String[] args) {// 首先&＃xff0c;我们需要一个基础饮料&＃xff0c;红茶、绿茶或咖啡Beverage beverage &＃61; new GreenTea();// 开始装饰beverage &＃61; new Lemon(beverage); // 先加一份柠檬beverage &＃61; new Mongo(beverage); // 再加一份芒果System.out.println(beverage.getDescription() &＃43; " 价格&＃xff1a;&＃xffe5;" &＃43; beverage.cost());//"绿茶, 加柠檬, 加芒果 价格&＃xff1a;&＃xffe5;16"
}
如果我们需要 芒果-珍珠-双份柠檬-红茶&＃xff1a;
Beverage beverage &＃61; new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));
是不是很变态&＃xff1f;
看看下图可能会清晰一些&＃xff1a;
到这里&＃xff0c;大家应该已经清楚装饰模式了吧。
下面&＃xff0c;我们再来说说 java IO 中的装饰模式。看下图 InputStream 派生出来的部分类&＃xff1a;
我们知道 InputStream 代表了输入流&＃xff0c;具体的输入来源可以是文件&＃xff08;FileInputStream&＃xff09;、管道&＃xff08;PipedInputStream&＃xff09;、数组&＃xff08;ByteArrayInputStream&＃xff09;等&＃xff0c;这些就像前面奶茶的例子中的红茶、绿茶&＃xff0c;属于基础输入流。
FilterInputStream 承接了装饰模式的关键节点&＃xff0c;它的实现类是一系列装饰器&＃xff0c;比如 BufferedInputStream 代表用缓冲来装饰&＃xff0c;也就使得输入流具有了缓冲的功能&＃xff0c;LineNumberInputStream 代表用行号来装饰&＃xff0c;在操作的时候就可以取得行号了&＃xff0c;DataInputStream 的装饰&＃xff0c;使得我们可以从输入流转换为 java 中的基本类型值。
当然&＃xff0c;在 java IO 中&＃xff0c;如果我们使用装饰器的话&＃xff0c;就不太适合面向接口编程了&＃xff0c;如&＃xff1a;
InputStream inputStream &＃61; new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));
这样的结果是&＃xff0c;InputStream 还是不具有读取行号的功能&＃xff0c;因为读取行号的方法定义在 LineNumberInputStream 类中。
我们应该像下面这样使用&＃xff1a;
DataInputStream is &＃61; new DataInputStream(new BufferedInputStream(new FileInputStream("")));
所以说嘛&＃xff0c;要找到纯的严格符合设计模式的代码还是比较难的。
门面模式&＃xff08;也叫外观模式&＃xff0c;Facade Pattern&＃xff09;在许多源码中有使用&＃xff0c;比如 slf4j 就可以理解为是门面模式的应用。这是一个简单的设计模式&＃xff0c;我们直接上代码再说吧。
首先&＃xff0c;我们定义一个接口&＃xff1a;
public interface Shape {void draw();
}
定义几个实现类&＃xff1a;
public class Circle implements Shape {&＃64;Overridepublic void draw() {System.out.println("Circle::draw()");}
}public class Rectangle implements Shape {&＃64;Overridepublic void draw() {System.out.println("Rectangle::draw()");}
}
客户端调用&＃xff1a;
public static void main(String[] args) {// 画一个圆形Shape circle &＃61; new Circle();circle.draw();// 画一个长方形Shape rectangle &＃61; new Rectangle();rectangle.draw();
}
以上是我们常写的代码&＃xff0c;我们需要画圆就要先实例化圆&＃xff0c;画长方形就需要先实例化一个长方形&＃xff0c;然后再调用相应的 draw() 方法。
下面&＃xff0c;我们看看怎么用门面模式来让客户端调用更加友好一些。
我们先定义一个门面&＃xff1a;
public class ShapeMaker {private Shape circle;private Shape rectangle;private Shape square;public ShapeMaker() {circle &＃61; new Circle();rectangle &＃61; new Rectangle();square &＃61; new Square();}/*** 下面定义一堆方法&＃xff0c;具体应该调用什么方法&＃xff0c;由这个门面来决定*/public void drawCircle(){circle.draw();}public void drawRectangle(){rectangle.draw();}public void drawSquare(){square.draw();}
}
看看现在客户端怎么调用&＃xff1a;
public static void main(String[] args) {ShapeMaker shapeMaker &＃61; new ShapeMaker();// 客户端调用现在更加清晰了shapeMaker.drawCircle();shapeMaker.drawRectangle();shapeMaker.drawSquare();
}
门面模式的优点显而易见&＃xff0c;客户端不再需要关注实例化时应该使用哪个实现类&＃xff0c;直接调用门面提供的方法就可以了&＃xff0c;因为门面类提供的方法的方法名对于客户端来说已经很友好了。
组合模式用于表示具有层次结构的数据&＃xff0c;使得我们对单个对象和组合对象的访问具有一致性。
直接看一个例子吧&＃xff0c;每个员工都有姓名、部门、薪水这些属性&＃xff0c;同时还有下属员工集合&＃xff08;虽然可能集合为空&＃xff09;&＃xff0c;而下属员工和自己的结构是一样的&＃xff0c;也有姓名、部门这些属性&＃xff0c;同时也有他们的下属员工集合。
public class Employee {private String name;private String dept;private int salary;private List subordinates; // 下属public Employee(String name,String dept, int sal) {this.name &＃61; name;this.dept &＃61; dept;this.salary &＃61; sal;subordinates &＃61; new ArrayList();}public void add(Employee e) {subordinates.add(e);}public void remove(Employee e) {subordinates.remove(e);}public List getSubordinates(){return subordinates;}public String toString(){return ("Employee :[ Name : " &＃43; name &＃43; ", dept : " &＃43; dept &＃43; ", salary :" &＃43; salary&＃43;" ]");}
}
通常&＃xff0c;这种类需要定义 add(node)、remove(node)、getChildren() 这些方法。
这说的其实就是组合模式&＃xff0c;这种简单的模式我就不做过多介绍了&＃xff0c;相信各位读者也不喜欢看我写废话。
英文是 Flyweight Pattern&＃xff0c;不知道是谁最先翻译的这个词&＃xff0c;感觉这翻译真的不好理解&＃xff0c;我们试着强行关联起来吧。Flyweight 是轻量级的意思&＃xff0c;享元分开来说就是 共享 元器件&＃xff0c;也就是复用已经生成的对象&＃xff0c;这种做法当然也就是轻量级的了。
复用对象最简单的方式是&＃xff0c;用一个 HashMap 来存放每次新生成的对象。每次需要一个对象的时候&＃xff0c;先到 HashMap 中看看有没有&＃xff0c;如果没有&＃xff0c;再生成新的对象&＃xff0c;然后将这个对象放入 HashMap 中。
这种简单的代码我就不演示了。
前面&＃xff0c;我们说了代理模式、适配器模式、桥梁模式、装饰模式、门面模式、组合模式和享元模式。读者是否可以分别把这几个模式说清楚了呢&＃xff1f;在说到这些模式的时候&＃xff0c;心中是否有一个清晰的图或处理流程在脑海里呢&＃xff1f;
代理模式是做方法增强的&＃xff0c;适配器模式是把鸡包装成鸭这种用来适配接口的&＃xff0c;桥梁模式做到了很好的解耦&＃xff0c;装饰模式从名字上就看得出来&＃xff0c;适合于装饰类或者说是增强类的场景&＃xff0c;门面模式的优点是客户端不需要关心实例化过程&＃xff0c;只要调用需要的方法即可&＃xff0c;组合模式用于描述具有层次结构的数据&＃xff0c;享元模式是为了在特定的场景中缓存已经创建的对象&＃xff0c;用于提高性能。
行为型模式关注的是各个类之间的相互作用&＃xff0c;将职责划分清楚&＃xff0c;使得我们的代码更加地清晰。
策略模式太常用了&＃xff0c;所以把它放到最前面进行介绍。它比较简单&＃xff0c;我就不废话&＃xff0c;直接用代码说事吧。
下面设计的场景是&＃xff0c;我们需要画一个图形&＃xff0c;可选的策略就是用红色笔来画&＃xff0c;还是绿色笔来画&＃xff0c;或者蓝色笔来画。
首先&＃xff0c;先定义一个策略接口&＃xff1a;
public interface Strategy {public void draw(int radius, int x, int y);
}
然后我们定义具体的几个策略&＃xff1a;
public class RedPen implements Strategy {&＃64;Overridepublic void draw(int radius, int x, int y) {System.out.println("用红色笔画图&＃xff0c;radius:" &＃43; radius &＃43; ", x:" &＃43; x &＃43; ", y:" &＃43; y);}
}
public class GreenPen implements Strategy {&＃64;Overridepublic void draw(int radius, int x, int y) {System.out.println("用绿色笔画图&＃xff0c;radius:" &＃43; radius &＃43; ", x:" &＃43; x &＃43; ", y:" &＃43; y);}
}
public class BluePen implements Strategy {&＃64;Overridepublic void draw(int radius, int x, int y) {System.out.println("用蓝色笔画图&＃xff0c;radius:" &＃43; radius &＃43; ", x:" &＃43; x &＃43; ", y:" &＃43; y);}
}
使用策略的类&＃xff1a;
public class Context {private Strategy strategy;public Context(Strategy strategy){this.strategy &＃61; strategy;}public int executeDraw(int radius, int x, int y){return strategy.draw(radius, x, y);}
}
客户端演示&＃xff1a;
public static void main(String[] args) {Context context &＃61; new Context(new BluePen()); // 使用绿色笔来画context.executeDraw(10, 0, 0);
}
放到一张图上&＃xff0c;让大家看得清晰些&＃xff1a;
这个时候&＃xff0c;大家有没有联想到结构型模式中的桥梁模式&＃xff0c;它们其实非常相似&＃xff0c;我把桥梁模式的图拿过来大家对比下&＃xff1a;
要我说的话&＃xff0c;它们非常相似&＃xff0c;桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低&＃xff0c;结构更复杂一些。
观察者模式对于我们来说&＃xff0c;真是再简单不过了。无外乎两个操作&＃xff0c;观察者订阅自己关心的主题和主题有数据变化后通知观察者们。
首先&＃xff0c;需要定义主题&＃xff0c;每个主题需要持有观察者列表的引用&＃xff0c;用于在数据变更的时候通知各个观察者&＃xff1a;
public class Subject {private List observers &＃61; new ArrayList();private int state;public int getState() {return state;}public void setState(int state) {this.state &＃61; state;// 数据已变更&＃xff0c;通知观察者们notifyAllObservers();}// 注册观察者public void attach(Observer observer) {observers.add(observer);}// 通知观察者们public void notifyAllObservers() {for (Observer observer : observers) {observer.update();}}
}
定义观察者接口&＃xff1a;
public abstract class Observer {protected Subject subject;public abstract void update();
}
其实如果只有一个观察者类的话&＃xff0c;接口都不用定义了&＃xff0c;不过&＃xff0c;通常场景下&＃xff0c;既然用到了观察者模式&＃xff0c;我们就是希望一个事件出来了&＃xff0c;会有多个不同的类需要处理相应的信息。比如&＃xff0c;订单修改成功事件&＃xff0c;我们希望发短信的类得到通知、发邮件的类得到通知、处理物流信息的类得到通知等。
我们来定义具体的几个观察者类&＃xff1a;
public class BinaryObserver extends Observer {// 在构造方法中进行订阅主题public BinaryObserver(Subject subject) {this.subject &＃61; subject;// 通常在构造方法中将 this 发布出去的操作一定要小心this.subject.attach(this);}// 该方法由主题类在数据变更的时候进行调用&＃64;Overridepublic void update() {String result &＃61; Integer.toBinaryString(subject.getState());System.out.println("订阅的数据发生变化&＃xff0c;新的数据处理为二进制值为&＃xff1a;" &＃43; result);}
}public class HexaObserver extends Observer {public HexaObserver(Subject subject) {this.subject &＃61; subject;this.subject.attach(this);}&＃64;Overridepublic void update() {String result &＃61; Integer.toHexString(subject.getState()).toUpperCase();System.out.println("订阅的数据发生变化&＃xff0c;新的数据处理为十六进制值为&＃xff1a;" &＃43; result);}
}
客户端使用也非常简单&＃xff1a;
public static void main(String[] args) {// 先定义一个主题Subject subject1 &＃61; new Subject();// 定义观察者new BinaryObserver(subject1);new HexaObserver(subject1);// 模拟数据变更&＃xff0c;这个时候&＃xff0c;观察者们的 update 方法将会被调用subject.setState(11);
}
output:
订阅的数据发生变化&＃xff0c;新的数据处理为二进制值为&＃xff1a;1011
订阅的数据发生变化&＃xff0c;新的数据处理为十六进制值为&＃xff1a;B
当然&＃xff0c;jdk 也提供了相似的支持&＃xff0c;具体的大家可以参考 java.util.Observable 和 java.util.Observer 这两个类。
实际生产过程中&＃xff0c;观察者模式往往用消息中间件来实现&＃xff0c;如果要实现单机观察者模式&＃xff0c;笔者建议读者使用 Guava 中的 EventBus&＃xff0c;它有同步实现也有异步实现&＃xff0c;本文主要介绍设计模式&＃xff0c;就不展开说了。
还有&＃xff0c;即使是上面的这个代码&＃xff0c;也会有很多变种&＃xff0c;大家只要记住核心的部分&＃xff0c;那就是一定有一个地方存放了所有的观察者&＃xff0c;然后在事件发生的时候&＃xff0c;遍历观察者&＃xff0c;调用它们的回调函数。
责任链通常需要先建立一个单向链表&＃xff0c;然后调用方只需要调用头部节点就可以了&＃xff0c;后面会自动流转下去。比如流程审批就是一个很好的例子&＃xff0c;只要终端用户提交申请&＃xff0c;根据申请的内容信息&＃xff0c;自动建立一条责任链&＃xff0c;然后就可以开始流转了。
有这么一个场景&＃xff0c;用户参加一个活动可以领取奖品&＃xff0c;但是活动需要进行很多的规则校验然后才能放行&＃xff0c;比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后&＃xff0c;才能让用户领走奖品。
如果产品给你这个需求的话&＃xff0c;我想大部分人一开始肯定想的就是&＃xff0c;用一个 List 来存放所有的规则&＃xff0c;然后 foreach 执行一下每个规则就好了。不过&＃xff0c;读者也先别急&＃xff0c;看看责任链模式和我们说的这个有什么不一样&＃xff1f;
首先&＃xff0c;我们要定义流程上节点的基类&＃xff1a;
public abstract class RuleHandler {// 后继节点protected RuleHandler successor;public abstract void apply(Context context);public void setSuccessor(RuleHandler successor) {this.successor &＃61; successor;}public RuleHandler getSuccessor() {return successor;}
}
接下来&＃xff0c;我们需要定义具体的每个节点了。
校验用户是否是新用户&＃xff1a;
public class NewUserRuleHandler extends RuleHandler {public void apply(Context context) {if (context.isNewUser()) {// 如果有后继节点的话&＃xff0c;传递下去if (this.getSuccessor() !&＃61; null) {this.getSuccessor().apply(context);}} else {throw new RuntimeException("该活动仅限新用户参与");}}
}
校验用户所在地区是否可以参与&＃xff1a;
public class LocationRuleHandler extends RuleHandler {public void apply(Context context) {boolean allowed &＃61; activityService.isSupportedLocation(context.getLocation);if (allowed) {if (this.getSuccessor() !&＃61; null) {this.getSuccessor().apply(context);}} else {throw new RuntimeException("非常抱歉&＃xff0c;您所在的地区无法参与本次活动");}}
}
校验奖品是否已领完&＃xff1a;
public class LimitRuleHandler extends RuleHandler {public void apply(Context context) {int remainedTimes &＃61; activityService.queryRemainedTimes(context); // 查询剩余奖品if (remainedTimes > 0) {if (this.getSuccessor() !&＃61; null) {this.getSuccessor().apply(userInfo);}} else {throw new RuntimeException("您来得太晚了&＃xff0c;奖品被领完了");}}
}
客户端&＃xff1a;
public static void main(String[] args) {RuleHandler newUserHandler &＃61; new NewUserRuleHandler();RuleHandler locationHandler &＃61; new LocationRuleHandler();RuleHandler limitHandler &＃61; new LimitRuleHandler();// 假设本次活动仅校验地区和奖品数量&＃xff0c;不校验新老用户locationHandler.setSuccessor(limitHandler);locationHandler.apply(context);
}
代码其实很简单&＃xff0c;就是先定义好一个链表&＃xff0c;然后在通过任意一节点后&＃xff0c;如果此节点有后继节点&＃xff0c;那么传递下去。
至于它和我们前面说的用一个 List 存放需要执行的规则的做法有什么异同&＃xff0c;留给读者自己琢磨吧。
在含有继承结构的代码中&＃xff0c;模板方法模式是非常常用的。
通常会有一个抽象类&＃xff1a;
public abstract class AbstractTemplate {// 这就是模板方法public void templateMethod() {init();apply(); // 这个是重点end(); // 可以作为钩子方法}protected void init() {System.out.println("init 抽象层已经实现&＃xff0c;子类也可以选择覆写");}// 留给子类实现protected abstract void apply();protected void end() {}
}
模板方法中调用了 3 个方法&＃xff0c;其中 apply() 是抽象方法&＃xff0c;子类必须实现它&＃xff0c;其实模板方法中有几个抽象方法完全是自由的&＃xff0c;我们也可以将三个方法都设置为抽象方法&＃xff0c;让子类来实现。也就是说&＃xff0c;模板方法只负责定义第一步应该要做什么&＃xff0c;第二步应该做什么&＃xff0c;第三步应该做什么&＃xff0c;至于怎么做&＃xff0c;由子类来实现。
我们写一个实现类&＃xff1a;
public class ConcreteTemplate extends AbstractTemplate {public void apply() {System.out.println("子类实现抽象方法 apply");}public void end() {System.out.println("我们可以把 method3 当做钩子方法来使用&＃xff0c;需要的时候覆写就可以了");}
}
客户端调用演示&＃xff1a;
public static void main(String[] args) {AbstractTemplate t &＃61; new ConcreteTemplate();// 调用模板方法t.templateMethod();
}
代码其实很简单&＃xff0c;基本上看到就懂了&＃xff0c;关键是要学会用到自己的代码中。
update: 2017-10-19
废话我就不说了&＃xff0c;我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存&＃xff0c;我们看看怎么用状态模式来写。
核心在于&＃xff0c;我们的关注点不再是 Context 是该进行哪种操作&＃xff0c;而是关注在这个 Context 会有哪些操作。
定义状态接口&＃xff1a;
public interface State {public void doAction(Context context);
}
定义减库存的状态&＃xff1a;
public class DeductState implements State {public void doAction(Context context) {System.out.println("商品卖出&＃xff0c;准备减库存");context.setState(this);//... 执行减库存的具体操作}public String toString() {return "Deduct State";}
}
定义补库存状态&＃xff1a;
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)&＃xff0c;我们来看看怎么定义 Context 类&＃xff1a;
public class Context {private State state;private String name;public Context(String name) {this.name &＃61; name;}public void setState(State state) {this.state &＃61; state;}public void getState() {return this.state;}
}
我们来看下客户端调用&＃xff0c;大家就一清二楚了&＃xff1a;
public static void main(String[] args) {// 我们需要操作的是 iPhone XContext context &＃61; new Context("iPhone X");// 看看怎么进行补库存操作State revertState &＃61; new RevertState();revertState.doAction(context);// 同样的&＃xff0c;减库存操作也非常简单State deductState &＃61; new DeductState();deductState.doAction(context);// 如果需要我们可以获取当前的状态// context.getState().toString();
}
读者可能会发现&＃xff0c;在上面这个例子中&＃xff0c;如果我们不关心当前 context 处于什么状态&＃xff0c;那么 Context 就可以不用维护 state 属性了&＃xff0c;那样代码会简单很多。
不过&＃xff0c;商品库存这个例子毕竟只是个例&＃xff0c;我们还有很多实例是需要知道当前 context 处于什么状态的。
行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式&＃xff0c;其实&＃xff0c;经典的行为型模式还包括备忘录模式、命令模式等&＃xff0c;但是它们的使用场景比较有限&＃xff0c;而且本文篇幅也挺大了&＃xff0c;我就不进行介绍了。
学习设计模式的目的是为了让我们的代码更加的优雅、易维护、易扩展。这次整理这篇文章&＃xff0c;让我重新审视了一下各个设计模式&＃xff0c;对我自己而言收获还是挺大的。我想&＃xff0c;文章的最大收益者一般都是作者本人&＃xff0c;为了写一篇文章&＃xff0c;需要巩固自己的知识&＃xff0c;需要寻找各种资料&＃xff0c;而且&＃xff0c;自己写过的才最容易记住&＃xff0c;也算是我给读者的建议吧。
来源&＃xff1a;https://javadoop.com/post/design-pattern
PS&＃xff1a;如果觉得我的分享不错&＃xff0c;欢迎大家随手点赞、在看。
&＃xff08;完&＃xff09;加我"微信" 获取一份 最新Java面试题资料请备注&＃xff1a;666&＃xff0c;不然不通过&＃xff5e;最近好文
1、Spring Boot 实现扫码登录&＃xff0c;这种方式太香了&＃xff01;&＃xff01;2、SpringSecurity &＃43; JWT 实现单点登录3、基于 Vue&＃43;Spring 前后端分离管理系统ELAdmin4、Spring Boot 接入支付宝完整流程实战5、Spring Boot 实现多图片上传并回显&＃xff0c;涨姿势了&＃xff5e;最近面试BAT&＃xff0c;整理一份面试资料《Java面试BAT通关手册》&＃xff0c;覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。获取方式&＃xff1a;关注公众号并回复 java 领取&＃xff0c;更多内容陆续奉上。明天见(&＃xff61;&＃xff65;ω&＃xff65;&＃xff61;)&＃xff89;♡
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 