圈套！都是圈套！

圈套者，圈于套路也！也就是说你的思维被局限在已有的套路里，难以发散开来，自然就容易错过更优雅的结构设计。猫捉老鼠是大家都认可的道理，但是所有的猫都捉老鼠么？见到老鼠吓得半死的怂猫比比皆是啊！那么本文要指出的道理是什么呢？敲黑板_划重点 ==开放接口，封闭实现== 继续划重点~ ==但这个道理不是绝对的==

让人不爽的圈套！

开放接口，封闭实现，也就是说我们需要声明一个接口，然后在一个插件中提供该接口的实现，此时我们并不能确认实现该接口的插件是否正在运行。然后问题来了，你提供一个接口让我用，我用的时候还要先确认一下接口有没有实现？有没有搞错？你向我提供服务，我当然希望可以直接调用了！这下好了，我调用之前还得判断有没有注册实现，你这个接口设计的咋就那么不让人省心呢？不爽归不爽，让我们用代码看下这个不让人省心的接口是怎么样的套路哈~

1. 插件框架

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 */
  }
}

2. 声明接口(公共jar包)

public interface Service {
  int method();
}

3.接口调用

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

更优雅的实现！

优雅你好！圈套再见！ 我们来简单分析一下不省心的代码为什么会那么让人不省心。有什么分析的呢？不省心就是不省心，人前人后两个样，有注册实现的时候随便调，没注册实现的时候全是空指针。那有什么好的措施弥补一下呢？加一个默认的实现就行了，这样无论如何都不会走到没注册实现的逻辑上，总结一下就是：我们不修复没注册实现的逻辑，我们把没注册实现的逻辑删了。X D

我们用代码来看一下优雅的接口是怎么实现的吧~

1. 接口声明(公共jar包)

public class Service {
  private static Service service;

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

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

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

  protected int methodImpl() {
    return 0;
  }

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

2.接口调用

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

开放封闭原则其实并不是针对接口和实现的，而是针对变与不变的。对于总是变化的接口实现，我们当然需要封闭到提供服务的插件中；对于几乎不变的接口，我们当然需要开放到公共的jar包中；但是对于默认的接口实现，在服务设计之初几乎就定下来不会变的默认实现，是没有必要封闭到提供服务的插件中的，完全可以开放在公共的jar包中！

利益相关

作者的另一篇文章，同时也是本文的另一个版本：插件化框架下模块间接口新尝试（一种反设计模式的接口设计）