工厂模式和门面模式

  • 2020 年 4 月 12 日
  • 筆記

1.3 工厂模式

  • 任何可以产生对象的方法或类,都可以称之为工厂,单例也是一种工厂,为什么有了new之后,还需要工厂呢?以汽车举例:
// 移动的接口  interface Moveable() {      void go();  }    // 其他交通类实现移动类接口,例如这里的小汽车  class Car inplaments Mpveable {      public void go() {          System.out.println("Car run ...");      }  }  

1.3.1 简单工厂:产品维度扩展

/**  * 可扩展性不好,比如要添加一个火车的创建,就还需要添加一个方法  * 最简单的工厂是这个工厂既可以生产汽车,也可以生产其他交通工具  */  public class SimpleFactor() {      // 创建汽车      public Car creatCar() {      // 前置操作          return new Car();      }        // 创建飞机      public Plane creatPlane() {      // 前置操作          return new Plane();      }  }  

基于最简单的工程的改进:

// 单独生产car的工厂  public class CarFactor() {      // 创建汽车      public Car creatCar() {      // 前置操作,比如打印日志      System.out.println("创建了一个小汽车...");          return new Car();      }  }    public static void main(String[] args) {      // 向上转型      Moveable c = new CarFactory().creatCar();      c.go();  }  

改进后达到:

  1. 任意定制交通工具:继承Moveable
  2. 任意定制生产过程:Moveable -> XXXFactor.create();
  3. 任意定制产品一簇

1.3.2 抽象工厂- 方便产品族上的扩展

  • 这里举例,现代人产品族和魔法世界人产品族。现代人和魔法人都抽象出来食物,交通工具,武器三个组成的产品族
// 武器  public abstract class Weapon {      abstract void fire();  }  // 交通工具  public abstract class Vehicle {      abstract void run();  }  // 食物  public abstract class Food {      abstract void printlnName();  }    // 抽象工厂  public abstract class AbstractFactory() {      abstract Food createFood();      abstract Vehicle createVehicle();      abstract Weapon createWeapon();  }    // 具体工厂,可以是现代人工厂,可以是魔法世界人的工厂,继承自抽象工厂,实现扩展  public class  TrueFactory extents AbstractFactory {      Food createFood() {          // 根据不同工厂返回不同的食物,这里的现实世界人吃的面包类,继承自Food类。如果是魔法世界人的具体工厂,可以返回魔法世界人的食物          return new Bread();      }      Vehicle createVehicle(){          // 根据不同工厂返回具体的交通工具,Car类继承自Vehicle          return new Car();      }      Weapon createWeapon(){          // 根据不同工厂返回具体的武器,这里Ak47继承自Weapon          return new Ak47();      }  }    
  • 一般来说在设计接口和抽象类时,秉承形容词概念用接口,名词概念用抽象类的方式

1.3.3 静态工厂:静态方法产生的,例如单例

1.3.4 Bean工厂(Spring):可以很方便的定制我们的产品

1.4 Facate门面模式

比如Controller需要杂糅很多的service,业务很复杂,那么可以让Controller调用门面层Facate,门面层封装service,负责和service打交道。这样如果有另外一个Controller进来,也只需要掉门面即可

1.5 Mediator调停者模式

解决Service和Service之间的复杂调用,比如一个service调用很多的service来完整自己的工作,另外一个service也是如此,那么引入一个内部协调者,类似居委会大妈
Facate和Mediator只是一种叫法,该门面(协调者)对外就是Facate的概念,对内就是Mediator的概念 -> 解耦

1.5.1 经典应用:消息中间件(Mediator)

产生消息的把消息扔到消息中间件,其他使用消息的,去消息中间件去拿,这个消息中间件就类似门面,扮演协调者的作用,进行了解耦
松散耦合: 门面模式松散了客户端与子系统的耦合关系,让子系统内部的模块能更容易扩展和维护。