【设计模式】——六原则（二）

此文章紧接上文，欢迎阅读访问【设计模式】——六原则（一）

依赖倒转原则

    依赖倒转：高层模块不应该依赖底层模块。两个都应该依赖抽象。抽象不能依赖细节，细节应该依赖抽象。说白了就是针对接口的编程，不是针对实现！

    解释：依赖倒转原则是面向对象编程设计的标志，用哪种语言编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序所有的依赖关系都终止于抽象类或者接口。高层模块和底层模块都是可以相当于两个具体类，如果两个类之前存在依赖关系，假如底层模块的修改就是严重影响到高层模块，这种情况肯定不是我们想要的。所以让他们之间不是相互依赖而是依赖于抽象类和接口。

    实例：在做机房收费系统的时候，用到了大量的select语句，但是这些语句的实现都依赖于模块中编写好的ExecuteSQL模块。（关系如图1）

                

如果模块修改，或者损坏涉及到数据库语言的地方都可能不能使用，这样的后果就是整个机房收费系统都无法正常使用，如果是一个很大型的项目，损失肯定是巨大的。为了避免这种情况，可以让高层模块和底层模块都去依赖于接口或抽象类（关系如图2），这样两者则不再互相干扰。

              

迪米特法则

    迪米特法则：如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三方转发这个调用。

    解释：这个原则根本的思想是强调类之间的松耦合，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对关系造成波及。上一个依赖倒转原则中强调面向接口编程，不要面向实现编程。其实也是这个意思，高层模块和底层模块之间的耦合度很高，因为高层模块需要调用底层模块的方法，两者强耦合在一起一损俱损，这种现象在编程的世界里尽可能的不出现！

    实例：书本上例子因为菜鸟不认识IT部的小李，造成一天时间的损失，他们之间存在关系如图3

             

其实小李也是IT部的完全可以让小李帮助菜鸟完成电脑的配置，但是他们之间不认识。之所以出现这种情况，是因为没有人管理，没人知道他们是否有空。实际上小张和小李都属于IT部这个大的抽象类，如果菜鸟直接打电话到IT部，不管认不认识人，他们一定会想办法解决的。IT部就相当于抽象类或接口，也就是此原则中的第三者转发者。（如图4）

          

合成/聚合复用原则

    合成/聚合复用原则：尽量使用合成/聚合尽量不要使用类继承

    何为合成/聚合？请进入了解【C#】——四种关系

    解释：对象的继承关系是在编译时就定义好了，所以无法在运行是改变从父类继承的实现。子类的实现与它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这样依赖关系限制了复用性。优先使用对象的合成/聚合将有助于我们保持每个类被封装，并被集中在单个任务上，这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

    实例：定义父类为手机品牌，有多个手机品牌，然后每个手机品牌下面有多个与之相匹配的软件，想象这张UML图会有多大。。

    

结合我们的手机想想，其实每个软件都是通用的，不存在这种有一个手机品牌就有一系列相关的软件和其匹配的这种现象。通过我们上面的法则再来画图，看看是不是很方便了。

  

总结

    虽然只是几个简单的设计原则，但是真的感受到设计模式的精彩，不得不感叹智慧就这样的伟大。让我们站在创造这些原则以及这些模式的巨人的肩膀上，仔细体会其中的精髓，在程序的世界里创造，同时用它们去亲手改变我们的未来！

    本人菜鸟一只，若有理解不对之处，请大神们及时指出，不胜感激！