[设计原则4] 依赖倒置原则--架构重用基础



        定义：要依赖于抽象，细节要依赖于抽象，抽象不要依赖于细节，或者说高层模块不应该依赖于底层模块，两个都应该依赖于抽象。

        依赖倒置原则是架构重用的基础。面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。因此在面向过程的编程时代，基本上没有公共的可重用架构，最多也就是一些公共的API供开发者调用。面向过程编程有时为了解决这种问题，通常引入回调函数来解决，但是回调函数相对面向对象的多态等特性来说有一定的局限性。

        面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。

        面向过程（非依赖倒置的情况）：比如现在有个服务器程序，底层通信框架收到客户端的消息后，根据消息类型，来调用不同的功能函数，但是如果需要增加或者修改某个功能时，都会影响到底层通信框架的修改，从而倒置通信框架无法稳定，更无法作为多个软件系统的基础框架。

        依赖注入模式：依赖注入模式就是根据依赖倒置原则所引入的，如果我们在设计底层通信框架的时候，设计一个MsgHandler接口类，提供一个Handle接口，其他的功能函数改为从这个接口类继承出多个功能类，同时实现各自的Handle函数，然后再通过抽象工厂等模式如HandlerFactory，创建根据消息类型创建这些功能类，这样底层通信模块接到消息时，只需要根据消息类型创建出不同的功能对象，然后调用该对象的Handle接口，当各功能扩展增加或者功能修改时，底层的通信框架都无需修改，从而实现了框架重用的目的。

        依赖倒置也不是完全没有缺点：

        1）依赖倒置后，会增加一些本来不需要的接口；

        2）一般人们在看代码时，比较容易一个流程从头到尾的读，比较有连续性，特别是对于一些新手，以及在代码没有多少文档的情况下。而依赖倒置打破了这个连续性，此时通常需要有些必要的文档，如类结构图以及序列图来帮助其他人员理解你的设计；

        所以所有的实现和抽象都依赖与抽象的话，势必导致过得的抽象接口，从而增加了代码的复杂度，这就是我们经常讲的过度设计。通常对于一些比较稳定的类，并且也不会有太多复杂的功能扩展，一般情况下都直接依赖与实现，如谁也不会为一个string类去抽象一堆接口。

        因此依赖倒置原则应该更确切的讲是稳定依赖原则，即我们在编程的时候，要依赖比较稳定的模块，如果这个模块不稳定，则需要想办法进行抽象，让其他模块不再依赖那些不稳定模块。