圈套！都是圈套！
圈套者，圈于套路也！也就是说你的思维被局限在已有的套路里，难以发散开来，自然就容易错过更优雅的结构设计。猫捉老鼠是大家都认可的道理，但是所有的猫都捉老鼠么？见到老鼠吓得半死的怂猫比比皆是啊！那么本文要指出的道理是什么呢？敲黑板划重点 ==开放接口，封闭实现== 继续划重点~ ==但这个道理不是绝对的==
让人不爽的圈套！
开放接口，封闭实现，也就是说我们需要声明一个接口，然后在一个插件中提供该接口的实现，此时我们并不能确认实现该接口的插件是否正在运行。然后问题来了，你提供一个接口让我用，我用的时候还要先确认一下接口有没有实现？有没有搞错？你向我提供服务，我当然希望可以直接调用了！这下好了，我调用之前还得判断有没有注册实现，你这个接口设计的咋就那么不让人省心呢？不爽归不爽，让我们用代码看下这个不让人省心的接口是怎么样的套路哈~
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包中！
利益相关
作者的另一篇文章，同时也是本文的另一个版本：插件化框架下模块间接口新尝试（一种反设计模式的接口设计）
