学习地址
个人见解
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<ICallBack> callback;
// callback 的 set 和 get 方法，注入。
public void statusAware(){
.....
CallBackUtil.execCallBack(callback);
....
}
}
这样之后，只要新增一类消息，我们只需要实现他自己对应的ICallBack，然后在注入到CallBackController中就好了。
