设计模式-七大原则

设计模式的的目的：

1）代码重用性（相同工单的代码，不用多次编写）

2）可读性（即编程规范性，便于理解）

3）可扩展性（需要增加新的功能时，非常方便）

4）可靠性（当增加新的功能后，对原先的功能不影响）

5）使程序呈现高内聚，低耦合的特性

设计模式一定符合下面几个原则。也存在违背下面某些法则

1、单一职责

对类来说，即一个类应该只负责一项职责

1.1、降低类的复杂度，一个类只负责一项职责

1.2、提高雷的可读性，可维护性

1.3、减低变更引起的风险

2、接口隔离原则 

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

（可用接口作为参数，传入参数时，用实现该接口的类传参数）

3、依赖倒转原则

3.1、高层模块（客户端）不应该依赖底层模块（实现类），二者都应该依赖起抽象

3.2、抽象不应该依赖细节，细节应该依赖抽象

3.3、依赖倒转的中心思想是面向接口编程

3.4、使用接口或者抽象类的目的是制定好规范 

（例如：A客户端依赖去直接依赖实现类。导致增加新类，需要改变依赖和被依赖的。当中间有抽象，A客户端依赖抽象接口。实现类实现抽象接口。当有新类。客户端不需要改变。新增类实现抽象接口。客户端用接口作为参数。实现类作为值传参）

4、里氏替换原则

4.1、所有引用基类的地方必须能透明的使用其子类的对象

4.2、在使用继承时，遵循里氏替换原则，在子类中经量不要重写父类的方法

4.3、继承实际上让两个类耦合性增强了，在使得的情况下。可以通过聚合，组合，依赖来解决问题

(例如：A,B两个类，原先是A基础B。现在改为新增一个基础类C ，A基础C，B也基础C 。如果A需要B 可以通过聚合或者组合)

5、开闭原则

5.1、一个软件实体如类，模块和函数应该对扩展开发，对修改关闭，用抽象构造框架，用实现扩展细节（功能扩展的时候，类可以增加，但是实现方法代码不变）

5.2、当软件需要变化时，经量通过扩展软件实体的行为来实现变化，而不是通过已有代码来实现变化

(例如：如果逻辑有多层if判断。且增加新功能需要增加if 这种就是违反开闭原则。解决；各个类实现抽象，抽象作为参数，实现参数的类作为传值)

6、迪米特法则

6.1、一个对象应该对其他对象保持最小的了解

6.2、类与类关系越密切，耦合度越大

6.3、执与直接的朋友通信

也就是说，对于依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息

直接朋友：类中出现成员变量，方法参数，方法返回值中的类称为直接朋友

而出现在局部变量中的类不是直接朋友

也就是说，陌生的类最好不要以局部变量的形式出现在类的内部

例如：B以局部变量出现在A类中。且在A类中写B自己的逻辑代码。这个时候就违反迪米特法则。

应该把这部分代码在B类中实现。对外提供public方法。在A类调用

7、合成复用原则

7.1、原则尽量使用合成/聚合的方式，而不是使用继承

设计原则核心：

1>把需要变化的独立出来，不要和那些不需要变化的代码混在一起

2>针对接口编程，而不是针对实现编程
3>为了交互对象直接的松耦合设计