小菜学设计模式——依赖倒转原则

    背景

    本文标题为什么叫小菜学习设计模式，原因是本文内容主要是学习《大话设计模式》时的笔记摘要部分，当然，并不是记录书中小菜的学习过程，这个完全没有意义，而是指本人学习设计模式的成长之旅。

    真诚的希望自己能够从一名小菜成长为一名大鸟！

    编写的程序应该满足：

    1）可维护

    2）可扩展

    3）可复用

    4）够灵活

    废话少说，言归正传，设计模式原则之：依赖倒转原则

    书面理解

    依赖倒转原则：

    A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

    B.抽象不应该依赖于具体，具体应该依赖于抽象。

    简单的说就是要求对抽象进行编程，不要对实现（过程）进行编程，这样就降低了调用者（client）与实现者（operation）模块间的耦合。

    抽象的稳定性决定了系统的稳定性，因为抽象是不变的，依赖于抽象是面向对象设计的精髓，也是依赖倒置原则的核心。

    面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。

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

    个人的理解

    依赖倒转原则：对于两个模块，如果二者之间存在耦合关系，那么尽量使用面向接口编程，即调用者只调用接口的方法，关于接口的具体是谁如何实现，调用者无需关心；实现者只关系接口的定义，关于谁要调用这个接口，实现者无需关心。那么这里高层次模块就是调用者，低层次模块就是是实现者，接口就是二者联系的桥梁。抽象不应该依赖于具体，然而具体实现者则要完全按照接口的定义去实现，否则，接口的定义将会失去意义。

    关于面向过程编程，就好比如过去的C语言，他们是把所有需要的函数都实现在函数库里面，一旦某个模块需要使用的时候，带调用这个库里面的那个函数，看似程序毫无破绽，实际上他却限制了程序的扩展，因为一个函数只是告诉调用者我会完成某个功能，这个功能已经写死了，不能扩展了，除非你去修改那个函数的代码，明显违背了开发封闭原则。然而，面向对象编程则不是，调用者调用的是接口的方法，然而接口的具体实现用户是可以自定义的，只要按照接口的意思，可以写出各种不同的策略，那么就是面向接口编程。

    现实中的例子，比如电脑模块之间的依赖使用，一块主板提供了各种接口（插孔），供CPU、内存条、硬、光驱等，如果A品牌内存条坏了，可以丢掉，买一个B品牌的内存条，继续插入主板使用，不会说内存条坏了，就必须连主板都要更换才能使用，因为主板依赖的是内存条插槽接口，内存条同样依赖这个插槽接口，所以内存条与主板是胡不影响的。

    秦始皇统一车轴轮，也就是这个道理。