创建型模式
创建型模式的作用就是创建对象,说到创建一个对象,最熟悉的就是 new 一个对象,然后 set 相关属性。但是,在很多场景下,我们需要给客户端提供更加友好的创建对象的方式,尤其是那种我们定义了类,但是需要提供给其他开发者用的时候。
- 单例模式
- 简单工厂模式
- 工厂模式
- 抽象工厂模式
- 建造者模式
- 原型模式
结构型模式
结构型模式旨在通过改变代码结构来达到解耦的目的,使得我们的代码容易维护和扩展。
- 代理模式
- 适配器模式
- 桥梁模式
- 装饰模式
- 门面模式
- 组合模式
- 享元模式
行为型模式
行为型模式关注的是各个类之间的相互作用,将职责划分清楚,使得我们的代码更加地清晰。
- 策略模式
- 观察者模式
- 责任链模式
- 模版方法模式
- 状态模式
单例模式(单线程)
保证一个类只有一个实例,并且提供一个访问该全局访问点。
-
应用:
- 网站的计数器,一般也是采用单例模式实现,否则难以同步。
- 应用程序的日志应用,一般都是单例模式实现,只有一个实例去操作才好,否则内容不好追加显示。
- 多线程的线程池的设计一般也是采用单例模式,因为线程池要方便对池中的线程进行控制
- Windows的(任务管理器)就是很典型的单例模式,他不能打开俩个
- windows的(回收站)也是典型的单例应用。在整个系统运行过程中,回收站只维护一个实例。
-
优点:
- 在单例模式中,活动的单例只有一个实例,对单例类的所有实例化得到的都是相同的一个实例。这样就防止其它对象对自己的实例化,确保所有的对象都访问一个实例
- 单例模式具有一定的伸缩性,类自己来控制实例化进程,类就在改变实例化进程上有相应的伸缩性。
- 提供了对唯一实例的受控访问。
- 由于在系统内存中只存在一个对象,因此可以节约系统资源,当需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。
- 允许可变数目的实例。
- 避免对共享资源的多重占用。
-
缺点:
-
不适用于变化的对象,如果同一类型的对象总是要在不同的用例场景发生变化,单例就会引起数据的错误,不能保存彼此的状态。
-
由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。
-
单例类的职责过重,在一定程度上违背了“单一职责原则”。
-
滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;如果实例化的对象长时间不被利用,系统会认为是垃圾而被回收,这将导致对象状态的丢失。
-
-
创建方式
如果不需要延迟加载单例,可以使用枚举或者饿汉式,相对来说枚举性好于饿汉式。
如果需要延迟加载,可以使用静态内部类或者懒汉式,相对来说静态内部类好于懒汉式。 最好使用饿汉式
- 饿汉式:类初始化时,会立即加载该对象,线程天生安全,调用效率高。
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(String mode) {return new Date();} }
- 懒汉式:类初始化时,不会初始化该对象,真正需要使用的时候才会创建该对象,具备懒加载功能。
public class Singleton {// 首先,也是先堵死 new Singleton() 这条路private Singleton() {}// 和饿汉模式相比,这边不需要先实例化出来,注意这里的 volatile,它是必须的// 双重检查,指的是两次检查 instance 是否为 null。private static volatile Singleton instance = null;public static Singleton getInstance() {if (instance == null) {// 加锁synchronized (Singleton.class) {// 这一次判断也是必须的,不然会有并发问题if (instance == null) {instance = new Singleton();}}}return instance;} }
- 静态内部方式(嵌套类):结合了懒汉式和饿汉式各自的优点,真正需要对象的时候才会加载,加载类是线程安全的。
public class Singleton3 {private Singleton3() {}// 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法的特性private static class Holder {private static Singleton3 instance = new Singleton3();}public static Singleton3 getInstance() {return Holder.instance;} }
- 枚举单例:使用枚举实现单例模式。优点:实现简单、调用效率高,枚举本身就是单例,由jvm从根本上提供保障,避免通过反射和反序列化的漏洞, 缺点没有延迟加载。
工厂模式(Bean)
它提供了一种创建对象的最佳方式。在工厂模式中,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象。实现了创建者和调用者分离。
-
分类
-
简单工厂:用来生产同一等级结构中的任意产品。(不支持拓展增加产品)
简单工厂模式相当于是一个工厂中有各种产品,创建在一个类中,客户无需知道具体产品的名称,只需要知道产品类所对应的参数即可。但是工厂的职责过重,而且当类型过多时不利于系统的扩展维护。
- 优点:简单工厂模式能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。明确区分了各自的职责和权力,有利于整个软件体系结构的优化。
- 缺点:很明显工厂类集中了所有实例的创建逻辑,容易违反GRASPR的高内聚的责任分配原则
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;}} }
-
工厂方法:用来生产同一等级结构中的固定产品。(支持拓展增加产品)
又称多态性工厂模式。在工厂方法模式中,核心的工厂类不再负责所有的产品的创建,而是将具体创建的工作交给子类去做。该核心类成为一个抽象工厂角色,仅负责给出具体工厂子类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
public interface FoodFactory {Food makeFood(String name); } public class ChineseFoodFactory implements FoodFactory {@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 {@Overridepublic Food makeFood(String name) {if (name.equals("A")) {return new AmericanFoodA();} else if (name.equals("B")) {return new AmericanFoodB();} else {return null;}} }// 调用 public class APP {public static void main(String[] args) {// 先选择一个具体的工厂FoodFactory factory = new ChineseFoodFactory();// 由第一步的工厂产生具体的对象,不同的工厂造出不一样的对象Food food = factory.makeFood("A");} }
-
抽象工厂模式:用来生产不同产品族的全部产品。(不支持拓展增加产品;支持增加产品族)
抽象工厂简单地说是工厂的工厂,抽象工厂可以创建具体工厂,由具体工厂来产生具体产品。
// 得到 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, mainBoard);public static void main(String[] args) {// 第一步就要选定一个“大厂”ComputerFactory cf = new AmdFactory();// 从这个大厂造 CPUCPU cpu = cf.makeCPU();// 从这个大厂造主板MainBoard board = cf.makeMainBoard();// 从这个大厂造硬盘HardDisk hardDisk = cf.makeHardDisk();// 将同一个厂子出来的 CPU、主板、硬盘组装在一起Computer result = new Computer(cpu, board, hardDisk); }
-
-
优点
- 工厂模式是我们最常用的实例化对象模式了,是用工厂方法代替new操作的一种模式。
- 利用工厂模式可以降低程序的耦合性,为后期的维护修改提供了很大的便利。
- 将选择实现类、创建对象统一管理和控制。从而将调用者跟我们的实现类解耦。
-
Spring开发中的工厂设计模式
-
Spring IOC
- 在Spring IOC容器创建bean的过程是使用了工厂设计模式
- Spring中无论是通过xml配置还是通过配置类还是注解进行创建bean,大部分都是通过简单工厂来进行创建的。
- 当容器拿到了beanName和class类型后,动态的通过反射创建具体的某个对象,最后将创建的对象放到Map中。
-
为什么Spring IOC要使用工厂设计模式创建Bean呢
- 在实际开发中,如果我们A对象调用B,B调用C,C调用D的话我们程序的耦合性就会变高。(耦合大致分为类与类之间的依赖,方法与方法之间的依赖。)
- 在很久以前的三层架构编程时,都是控制层调用业务层,业务层调用数据访问层时,都是是直接new对象,耦合性大大提升,代码重复量很高,对象满天飞
- 为了避免这种情况,Spring使用工厂模式编程,写一个工厂,由工厂创建Bean,以后我们如果要对象就直接管工厂要就可以,剩下的事情不归我们管了。Spring IOC容器的工厂中有个静态的 Map集合,是为了让工厂符合单例设计模式,即每个对象只生产一次,生产出对象后就存入到 Map集合中,保证了实例不会重复影响程序效率
-
原型模式(克隆)
- 原型设计模式简单来说就是克隆
protected native Object clone() throws CloneNotSupportedException;
- 原型表明了有一个样板实例,这个原型是可定制的。原型模式多用于创建复杂的或者构造耗时的实例,因为这种情况下,复制一个已经存在的实例可使程序运行更高效。
- 应用场景
- 类初始化需要消化非常多的资源,这个资源包括数据、硬件资源等。这时我们就可以通过原型拷贝避免这些消耗。
- 通过new产生的一个对象需要非常繁琐的数据准备或者权限,这时可以使用原型模式。
- 一个对象需要提供给其他对象访问,而且各个调用者可能都需要修改其值时,可以考虑使用原型模式拷贝多个对象供调用者使用,即保护性拷贝。
- 使用方式
- 实现Cloneable接口。在java语言有一个Cloneable接口,它的作用只有一个,就是在运行时通知虚拟机可以安全地在实现了此接口的类上使用clone方法。在java虚拟机中,只有实现了这个接口的类才可以被拷贝,否则在运行时会抛出CloneNotSupportedException异常。
- 重写Object类中的clone方法。Java中,所有类的父类都是Object类,Object类中有一个clone方 法,作用是返回对象的一个拷贝,但是其作用域protected类型的,一般的类无法调用,因此 Prototype类需要将clone方法的作用域修改为public类型。
- 原型模式分为浅复制和深复制
- 浅复制:只是拷贝了基本类型的数据,而引用类型数据,只是拷贝了一份引用地址。
- 深复制:在计算机中开辟了一块新的内存地址用于存放复制的对象。
建造者模式(构建与表示分离、StringBuilder)
- 是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的方式进行创建。
- 工厂类模式是提供的是创建单个类的产品,而建造者模式则是将各种产品集中起来进行管理,用来具有不同的属性的产品
- 建造者模式通常包括下面几个角色:
- uilder:给出一个抽象接口,以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的哪些部分的创建,并不涉及具体的对象部件的创建。
- ConcreteBuilder:实现Builder接口,针对不同的商业逻辑,具体化复杂对象的各部分的创建。 在建造过程完成后,提供产品的实例。
- Director:调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
- Product:要创建的复杂对象。
- 使用场景
- 需要生成的对象具有复杂的内部结构。
- 需要生成的对象内部属性本身相互依赖。
- 与工厂模式的区别是:建造者模式更加关注与零件装配的顺序。
- JAVA 中的 StringBuilder就是建造者模式创建的,他把一个单个字符的char数组组合起来
- Spring不是建造者模式,它提供的操作应该是对于字符串本身的一些操作,而不是创建或改变一个字符串。
// lombok
@Builder
class User {private String name;private String password;private String nickName;private int age;
}public class APP {public static void main(String[] args) {User d = User.builder().name("foo").password("pAss12345").age(25).build();// 链式User user = new User().setName("").setPassword("").setAge(20);}
}
代理模式(AOP、异常处理)
- 通过代理控制对象的访问,可以在这个对象调用方法之前、调用方法之后去处理/添加新的功能。 (也就是AOP微实现)。代理在原有代码乃至原业务流程都不修改的情况下,直接在业务流程中切入新代码,增加新功能, 这也和Spring的(面向切面编程)很相似
- 用一个代理来隐藏具体实现类的实现细节,通常还用于在真实的实现的前后添加一部分逻辑。既然说是代理,那就要对客户端隐藏真实实现,由代理来负责客户端的所有请求。当然,代理只是个代理,它不会完成实际的业务逻辑,而是一层皮而已,但是对于客户端来说,它必须表现得就是客户端需要的真实实现。
- 应用场景
- Spring AOP、日志打印、异常处理、事务控制、权限控制等
- 分类
- 静态代理(静态定义代理类)
- 简单代理模式,是动态代理的理论基础。常见使用在代理模式。由程序员创建或工具生成代理类的源码,再编译代理类。所谓静态也就是在程序运行前就已经存在代理类的字节码文件,代理类和委托类的关系在运行前就确定了。
- 缺点:每个需要代理的对象都需要自己重复编写代理,很不舒服,
- 优点:但是可以面相实际对象或者是接口的方式实现代理
- 动态代理(动态生成代理类,也称为Jdk自带动态代理)
- 使用反射完成代理。需要有顶层接口才能使用,常见是mybatis的mapper文件是代理。动态代理的对象,是利用JDK的API,动态的在内存中构建代理对象(是根据被代理的接口来动态生成代理类的class文件,并加载运行的过程),这就叫动态代理
- 缺点:必须是面向接口,目标业务类必须实现接口
- 优点:不用关心代理类,只需要在运行阶段才指定代理哪一个对象
- Cglib 、javaassist(字节码操作库)
- 也是使用反射完成代理,可以直接代理类(jdk动态代理不行),使用字节码技术,不能对final类进行继承。(需要导入jar包)
- 静态代理(静态定义代理类)
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();
代理模式说白了就是做 “方法包装” 或做 “方法增强”。在面向切面编程中,其实就是动态代理的过程。比如 Spring 中,我们自己不定义代理类,但是 Spring 会帮我们动态来定义代理,然后把我们定义在 @Before、@After、@Around 中的代码逻辑动态添加到代理中。
说到动态代理,又可以展开说,Spring 中实现动态代理有两种:
- 一种是如果我们的类定义了接口,如 UserService 接口和 UserServiceImpl 实现,那么采用 JDK 的动态代理,感兴趣的读者可以去看看 java.lang.reflect.Proxy 类的源码
- 另一种是我们自己没有定义接口的,Spring 会采用 CGLIB 进行动态代理,它是一个 jar 包,性能还不错。
适配器模式
适配器模式做的就是,有一个接口需要实现,但是我们现成的对象都不满足,需要加一层适配器来进行适配。
适配器模式总体来说分三种:默认适配器模式、对象适配器模式、类适配器模式。
默认适配器模式
我们用 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 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) {}
}
比如我们可以定义以下类,我们仅仅需要实现我们想实现的方法就可以了:
public class FileMonitor extends FileAlterationListenerAdaptor {public void onFileCreate(final File file) {// 文件创建doSomething();}public void onFileDelete(final File file) {// 文件删除doSomething();}
}
当然,上面说的只是适配器模式的其中一种,也是最简单的一种,无需多言。下面,再介绍**“正统的”**适配器模式。
对象适配器模式
来看一个《Head First 设计模式》中的一个例子,我稍微修改了一下,看看怎么将鸡适配成鸭,这样鸡也能当鸭来用。因为,现在鸭这个接口,我们没有合适的实现类可以用,所以需要适配器。
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() 两个方法,鸡 Cock 如果要冒充鸭,fly() 方法是现成的,但是鸡不会鸭的呱呱叫,没有 quack() 方法。这个时候就需要适配了:
// 毫无疑问,首先,这个适配器肯定需要 implements Duck,这样才能当做鸭来用
public class CockAdapter implements Duck {Cock cock;// 构造方法中需要一个鸡的实例,此类就是将这只鸡适配成鸭来用public CockAdapter(Cock cock) {this.cock = cock;}// 实现鸭的呱呱叫方法@Overridepublic void quack() {// 内部其实是一只鸡的咕咕叫cock.gobble();}@Overridepublic void fly() {cock.fly();}
}
客户端调用很简单了:
public static void main(String[] args) {// 有一只野鸡Cock wildCock = new WildCock();// 成功将野鸡适配成鸭Duck duck = new CockAdapter(wildCock);...
}
到这里,大家也就知道了适配器模式是怎么回事了。无非是我们需要一只鸭,但是我们只有一只鸡,这个时候就需要定义一个适配器,由这个适配器来充当鸭,但是适配器里面的方法还是由鸡来实现的。
类适配器模式
适配器模式总结
-
类适配和对象适配的异同
一个采用继承,一个采用组合;
类适配属于静态实现,对象适配属于组合的动态实现,对象适配需要多实例化一个对象。
总体来说,对象适配用得比较多。
-
适配器模式和代理模式的异同
比较这两种模式,其实是比较对象适配器模式和代理模式,在代码结构上,它们很相似,都需要一个具体的实现类的实例。但是它们的目的不一样,代理模式做的是增强原方法的活;适配器做的是适配的活,为的是提供“把鸡包装成鸭,然后当做鸭来使用”,而鸡和鸭它们之间原本没有继承关系。
桥梁模式
理解桥梁模式,其实就是理解代码抽象和解耦。我们首先需要一个桥梁,它是一个接口,定义提供的接口方法。
public interface DrawAPI {public void draw(int radius, int x, int y);
}
然后是一系列实现类:
public class RedPen implements DrawAPI {@Overridepublic void draw(int radius, int x, int y) {System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);}
}
public class GreenPen implements DrawAPI {@Overridepublic void draw(int radius, int x, int y) {System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);}
}
public class BluePen implements DrawAPI {@Overridepublic 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();
}
桥梁模式的优点也是显而易见的,就是非常容易进行扩展。
装饰模式
要把装饰模式说清楚明白,不是件容易的事情。也许读者知道 Java IO 中的几个类是典型的装饰模式的应用,但是读者不一定清楚其中的关系,也许看完就忘了,希望看完这节后,读者可以对其有更深的感悟。
首先,我们先看一个简单的图,看这个图的时候,了解下层次结构就可以了:
我们来说说装饰模式的出发点,从图中可以看到,接口 Component
其实已经有了 ConcreteComponentA
和 ConcreteComponentB
两个实现类了,但是,如果我们要增强这两个实现类的话,我们就可以采用装饰模式,用具体的装饰器来装饰实现类,以达到增强的目的。
从名字来简单解释下装饰器。既然说是装饰,那么往往就是添加小功能这种,而且,我们要满足可以添加多个小功能。最简单的,代理模式就可以实现功能的增强,但是代理不容易实现多个功能的增强,当然你可以说用代理包装代理的多层包装方式,但是那样的话代码就复杂了。
首先明白一些简单的概念,从图中我们看到,所有的具体装饰者们 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(Beverage bevarage) {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(Beverage bevarage) {this.bevarage = bevarage;}public String getDescription() {return bevarage.getDescription() + ", 加芒果";}public double cost() {return beverage.cost() + 3; // 加芒果需要 3 元}
}
...// 给每一种调料都加一个类
看客户端调用:
public static void main(String[] args) {// 首先,我们需要一个基础饮料,红茶、绿茶或咖啡Beverage beverage = new GreenTea();// 开始装饰beverage = new Lemon(beverage); // 先加一份柠檬beverage = new Mongo(beverage); // 再加一份芒果System.out.println(beverage.getDescription() + " 价格:¥" + beverage.cost());//"绿茶, 加柠檬, 加芒果 价格:¥16"
}
如果我们需要 芒果-珍珠-双份柠檬-红茶:
Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));
到这里,大家应该已经清楚装饰模式了吧。
下面,我们再来说说 java IO 中的装饰模式。看下图 InputStream 派生出来的部分类:
我们知道 InputStream 代表了输入流,具体的输入来源可以是文件(FileInputStream)、管道(PipedInputStream)、数组(ByteArrayInputStream)等,这些就像前面奶茶的例子中的红茶、绿茶,属于基础输入流。
FilterInputStream 承接了装饰模式的关键节点,它的实现类是一系列装饰器,比如 BufferedInputStream 代表用缓冲来装饰,也就使得输入流具有了缓冲的功能,LineNumberInputStream 代表用行号来装饰,在操作的时候就可以取得行号了,DataInputStream 的装饰,使得我们可以从输入流转换为 java 中的基本类型值。
当然,在 java IO 中,如果我们使用装饰器的话,就不太适合面向接口编程了,如:
InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));
这样的结果是,InputStream 还是不具有读取行号的功能,因为读取行号的方法定义在 LineNumberInputStream 类中。
我们应该像下面这样使用:
DataInputStream is = new DataInputStream(new BufferedInputStream(new FileInputStream("")));
所以说嘛,要找到纯的严格符合设计模式的代码还是比较难的。
门面模式(外观模式,接口)
- 隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口
- 它向现有的系统添加一个接口,用这一个接口来隐藏实际的系统的复杂性。
- 使用外观模式,他外部看起来就是一个接口,其实他的内部有很多复杂的接口已经被实现
门面模式(也叫外观模式,Facade Pattern)在许多源码中有使用,比如 slf4j 就可以理解为是门面模式的应用。这是一个简单的设计模式,我们直接上代码再说吧。
首先,我们定义一个接口:
public interface Shape {void draw();
}
定义几个实现类:
public class Circle implements Shape {@Overridepublic void draw() {System.out.println("Circle::draw()");}
}public class Rectangle implements Shape {@Overridepublic 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();
}
门面模式的优点显而易见,客户端不再需要关注实例化时应该使用哪个实现类,直接调用门面提供的方法就可以了,因为门面类提供的方法的方法名对于客户端来说已经很友好了。
组合模式
组合模式用于表示具有层次结构的数据,使得我们对单个对象和组合对象的访问具有一致性。
直接看一个例子吧,每个员工都有姓名、部门、薪水这些属性,同时还有下属员工集合(虽然可能集合为空),而下属员工和自己的结构是一样的,也有姓名、部门这些属性,同时也有他们的下属员工集合。
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 = name;this.dept = dept;this.salary = sal;subordinates = 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 : " + name + ", dept : " + dept + ", salary :" + salary+" ]");}
}
通常,这种类需要定义 add(node)、remove(node)、getChildren() 这些方法。
这说的其实就是组合模式,这种简单的模式我就不做过多介绍了,相信各位读者也不喜欢看我写废话。
享元模式
英文是 Flyweight Pattern,不知道是谁最先翻译的这个词,感觉这翻译真的不好理解,我们试着强行关联起来吧。Flyweight 是轻量级的意思,享元分开来说就是共享元器件,也就是复用已经生成的对象,这种做法当然也就是轻量级的了。
复用对象最简单的方式是,用一个 HashMap 来存放每次新生成的对象。每次需要一个对象的时候,先到 HashMap 中看看有没有,如果没有,再生成新的对象,然后将这个对象放入 HashMap 中。
模板方法模式
-
定义一个操作中的算法骨架(父类),而将一些步骤延迟到子类中。 模板方法使得子类可以不改变一个算法的结构来重定义该算法的
-
什么时候使用模板方法
实现一些操作时,整体步骤很固定,但是呢。就是其中一小部分需要改变,这时候可以使用模板方法模式,将容易变的部分抽象出来,供子类实现。
-
应用场景:数据库访问的封装、Junit单元测试、servlet中关于doGet/doPost方法的调用等等
在含有继承结构的代码中,模板方法模式是非常常用的。
通常会有一个抽象类:
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();
}
代码其实很简单,基本上看到就懂了,关键是要学会用到自己的代码中。
策略模式(if…else)
-
定义了一系列的算法或逻辑或相同意义的操作,并将每一个算法、逻辑、操作封装起来,而且使它们还可以相互替换。(其实策略模式Java中用的非常非常广泛)
-
我觉得主要是为了简化 if…else 所带来的复杂和难以维护。
-
应用场景
- 策略模式的用意是针对一组算法或逻辑,将每一个算法或逻辑封装到具有共同接口的独立的类中, 从而使得它们之间可以相互替换。
- 例如:我要做一个不同会员打折力度不同的三种策略,初级会员,中级会员,高级会员(三种不同的计算)。
- 例如:我要一个支付模块,我要有微信支付、支付宝支付、银联支付等
-
优点
- 算法可以自由切换。 避免使用多重条件判断。扩展性非常良好。
-
缺点
- 策略类会增多。 所有策略类都需要对外暴露。
首先,先定义一个策略接口:
public interface Strategy {public void draw(int radius, int x, int y);
}
然后我们定义具体的几个策略:
public class RedPen implements Strategy {@Overridepublic void draw(int radius, int x, int y) {System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);}
}
public class GreenPen implements Strategy {@Overridepublic void draw(int radius, int x, int y) {System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);}
}
public class BluePen implements Strategy {@Overridepublic 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 int executeDraw(int radius, int x, int y){return strategy.draw(radius, x, y);}
}
客户端演示:
public static void main(String[] args) {Context context = new Context(new BluePen()); // 使用绿色笔来画context.executeDraw(10, 0, 0);
}
要我说的话,它们非常相似,桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低,结构更复杂一些。
观察者模式(发布订阅)
-
行为性模型,行为型模式关注的是系统中对象之间的相互交互,解决系统在运行时对象之间的相互通信和协作,进一步明确对象的职责。
-
观察者模式,是一种行为性模型,又叫发布-订阅模式,他定义对象之间一种一对多的依赖关系, 使得当一个对象改变状态,则所有依赖于它的对象都会得到通知并自动更新。
-
模式的职责
观察者模式主要用于1对N的通知。当一个对象的状态变化时,他需要及时告知一系列对象,令他们做出相应。
-
实现有两种方式
- 推:每次都会把通知以广播的方式发送给所有观察者,所有的观察者只能被动接收。
- 拉:观察者只要知道有情况即可,至于什么时候获取内容,获取什么内容,都可以自主决定。
-
应用场景
- 关联行为场景,需要注意的是,关联行为是可拆分的,而不是“组合”关系。事件多级触发场景。
- 跨系统的消息交换场景,如消息队列、事件总线的处理机制。
首先,需要定义主题,每个主题需要持有观察者列表的引用,用于在数据变更的时候通知各个观察者:
public class Subject {private List observers = new ArrayList();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);}// 该方法由主题类在数据变更的时候进行调用@Overridepublic 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);}@Overridepublic 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);
}
output:
订阅的数据发生变化,新的数据处理为二进制值为:1011
订阅的数据发生变化,新的数据处理为十六进制值为:B
当然,jdk 也提供了相似的支持,具体的大家可以参考 java.util.Observable 和 java.util.Observer 这两个类。
实际生产过程中,观察者模式往往用消息中间件来实现,如果要实现单机观察者模式,笔者建议读者使用 Guava 中的 EventBus,它有同步实现也有异步实现,本文主要介绍设计模式,就不展开说了。
还有,即使是上面的这个代码,也会有很多变种,大家只要记住核心的部分,那就是一定有一个地方存放了所有的观察者,然后在事件发生的时候,遍历观察者,调用它们的回调函数。
责任链模式
责任链通常需要先建立一个单向链表,然后调用方只需要调用头部节点就可以了,后面会自动流转下去。比如流程审批就是一个很好的例子,只要终端用户提交申请,根据申请的内容信息,自动建立一条责任链,然后就可以开始流转了。
有这么一个场景,用户参加一个活动可以领取奖品,但是活动需要进行很多的规则校验然后才能放行,比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后,才能让用户领走奖品。
如果产品给你这个需求的话,我想大部分人一开始肯定想的就是,用一个 List 来存放所有的规则,然后 foreach 执行一下每个规则就好了。不过,读者也先别急,看看责任链模式和我们说的这个有什么不一样?
首先,我们要定义流程上节点的基类:
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);
}
代码其实很简单,就是先定义好一个链表,然后在通过任意一节点后,如果此节点有后继节点,那么传递下去。
至于它和我们前面说的用一个 List 存放需要执行的规则的做法有什么异同,留给读者自己琢磨吧。
状态模式
废话我就不说了,我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存,我们看看怎么用状态模式来写。核心在于,我们的关注点不再是 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 XContext 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 属性了,那样代码会简单很多。
不过,商品库存这个例子毕竟只是个例,我们还有很多实例是需要知道当前 context 处于什么状态的。
spring中用到哪些设计模式?
- 工厂模式,这个很明显,在各种BeanFactory以及ApplicationContext创建中都用到了;
- 模版模式,这个也很明显,在各种BeanFactory以及ApplicationContext实现中也都用到了;
- 代理模式,在Aop实现中用到了JDK的动态代理;
- 单例模式,这个比如在创建bean的时候。
- 外观模式,Tomcat中有很多场景都使用到了外观模式,因为Tomcat中有很多不同的组件,每个组件需要相互通信,但又不能将自己内部数据过多地暴露给其他组件。用外观模式隔离数据是个很好的方法。
- 策略模式,因为Comparator这个接口简直就是为策略模式而生的。Comparable和Comparator的区别一文中,详细讲了Comparator的使用。比方说Collections里面有一个sort方法,因为集合里面的元素有可能是复合对象,复合对象并不像基本数据类型,可以根据大小排序,复合对象怎么排序呢?基于这个问题考虑,Java要求如果定义的复合对象要有排序的功能,就自行实现Comparable接口或Comparator接口.
- 原型模式:使用原型模式创建对象比直接new一个对象在性能上好得多,因为Object类的clone()方法是一个native方法,它直接操作内存中的二进制流,特别是复制大对象时,性能的差别非常明显。
- 迭代器模式:Iterable接口和Iterator接口 这两个都是迭代相关的接口,可以这么认为,实现了Iterable接口,则表示某个对象是可被迭代的;Iterator接口相当于是一个迭代器,实现了Iterator接口,等于具体定义了这个可被迭代的对象时如何进行迭代的