设计模式的六大原则
一、开闭原则(Open-Closed-Principle)
核心:一个软件实体应当对拓展开放,对修改关闭。即:软件实体应尽量在不修改原有代码的情况下进行拓展
二、里氏代换原则(Liskow-Substitution-Principle)
子类可以扩展父类的功能,但不能改变原有父类的功能;(本质其实就是c++的多态)
(目的:增强程序的健壮性)实际项目中,每个子类对应不同的业务含义,使父类作为参数,传递不同的子类完成不同的业务逻辑。
一个软件实体如果使用的是一个父类,那么一定适用于其子类,而且他察觉不出父类对象和子类对象的区别。也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化。简单地说,子类型必须能够替换掉它们的父类型。
三、依赖倒置原则(dependence inversion principle)
面向接口编程;(通过接口作为参数实现应用场景)
抽象就是接口或者抽象类,细节就是实现类
含义:
上层模块不应该依赖下层模块,两者应依赖其抽象;
抽象不应该依赖细节,细节应该依赖抽象;
通俗点就是说变量或者传参数,尽量使用抽象类,或者接口;
【接口负责定义public属性和方法,并且申明与其他对象依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑
四、单一职责原则(Single-Responsibility-Principle)
一个类或者一个方法只负责一项职责,尽量做到类的只有一个行为原因引起变化;
a、业务对象(BO business object)、业务逻辑(BL business logic)拆分;
五、接口隔离原则(Interface-Segregation-Principle)
建立单一接口;(扩展为类也是一种接口,一切皆接口)
定义:
a.客户端不应该依赖它不需要的接口;
b.类之间依赖关系应该建立在最小的接口上;
简单理解:复杂的接口,根据业务拆分成多个简单接口;(对于有些业务的拆分多看看适配器的应用)
【接口的设计粒度越小,系统越灵活,但是灵活的同时结构复杂性提高,开发难度也会变大,维护性降低】
六、迪米特法则(Law-Of-Demeter)
最少知道原则,尽量降低类与类之间的耦合;
一个对象应该对其他对象有最少的了解