设计模式之抽象工厂模式

设计模式之抽象工厂模式

点击浏览其他设计模式

一、工厂方法模式介绍
工厂模式又称工厂方法模式，是一种创建型设计模式，其在父类中提供一个创建对象的方法， 允许子类决定实例化对象的类型。

抽象工厂模式与工厂方法模式虽然主要意图都是为了解决接口选择问题。但在实现上，抽象工厂是一个中心工厂，创建其他工厂的模式，如图，工厂模式和抽象工厂模式对比，也可以形象的比喻为我们平常吃的食堂。

除了这样显而易见的例子外，我们的业务开发中时常也会遇到类似的问题，需要兼容做处理，但大部分经验不足的开发人员，常常直接通过添加ifelse方式进行处理了。
抽象工厂简单代码如图
。

二、案例场景模拟

模拟企业级双套Redis集群升级，很多时候初期业务的蛮荒发展，也会牵动着研发对系统的建设。预估QPS较低、系统压力较小、并发访问不大、近一年没有大动作等等，在考虑时间投入成本的前提前，并不会投入特别多的人力去构建非常完善的系统。就像对 Redis 的使用，往往可能只要是单机的就可以满足现状。
但随着业务超过预期的快速发展，系统的负载能力也要随着跟上。原有的单机 Redis 已经满足不了系统需求。这时候就需要更换为更为健壮的Redis集群服务，虽然需要修改但是不能影响目前系统的运行，还要平滑过渡过去。

随着这次的升级，可以预见的问题会有；
很多服务用到了Redis需要一起升级到集群。
需要兼容集群A和集群B，便于后续的灾备。
两套集群提供的接口和方法各有差异，需要做适配。
不能影响到目前正常运行的系统。

1. 场景模拟工程
   itstack-demo-design-2-00
   └── src
   └── main
   └── java
   └── org.itstack.demo.design
   ├── matter
   │ ├── EGM.java
   │ └── IIR.java
   └── RedisUtils.java

2. 场景简述
   2.1 模拟单机服务 RedisUtils
   Redis单机服务，模拟Redis功能，也就是假定目前所有的系统都在使用的服务，类和方法名次都固定写死到各个业务系统中，改动略微麻烦
   2.2 模拟集群 EGM
   模拟集群 EGM，模拟一个集群服务，但是方法名与各业务系统中使用的方法名不同。有点像你mac，我用win。做一样的事，但有不同的操作。
   2.3 模拟集群 IIR
   模拟集群 IIR，这是另外一套集群服务，有时候在企业开发中就很有可能出现两套服务，这里我们也是为了做模拟案例，所以添加两套实现同样功能的不同服务，来学习抽象工厂模式。
   综上可以看到，我们目前的系统中已经在大量的使用redis服务，但是因为系统不能满足业务的快速发展，因此需要迁移到集群服务中。而这时有两套集群服务需要兼容使用，又要满足所有的业务系统改造的同时不影响线上使用。

3. 单集群代码使用
   以下是案例模拟中原有的单集群Redis使用方式，后续会通过对这里的代码进行改造。当前功能的类图结构
   3.1 定义使用接口

public interface CacheService {

    String get(final String key);

    void set(String key, String value);

    void set(String key, String value, long timeout, TimeUnit timeUnit);

    void del(String key);

}

3.2 实现调用代码

public class CacheServiceImpl implements CacheService {

    private RedisUtils redisUtils = new RedisUtils();

    public String get(String key) {
        return redisUtils.get(key);
    }

    public void set(String key, String value) {
        redisUtils.set(key, value);
    }

    public void set(String key, String value, long timeout, TimeUnit timeUnit) {
        redisUtils.set(key, value, timeout, timeUnit);
    }

    public void del(String key) {
        redisUtils.del(key);
    }

}

目前的代码对于当前场景下的使用没有什么问题，也比较简单。但是所有的业务系统都在使用同时，需要改造就不那么容易了。这里可以思考下，看如何改造才是合理的。
三、用一坨坨代码实现
讲道理没有ifelse解决不了的逻辑，不行就在加一行！

此时的实现方式并不会修改类结构图，也就是与上面给出的类层级关系一致。通过在接口中添加类型字段区分当前使用的是哪个集群，来作为使用的判断。可以说目前的方式非常难用，其他使用方改动颇多，这里只是做为例子。

1. 工程结构
   itstack-demo-design-2-01
   └── src
   └── main
   └── java
   └── org.itstack.demo.design
   ├── impl
   │ └── CacheServiceImpl.java
   └── CacheService.java
   此时的只有两个类，类结构非常简单。而我们需要的补充扩展功能也只是在 CacheServiceImpl 中实现。
