设计模式六大原则

设计模式六大原则

介绍

在软件开发过程中，尤其是面向对象和模块化设计时，一个良好的设计是会尽量符合几个基本原则的，这几个原则就是所谓的六大原则。

单一职责原则

定义:通俗的说一个类只有一项职责(一项职责并非一定是一个方法)

1、可以降低类的复杂性
2、可以提高类的可读性,从而提高系统的可维护性
3、变更引起的风险降低,变更是不可避免的,如果接口的单一职责定义的好,一个接口修改只对相应的实现类有影响,
对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。

需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,适合所有模块化的程序设计。

里氏替换原则

里氏替换原则简单来说就是所有引用基类(父类)的地方必须能透明地使用其子类的对象。里氏替换原则是依赖于继承、
多态这两大特性。

通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就
不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

里氏替换原则实现方式:子类可以扩展父类的功能,但不能改变父类原有的功能.

1、代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性
2、提高代码的重用性
3、提高代码的可扩展性,实现父类的方法就可以“为所欲为”了,很多开源框架的扩展接口都是通过继承父类或实现接口来完成的

依赖倒置原则

定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象。

上面说的那么玄乎其玄的,其实就是要我们面向接口编程而非面向实现类编程(此接口interface非彼接口api)

1、可扩展性好
2、耦合度低

该原则就是鼓励我们面向接口和面向抽象编程,解耦合可扩展。

开闭原则

定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭.

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误。
因此当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。

1、增加系统的稳定性(在有新增需求)
2、提高可扩展性

接口隔离原则

定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。

通俗说就是接口定义不应该大而杂应该小而精,应该尽量建立单一接口。并不是一味的设计越小的接口越好,要适度设计。

1、降低耦合性
2、提高代码可读性

迪米特法则

定义:一个对象应该对其他对象有最少的了解。

通俗地讲,一个类应该对自己需要耦合或调用的类知道得越少越好.

1、降低复杂度
2、降低耦合度

总结

六大原则最终目的就是为了达到高内聚低耦合可扩展和可维护的目的,为了达到这些目的,
通过面向接口编程等手段实现。高内聚低耦合，可扩展可读性简直就是和唱歌一样。

参考