设计模式之六大原则
1.开闭原则
开闭原则(Open-Close Principle, OCP)是指一个软件实体(如类、模块、函数)应该对扩展开放,对修改关闭.所谓的开闭,也正是对扩展和修改两个行为的一个原则.它强调的是用抽象构建框架,用实现扩展细节.可以提高软件系统的可复用性及可维护性.开闭原则是面向对象设计中最基础的设计原则,它知道我们如何建立稳定、灵活的系统.例如版本更新,我们尽可能不修改源码,但是可以增加新功能.
开闭原则的核心思想就是面向抽象编程.
2.依赖倒置原则
依赖倒置原则(Dependence Inversion Principle, DIP)是指设计代码结构时,高层模块不应该依赖底层模块,二者都应该依赖其抽象.抽象不依赖细节,细节应该依赖抽象.通过依赖倒置,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码的可读性和可维护性,并且能够降低修改程序所造成的风险.
3.单一职责
单一职责原则(Simple Responsibility Principle, SRP)是指不要存在多于一个导致类变更的原因.如果一个类负责两个职责,一旦发生需求变更,修改其中一个职责的逻辑代码,有可能导致另一个职责的功能发生故障.这样就会存在两个类变更的原因.为了解决这个问题最好的方式就是将两个职责分成两个类来实现,进行解耦.之后两者的需求变更不再相互影响.降低了类的复杂度,提高了类的可读性,提高系统的可维护性,降低需求变更的风险.
(相信出现上述情况的朋友不在少数,在一个类中用大量的if-else来进行切分职责,强行把另一个职责加入其中,以致于可维护性、可读性非常差,前车之鉴,后车之师)
4.接口隔离原则
接口隔离原则(Interface Segregation Principle，ISP)是指用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口.当我们在设计接口时应当注意以下几点:
(1)一个类对另一个类的依赖应该建立在最小的接口之上.
(2)建立单一接口,不要建立庞大臃肿的接口.
(3)尽量细化接口,接口中的方法尽量少(不是越少越好,一定要适度)
接口隔离原则符合我们常说的高内聚、低耦合的设计思想,可以使类具有很好的可读性、可扩展性和可维护性.
在需求开发中,常常会遇到它们是一系列相关业务的需求,把这类业务全写在一个总接口中,当我们需要调用这个总接口的一个小业务需求的接口时,不得不进行一番寻找,如果命名遵循相同的格式还比较容易找到,暂且不说接口的大量加载而导致持有较大的元空间.现实开发中,由于是公司协作开发,这就造成了一个总接口,会有很多人在其中进行定义,如果大家没有沟通好并且命名习惯不统一的话,很容易造成接口污染.需要花费一定的时间来寻找自己所需的方法,找得到还好说,找不到,则会导致另一种后果,方法重复.非常不可取的.做了很多无用功.
5.迪米特原则
迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP)，尽量降低类与类之间的耦合度.迪米特原则主要强调:只和朋友交流,不和陌生人说话.出现在成员变量、方法的输入、输出参数中的类都可以成为成员朋友类,而出现方法体内部的类不属于朋友类.
6.里氏替换原则
里氏替换原则(Liskov Subsititution Principle, LSP)是指如果对每一个类型为T1的对象O1,都有类型为T2的对象O2,使得以T1定义的所有程序P在所有的对象O1都替换成O2时,程序P的行为都没有发生变化,那么类型T2是T1的子类型
转换一下,就可以理解为一个软件实体如果适用于一个父类,那么一定适用于其子类,所有引用父类的地方必须能透明地使用其子类的对象,子类对象能够替换父类对象,而程序逻辑不变.子类可以扩展父类的功能,但不能改变父类的原有的功能.子类不能改变父类方法的逻辑.否则将不能保证程序P的行为没有发生变化,子类一般被认为是父类的扩展方法。但是也有几点需要注意的:
(1)子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法
(2)子类可以增加自己特有的方法
(3)当子类的方法重载父类的方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽容
(4)当子类的方法实现父类的方法时(重写/重载或实现抽象方法),方法的后置条件(即方法的输出/返回值)要比父类更加焰哥或与父类一样.
结尾
设计模式在复杂的应用系统中往往能发挥到意想不到的作用,它主要是控制了系统的可读性和可维护性以及可扩展性.在应用开发过程中,可能会遵照敏捷开发不考虑什么设计原则,这样有好处也有坏处,好处是开发比较迅速,简单粗暴.当后续需求要在原有的需求中进行改造时,作为开发人员就会思考如何接入新的变动.这个时候就会陷入一种苦恼.当然不是为了设计模式而去设计,这是一种无形的内化,我也不是要无脑鼓吹设计模式,只是一种经验式的总结.知道我们之前的设计是一种什么体系.为了更好的应对复杂的应用体系.