2. ifelse实现需求

public class CacheServiceImpl implements CacheService {

    private RedisUtils redisUtils = new RedisUtils();

    private EGM egm = new EGM();

    private IIR iir = new IIR();

    public String get(String key, int redisType) {

        if (1 == redisType) {
            return egm.gain(key);
        }

        if (2 == redisType) {
            return iir.get(key);
        }

        return redisUtils.get(key);
    }

    public void set(String key, String value, int redisType) {

        if (1 == redisType) {
            egm.set(key, value);
            return;
        }

        if (2 == redisType) {
            iir.set(key, value);
            return;
        }

        redisUtils.set(key, value);
    }

    //... 同类不做太多展示，可以下载源码进行参考

}

这里的实现过程非常简单，主要根据类型判断是哪个Redis集群。
虽然实现是简单了，但是对使用者来说就麻烦了，并且也很难应对后期的拓展和不停的维护。
3. 测试验证
接下来我们通过junit单元测试的方式验证接口服务，强调日常编写好单测可以更好的提高系统的健壮度。

「编写测试类：」

@Test
public void test_CacheService() {
    CacheService cacheService = new CacheServiceImpl();
    cacheService.set("user_name_01", "小傅哥", 1);
    String val01 = cacheService.get("user_name_01",1);
    System.out.println(val01);
}

「结果：」

22:26:24.591 [main] INFO  org.itstack.demo.design.matter.EGM - EGM写入数据 key：user_name_01 val：小傅哥
22:26:24.593 [main] INFO  org.itstack.demo.design.matter.EGM - EGM获取数据 key：user_name_01
测试结果：小傅哥

Process finished with exit code 0

从结果上看运行正常，并没有什么问题。但这样的代码只要到生成运行起来以后，想再改就真的难了！
六、抽象工厂模式重构代码
接下来使用抽象工厂模式来进行代码优化，也算是一次很小的重构。

这里的抽象工厂的创建和获取方式，会采用代理类的方式进行实现。所被代理的类就是目前的Redis操作方法类，让这个类在不需要任何修改下，就可以实现调用集群A和集群B的数据服务。

并且这里还有一点非常重要，由于集群A和集群B在部分方法提供上是不同的，因此需要做一个接口适配，而这个适配类就相当于工厂中的工厂，用于创建把不同的服务抽象为统一的接口做相同的业务。这一块与我们上一章节中的工厂方法模型类型，可以翻阅参考。

1. 工程结构
   itstack-demo-design-2-02
   └── src
   ├── main
   │ └── java
   │ └── org.itstack.demo.design
   │ ├── factory
   │ │ ├── impl
   │ │ │ ├── EGMCacheAdapter.java
   │ │ │ └── IIRCacheAdapter.java
   │ │ ├── ICacheAdapter.java
   │ │ ├── JDKInvocationHandler.java
   │ │ └── JDKProxy.java
   │ ├── impl
   │ │ └── CacheServiceImpl.java
   │ └── CacheService.java
   └── test
   └── java
   └── org.itstack.demo.design.test
   └── ApiTest.java
   「抽象工厂模型结构」

抽象工厂模型结构
工程中涉及的部分核心功能代码，如下；
ICacheAdapter，定义了适配接口，分别包装两个集群中差异化的接口名称。EGMCacheAdapter、IIRCacheAdapter
JDKProxy、JDKInvocationHandler，是代理类的定义和实现，这部分也就是抽象工厂的另外一种实现方式。通过这样的方式可以很好的把原有操作Redis的方法进行代理操作，通过控制不同的入参对象，控制缓存的使用。那么接下来会分别讲解几个类的具体实现。

2. 代码实现
   2.1 定义适配接口

public interface ICacheAdapter {

    String get(String key);

    void set(String key, String value);

    void set(String key, String value, long timeout, TimeUnit timeUnit);

    void del(String key);

}

这个类的主要作用是让所有集群的提供方，能在统一的方法名称下进行操作。也方面后续的拓展。
2.2 实现集群使用服务
「EGMCacheAdapter」

public class EGMCacheAdapter implements ICacheAdapter {

    private EGM egm = new EGM();

    public String get(String key) {
        return egm.gain(key);
    }

    public void set(String key, String value) {
        egm.set(key, value);
    }

    public void set(String key, String value, long timeout, TimeUnit timeUnit) {
        egm.setEx(key, value, timeout, timeUnit);
    }

