通过实例演变的过程,我们的软件设计要符合设计模式的几个原则
1. 开闭原则
软件实体(class,模块,功能或业务,微服务etc)对修改关闭,对拓展开放。
抽象构建框架,实现拓展细节。
面向抽象编程,而不是面向具体实现编程。因为抽象相对来说是稳定的,让类去依赖于固定的抽象,所有对于修改来说就是封闭的,通过OO的继承,多态机制就可以实现对抽象体的拓展,通过重写改变固有的方法或者实现新的拓展方法。
2. 依赖倒置原则
高层实现不应该直接依赖于低层实现,它们应该依赖于共同的抽象(低层接口)。
越基础的模块发生变化影响的范围越大。
3. 单一职责原则
不要存在多于一个导致类变更的原因。
一个类只负责一种职责,从类的方法上来考虑就是一个类可能存在多个方法,但这些方法的功能类似,都是为了完成同一种职责。
适用于类、接口、方法等,减少复杂度、提高可读性和可维护性。
4. 接口隔离原则
该原则针对接口。要求在适度该原则的情况下,尽量细化接口(接口中的方法尽量少,完成的功能尽量单一),过大的接口不利于维护,过小的接口会提高系统的复杂性,也不利于后期维护。
一个类不应该实现不需要的接口方法。
细粒度可组装,粗粒度不可拆分。
高内聚低耦合:高内聚要求减少对外交互,使接口中最少的方法去完成最多的事情。低耦合要求降低依赖关系。
5. 里氏替换原则
当两个具体类关系违反里氏代换原则时,一种办法是抽象出一个基类,作为这两个类的父类,一种是应用组合聚合关系建立关系。不要为了使用某些类的方法(功能)而滥用继承。
6. 迪米特原则
最少知道原则,一个对象应对其他对象保持最少的了解。
减少类之间不必要的依赖,尽量降低类之间的耦合,提高类的复用率。
适当使用访问权限。
该原则要求只和朋友交流,不和陌生人交流。那么对于一个类来说,哪些是朋友?哪些是陌生人?
朋友
对象组合
对象依赖。输入参数,输出返回值。
陌生人
方法体内中的类