设计模式 之 6大原则

**

设计模式 之 6大原则

**
原则一：单一职责原则
定义：应该有且只有一个原因引起类的变更。
优点：1.类的复杂性降低，实现什么职责都有清晰明确的定义。
2.复杂性降低，可读性提高、可维护性提高
3.变更引起的风险降低
注意：单一职责原则提出了一个编写程序的标准，用‘职责’或‘变化原因’来衡量接口或类设计的是否优良，但是‘职责’和‘变化原因’都是不可度量的，因项目而异，因环境而异。
自己理解：
单一职责原则实际上就是一个类只负责一个职责，只有该职责改变时，才会影响到该类。例如一部手机，开关机是一个职责，通话是一个职责，上网是一个职责等等，需要修改通话的一些设置时，就只需要修改负责通话的类，其他的类不需要改动，反过来说，该类改动时，只有通话的功能发生变化才可以。当然，职责需要根据具体情况来划分，可以把开机划分成一个职责，关机划分成一个职责，这时候手机这个程序实际就有四个职责。职责划分的越细，类就越多，职责越细，类越多，代码虽然清晰，但太琐碎，不利于维护。所以需要根据具体情况进行具体分析。
原则二：里式替换原则
定义：只要父类能出现的地方，子类就可以出现，且替换成子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类，反之不成立：有子类出现的地方，父类不一定能使用。
优点：增强系统的健壮性
里式替换原则为继承定义了一个规范：
1.子类必须完全实现父类的方法
2.子类可以有自己的个性，即里式替换原则可以正着用，不能反着用
3.覆盖或实现父类的方法时，入参可以被放大(调用父类时执行子类，里式替换后，调用子类时还是执行子类)
4.覆写或实现父类的方法时输出结果可以被缩小
自己理解：里式替换原则就是实现松耦合，即通过接口或抽象类，当需求变更或扩展时，将改动量优化到最小。
原则三：依赖倒置原则
依赖倒置原则在java中体现：
1.模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
2.接口或抽象类不依赖于实现类
3.实现类依赖接口或抽象类
对象的依赖关系传递方式：
1.构造函数传递依赖对象(构造函数中有参数，调用构造函数时传对象参数)
2.setter方法传递依赖对象(调用set方法时传递对象参数)
3.接口声明依赖对象(接口方法中声明依赖对象，即接口注入)
优点：降低模块之间的耦合性，降低并行开发的风险
自己理解：该原则的本质就是通过接口或抽象类，使个各类或模块之间实现独立，互不影响，实现松耦合。优点是将并行开发的影响降至最低，还可以减少后期扩展和维护的成本。
原则四：接口隔离原则
定义：建立单一接口，不要建立臃肿庞大的接口
接口隔离原则是对接口进行规范约束：
1.接口要尽量小(根据接口隔离原则拆分接口时，必须满足单一职责原则)
2.接口要高内聚(要求在接口中尽量少公布public方法)
3.定制服务(根据项目需求，需要为某个事物提供一个定制的需求时，只提供访问者需要的方法)
4.接口细化是有限度的。
单一职责原则和接口隔离原则区别：单一职责原则要求的是类和接口的职责单一，注重的是职责，这是业务逻辑上的划分，而隔离原则要求接口的方法尽量少。
自己理解：该原则只是为接口或抽象类开发提供一个规范：接口里面的方法尽量少，实现松耦合，方便以后的扩展和修改。但接口越多，维护成本越大。
原则五：迪米特法则(最少知识原则)
定义：一个对象应该对其他对象有最少的了解。
自己理解：一个类只与朋友类交流(朋友类：出现在成员变量、方法中的入参或返回参数的类)。对其他类不需要知道，通过朋友类来依赖其他类，即朋友类中的public方法要尽量少，在方法内去调用其他的方法或类。
迪米特法则的核心观念就是类间的解耦-弱耦合，只有弱耦合以后，类的复用才可以提高，其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。
原则六：开闭原则
定义：一个软件实体，如类、模块、函数等应该对扩展开放，对修改关闭，即应该通过扩展实现变化，而不是通过修改已有代码实现变化。
软件实体：包括项目或软件产品中按照一定的逻辑规则划分的模块，抽象和类、方法。
注意：开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，底层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。
优点：1.减少对测试的影响(需求修改后，之进行扩展，测试人员不需要测试原来已有的功能)
2.可以提高复用性
3.提高可维护性
4.面向对象的开发要求
如何使用：1.抽象约束(通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放)
2.配置参数控制模块行为
3.制定项目章程
4.封装变化(将相同的变化封装到一个接口或抽象类中。将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中)
自己理解：开闭原则指代码开发要尽量的高内聚、低耦合，当需求变化时，修改代码要对原有功能影响尽量小，所以对原有代码尽量不做修改，只是在原有基础上进行扩展，便于维护人员进行维护
6个原则结合使用
优点：建立稳定、灵活、健壮的设计
注意的问题：1.开闭原则只是一个原则，要根据实际情况来开发，不应该局限于是否符合原则
2.项目章程很重要
3.要预知变化

这篇文章只是记录了自己对6个原则的认识和理解，有不足之处，请告知。