设计模式学习

设计模式的6大设计原则

• 单一职责原则       

           单一职责原则：Simple Responsibility Principle  简称 SRP

                这个原则比较难定义，可是也是比较好理解的。简单来讲就是接口要作到职责分明，什么该作什么不应作要分清楚。

                单一职责的好处

                        类的复杂性下降，实现什么的职责都有清晰明确的定义

                        可读性提升，复杂性下降

                        可维护性提升，可读性提供

                        更变引发的风险下降

• 里氏替换原则

           里氏替换原则  (Liskov Substitution Principle , LSP)   

          第一种定义：若是对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的全部程序P在全部的对象o1都替换成o2时，程序P的行为没有发生变化，那么S是T的子类型。

          第二种定义：全部引用基类的地方必须能透明地使用其子类的对象。

          官方的说明太官方了。。。简单来讲，只要父类能出现的地方子类就能够出现，并且替换成子类也不会产生任何的错误或者异常。（给我最直接的感受就是里氏替换原则就是为JAVA里的继承定义了一个规范，

          在JAVA里的继承，子类能够强制转换成父类，父类不能强制转换成子类）

• 依赖倒置原则

          依赖倒置原则 （Dependence Inversion Principle , DIP） 

          依赖倒置原则原始定义是 ： High level modules should not depend upon low level modules . Both should depend upon abstractions . Abstractions should not depend upon details . Details should depend upon  abstractions.

          很容易理解，高层模块不该该依赖底层模块，二者都应该依赖其抽象，抽象不该该依赖细节，细节应该依赖抽象。从JAVA的方向看，模块间的依赖经过抽象过程，实现类之间不发生直接的依赖关系，其依赖关系   是经过接口和抽象产生的；接口或抽象类不依赖实现类，实现类依赖接口或抽象类。（这不就是面对接口编程的精髓吗？）

         采用依赖倒置原则的本质就是经过抽象（接口或抽象类）使各个类或模块的实现彼此独立，能够减小类之间的耦合性，提升系统的稳定性，下降并行开发引发的风险，提升代码的可读性和可维护性。

 

• 接口隔离原则

          接口隔离原则第一种定义：客户端不该该依赖它不须要的接口，第二种定义：类间的依赖关系应该创建在最小的接口上。简单的来讲就是创建接口要尽可能细化，同时接口中的方法尽可能少。看起来与单一职责原则很  像，其实两个原则的审视角度不相同，单一职责要求的是类和接口的职责单一，注重的是职责，是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少（拆分接口时必须知足单一职责原则），接口要高内聚，定制服务，接口设计是有限度的（并非越小越好，要根据实情去设计）

• 迪米特法则

         迪米特法则（Law of Demeter , LoD）也称为最少知识原则

         定义：一个对象应该对其余对象有最少的了解，通俗地说，一个类应该对本身须要耦合或调用的类知道得最少（被调用的类逻辑多复杂跟你不要紧，你只是调用它提供的方法而已）

         迪米特法则的核心观念是类间解耦，弱耦合，只有弱耦合了之后，类的复用率才能够提升

• 开闭原则

         开闭原则定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。（通俗讲一个程序应该经过扩展来实现变化，而不是经过修改已存在的代码来实现变化）