《设计模式二》工厂模式和门面模式

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）

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