依赖倒转原则学习后感想

学习地址

gitbook--设计模式 java 版

个人见解

ps：个人见解，如果错误，望请指出。

Dependency Inversion Principle（依赖倒转原则）：抽象不应该依赖于细节，细节应该依赖于抽象。即面向接口编程。

什么意思呢？第一次开到这个原则完全不知道是什么意思，在最近工作的时候，听组里面的架构师提起过，再回来看看，结合自己最近的工作内容，渐渐对这个原则有了一些理解。

假设有一个这样一个场景，业务系统将消息发送给平台，平台在将消息落地持久化后告诉业务系统我收到消息了，然后业务系统就去做其他事情了。当平台在过一会后，将消息发送到消息的接受者后，需要回调业务系统，告诉业务系统消息发送成功，可以进新相关的业务处理。

对于回调这一部分，我们可以这么实现

public class CallBack {
      public void messageAfterSent() {
          // 业务处理
      }
}

public class CallBackController {
     
      private CallBack callback;

      // callback 的 set 和 get 方法，注入。

      public void statusAware(){
            .....
            callback.messageAfterSent
            ....
      }
}

业务系统实现这样的一个回调类，在收到平台的回调的时候，执行CallBack中的messageAfterSent就行。这样就能实现功能了，但是如果不同类型的消息对应的回调处理不同的时候，我们也可以在messageAfterSent中加入 if...else 来进行业务处理，但是这不符合开闭原则。

思考上面的场景，其实我们违反了依赖倒转原则，细节（CallBackController）依赖了细节（CallBack）。细节应该依赖于抽象，为了能够让不同类型的消息有自己的回调，应该将 CallBack 抽象，将消息回调抽象出来为一个接口，让细节（CallBackController）依赖于抽象（CallBack接口），这样在增加不同类型的消息的时候，只需要重新写一个类实现接口，加入到细节（CallBackController）中即可。

public interface ICallBack {
      void messageAfterSent();
}

public class CallBackController {
     
      private List callback;

      // callback 的 set 和 get 方法，注入。

      public void statusAware(){
            .....
            CallBackUtil.execCallBack(callback);
            ....
      }
}

这样之后，只要新增一类消息，我们只需要实现他自己对应的ICallBack，然后在注入到CallBackController中就好了。