设计模式-八大设计原则

1.依赖倒置原则(DIP)
①高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象;
②抽象不应该依赖于实现细节(变化),实现细节应该依赖于抽象(稳定);
总结:这个原则是贯穿23种设计模式的,意思是说一个类A去依赖另一个类继承体系B的时候,我们应该去依赖B的基类(抽象类),而不应该去依赖B中的子类(派生类),因为子类是变化的,如果版本迭代增加了新的B的子类,那么A的依赖代码也需要修改。但如果我们依赖的是B的基类,那么通过多态调用也可以调到新增的B的子类而无需修改A类的代码。

2.开放封闭原则(OCP)
①对扩展开放,对更改封闭;
②类模块应该是可扩展的,但是不可修改的。
总结:在面对一些新需求时,我们应该考虑如何扩展(增加)原来的代码来达到要求,而不是对原来的体系进行重写,这样能保证之前已经编译测试通过的代码不会被破坏。所以我们设计的软件架构体系应该能适应这种扩展。在写类结构体系时,应该考虑到新增需求如何扩展的问题,这就需要设计有完备接口的抽象基类被其他类来依赖,从而保证版本迭代尽可能少地改动之前地代码。

3.单一职责原则(SRP)
①一个类应该仅有一个引起他变化的原因
②变化的方向隐含着类的职责
总结:设计一个类应该明确它地责任范围,不应该去做超出范围地工作。但只有一个引起它变化地原因可能不太现实,目前有些类处理的流程可能比较复杂,会涉及很多变化和状态,但责任范围一定是明确的,这样不会导致类功能混乱,不易于管理。至于变化的方向隐含着类的职责,其实就体现在类地成员函数上,这些成员函数就是类的职责功能,而类成员数据则表现着实例对象的状态。

4.Liskov替换原则(LSP)
①子类必须能够替换它们的基类(IS-A)。
②继承表达类型抽象。
总结:简单来说就是任何可以传递基类指针的地方,都可以传一个子类指针。这也是多态调用能够正常工作的必要条件,子类和基类应该时is a的关系,子类拥有所有基类拥有的特性(包括继承的和重写的),所以可以替换。如果违背了这个原则,那么这两个类本就不应该是继承的关系,可能是应该组合的。

5.接口隔离原则(ISP)
①不应该强迫客户程序依赖它们不用的方法
②接口应该小而完备
总结:在写一个类的时候,应该把主要的接口函数写为public,不必要函数尽量写到private中,防止客户程序依赖private中的方法,导致耦合严重,不利于维护。成员函数的可访问等级有三个,设置的基本原则是:允许客户代码来访问的接口public,允许子类使用的protected,之作自身类内部使用的private,成员数据一般也应该private。

6.优先使用对象组合,而不是类继承
①类继承通常为“白箱复用”,对象组合通常为“黑箱复用”
②继承在某种程度上继承了很多基类的函数,破坏了封装性,子类父类的耦合度过高。
③使用对象组合只要求被组合的对象具有良好的接口定义即可
总结:我的理解是不同体系的类之间一定不要使用继承,应该使用组合;使用继承的类,子类和父类中定义函数应该考虑其意义是否符合类定义的初衷,不应只考虑符合语法规则就盲目定义函数,防止破坏封装性。

7.封装变化点
①使用封装来创建对象之间的分界点,让设计者可以在分界点的一侧进行修改,而不会对另一侧产生不良影响,实现对象之间的松耦合。
总结:对象之间尽可能地解耦,不要允许彼此相互调用类或者数据进行增删改查。这样分别进行类设计不会对其他类产生影响,这个思想更多的体现在软件架构地设计中,每个模块各司其职,不要去做其他模块的工作或者修改其他模块的数据,模块与模块之间拥有确定的通讯函数接口,即分界点,能有效地避免代码混乱,便于维护。

8.针对接口编程,不要针对实现编程
①不将变量类型声明为某个特定的具体类,而声明为某个接口类;
②客户程序无需知晓对象的具体类型,只需要知道对象所具有的接口即可;
③减少系统中各部分的依赖关系,从而实现“高内聚、低耦合”的类设计方案。
总结:不仅依赖的类继承体系应该依赖抽象基类(只需要直到对象的接口即可),而且实现类的数据成员也可以是一些业务相关的接口类类型,在初始化的时候再指定为某个特定的实现类。减少系统中各部件的依赖关系,尽量不产生耦合,但肯定是需要有交互的地方,这些地方需要尽可能稳定。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

3 × 5 =