    public void del(String key) {
        egm.delete(key);
    }
}
「IIRCacheAdapter」

public class IIRCacheAdapter implements ICacheAdapter {

    private IIR iir = new IIR();

    public String get(String key) {
        return iir.get(key);
    }

    public void set(String key, String value) {
        iir.set(key, value);
    }

    public void set(String key, String value, long timeout, TimeUnit timeUnit) {
        iir.setExpire(key, value, timeout, timeUnit);
    }

    public void del(String key) {
        iir.del(key);
    }

}

以上两个实现都非常容易，在统一方法名下进行包装。
2.3 定义抽象工程代理类和实现
「JDKProxy」

public static <T> T getProxy(Class<T> interfaceClass, ICacheAdapter cacheAdapter) throws Exception {
    InvocationHandler handler = new JDKInvocationHandler(cacheAdapter);
    ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
    Class<?>[] classes = interfaceClass.getInterfaces();
    return (T) Proxy.newProxyInstance(classLoader, new Class[]{classes[0]}, handler);
}

这里主要的作用就是完成代理类，同时对于使用哪个集群有外部通过入参进行传递。
「JDKInvocationHandler」

public class JDKInvocationHandler implements InvocationHandler {

    private ICacheAdapter cacheAdapter;

    public JDKInvocationHandler(ICacheAdapter cacheAdapter) {
        this.cacheAdapter = cacheAdapter;
    }

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        return ICacheAdapter.class.getMethod(method.getName(), ClassLoaderUtils.getClazzByArgs(args)).invoke(cacheAdapter, args);
    }

}

在代理类的实现中其实也非常简单，通过穿透进来的集群服务进行方法操作。
另外在invoke中通过使用获取方法名称反射方式，调用对应的方法功能，也就简化了整体的使用。
到这我们就已经将整体的功能实现完成了，关于抽象工厂这部分也可以使用非代理的方式进行实现。
2. 测试验证
「编写测试类：」

@Test
public void test_CacheService() throws Exception {
    CacheService proxy_EGM = JDKProxy.getProxy(CacheServiceImpl.class, new EGMCacheAdapter());
    proxy_EGM.set("user_name_01","小傅哥");
    String val01 = proxy_EGM.get("user_name_01");
    System.out.println(val01);
    
    CacheService proxy_IIR = JDKProxy.getProxy(CacheServiceImpl.class, new IIRCacheAdapter());
    proxy_IIR.set("user_name_01","小傅哥");
    String val02 = proxy_IIR.get("user_name_01");
    System.out.println(val02);
}

在测试的代码中通过传入不同的集群类型，就可以调用不同的集群下的方法。JDKProxy.getProxy(CacheServiceImpl.class, new EGMCacheAdapter());
如果后续有扩展的需求，也可以按照这样的类型方式进行补充，同时对于改造上来说并没有改动原来的方法，降低了修改成本。
「结果：」

23:07:06.953 [main] INFO  org.itstack.demo.design.matter.EGM - EGM写入数据 key：user_name_01 val：小傅哥
23:07:06.956 [main] INFO  org.itstack.demo.design.matter.EGM - EGM获取数据 key：user_name_01
测试结果：小傅哥
23:07:06.957 [main] INFO  org.itstack.demo.design.matter.IIR - IIR写入数据 key：user_name_01 val：小傅哥
23:07:06.957 [main] INFO  org.itstack.demo.design.matter.IIR - IIR获取数据 key：user_name_01
测试结果：小傅哥

Process finished with exit code 0

运行结果正常，这样的代码满足了这次拓展的需求，同时你的技术能力也给老板留下了深刻的印象。
研发自我能力的提升远不是外接的压力就是编写一坨坨代码的接口，如果你已经熟练了很多技能，那么可以在即使紧急的情况下，也能做出完善的方案。
七、总结
抽象工厂模式，所要解决的问题就是在一个产品族，存在多个不同类型的产品(Redis集群、操作系统)情况下，接口选择的问题。而这种场景在业务开发中也是非常多见的，只不过可能有时候没有将它们抽象化出来。
你的代码只是被ifelse埋上了！当你知道什么场景下何时可以被抽象工程优化代码，那么你的代码层级结构以及满足业务需求上，都可以得到很好的完成功能实现并提升扩展性和优雅度。
那么这个设计模式满足了；单一职责、开闭原则、解耦等优点，但如果说随着业务的不断拓展，可能会造成类实现上的复杂度。但也可以说算不上缺点，因为可以随着其他设计方式的引入和代理类以及自动生成加载的方式降低此项缺点。