起

插件化是一种利用分治思想对项目进行降维开发的思路。当然组件化也能起到降维和分治的目的，但是组件化这个词已经是教科书上都有提及的概念了，大多数应用开发中遇到的问题都是基于插件化的，因为插件化对比组件化增加了热插拔的功能，也就是说使用插件化框架能够实现应用的动态更新。

近期某互联网公司发布消息说要开源自己的插件框架源码。虽然插件化的概念在安卓开发领域已经火了有些日子了，但始终没有发现一款大家都满意的、普适的插件框架。目前已知在研究插件框架的公司已经超过了5个，所以对要开源的这款也不置可否，但不管使用哪种类型的插件框架，抑或只是使用组件化对项目进行切分，都会遇到题目中所描述的问题模块间接口设计。

承

既然要按插件化或组件化把项目分成多个模块，那么无可避免地需要多个模块之间进行数据或逻辑交互。按照设计模式中的开闭原则，大家第一想法多半是暴露服务接口、封闭服务实现。于是给服务新加了以下接口：

public interface Service {
  int method();
}

为了在各个插件中方便地注册或获取服务，在插件框架中需要一个统一管理服务的机制，类似于：

public class PluginFramework {
  public static void registerService(String key, Object service) {
    /* todo */
  }

  public static void unregisterService(String key) {
    /* todo */
  }

  public static Object getService(String key) {
    return null;
    /* todo */
  }
}

当在某个插件里需要调用该服务时，首先你需要从插件框架提供的统一服务管理机制中获取该服务，然后才能调用该服务提供的方法（注意此时需要对获取的服务进行判空保护），类似于：

public class Test {
  public void function() {
    Service service = (Service) PluginFramework.getService("key");
    if (service != null) {
      service.method();
    }
  }
}

以上，一个标准的符合设计模式思想的模块间接口就设计好了。

转

既然项目分成了多个模块，我们就希望各个模块之间共有的逻辑尽可能少，但实际开发中往往会遇到一些通用性很强、出现频率很高又非常重要的逻辑穿插整个项目，我们既不能删掉它，又找不到很好的方法把这块逻辑封装到一个单独的模块里，但是它出现的频率很高，而且每出现一次都需要三步操作（1.获取/2.判空/3.调用）。极端情况下，一个n行可以实现的逻辑，我们就需要3*n的代码量去实现，这在快速迭代的需求开发中是很影响程序猿的编码速度的，同时业务代码的可读性可见一斑。基于以上考虑，我在项目中对模块间的接口进行了以下尝试：

public class Service {
  private static Service service;

  private static Service getService() {
    if (service == null) {
      service = new Service();
    }
    return service;
  }

  protected int methodImpl() {
    return 0;
  }

  public static int method() {
    return getService().methodImpl();
  }
}

将抽象的接口和接口的默认实现完全耦合在一起，这样即使提供服务的一方没有及时注册服务，使用服务的一方也可以随时调用服务的方法，完全不必考虑空指针问题，因为我们有一个默认的实现。此时该服务的注册和反注册是在服务类内部实现的，也就不需要跟PluginFramework有任何牵连了。

public class Service {
  private static Service service;

  protected final void register() {
    service = this;
  }

  protected final void unregister() {
    service = null;
  }
}

注意register和unregister方法是protected final的，如果要进行注册和反注册操作的话，业务方必须实现一个子类集成Service，然后在子类内部调用register方法，这在一定程度上可以避免业务方误操作导致已注册服务被覆盖的问题。

此时业务方调用服务提供的方法时，代码就成了这个样子：

public class Test {
  public void function() {
    Service.method();
  }
}

细心的同学会发现，这种接口设计方式并不符合开放接口、封闭实现的原则，还将接口、默认实现、服务管理逻辑完全耦合在了一起，这就是我之所以把它称之为反设计模式的原因。

合

教科书上说：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性，然后才有了6原则、23模式。在实际的结构设计中，记性好的同学可能会首选23种模式为参考，稍微懒点儿的同学大概就只记得6原则了，像我这种7秒就什么都不记得的，只好什么都不管了。某伟人曾经说过，不管黑猫白猫抓到老鼠就是好猫，所以私以为只要设计出来的代码好使好用好看，就不要考虑什么原则什么模式了吧。

如果要强行站队的话，本文提到的这种反设计模式的接口设计思路跟迪米特法则能靠上边儿吧，不管怎么说业务方调用的时候方便了，不管你有没有实现有没有注册都可以直接调用服务的方法，提供服务的系统模块的确更加独立了呢~