应遵循的设计原则与设计模式使用的建议"/>
关于代码应遵循的设计原则与设计模式使用的建议
一、设计模式的目的
设计模式是为了更好的代码重用性,可读性,可靠性,可维护性。
二、六大设计原则
(1)单一职责原则
该原则是针对类来说的,即一个类应该只负责一项职责。
如类T负责两个不同职责:职责P1,职责P2。当职责P1需求变更而改变T时,可能造成职责P2发生故障,所以需要将类T的粒度分解为T1,T2。
遵循单一职责的优点:
1.降低类的复杂度,一个类只负责一项职责。
2.提高类的可读性,可维护性
3.降低变更引起的风险。
总结:一个类尽量只做一件事。如果一个类中要做多件事情,那么就分解成多个类。
- 里氏替换原则
该原则是在1988年,由麻省理工学院的里姓女士提出的。
定义:如果对每个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型。
换句话说,所有引用基类的地方必须能透明地使用其子类的对象。
由定义可知,在使用继承时,遵循里氏替换原则,在子类中尽量不要重写和重载父类的方法。
继承包含这样一层含义:父类中凡是已经实现好的方法(相对抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。继承作为面向对象三大特性之一,在给程序设计带来巨大便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能产生故障。
总结:程序设计中尽量少的使用继承。如果一定要使用继承,那么应尽可能少的重写父类的方法。
- 依赖倒转原则
高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象。
类A直接依赖类B,如果要将类A改为依赖类C,则必须通过修改类A的代码来达成。此时,类A一般是高层模块,负责复杂的业务逻辑,类B和类C是低层模块,负责基本的原子操作;修改A会给程序带来风险。
将类A修改未依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或类C发生联系,则会大大降低修改类A的记几率。
依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中,抽象指的是接口或抽象类,细节就是具体的实现类,使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。依赖倒置的中心思想是面向接口编程。
例子:
使用此原则之前,MainTextToPDF这个类要经常改动,每次增加一种转PDF的方式就改一次代码。使用此原则后,传递的是PDFConvertor接口,具体实现都封装在接口的实现类中,这样做以后扩展性得到极大提高,MainTextToPDF类也非常稳定,后面增加任何转换方式也不用修改这个类,而只用增加一个PDFConvertor接口的实现类即可。
总结:尽可能进行面向接口的编程。定义方法时,参数尽量是抽象参数(接口,抽象类等),例如尽量使用Map,List,而不使用HashMap,ArrayList等具体实现类作为参数。
- 接口隔离原则
客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类C来说不是最小接口,则类B和类D必须去实现他们不需要的方法。
将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
举例说明接口隔离原则:
这个图的意思是:类A依赖接口I中的方法1,方法2,方法3,类B是对类A依赖的实现;类C依赖接口I中的方法1,方法4,方法5,类D是对类C依赖的实现。对于类B和类D来说,虽然存在用不到的方法(红色标记所示),但由于实现了接口I,所以也必须要实现这些用不到的方法。
因此根据此原则,应把接口I拆分为三个接口。如下图:
- 迪米特法则
一个对象应该对其他对象保持最少的了解。
类与类关系越密切,耦合度越大。迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public 方法,不对外泄露任何信息。
迪米特法则还有个更简单的定义:只与直接的朋友通信。什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部。
总结:依赖的对象只能是直接的朋友(成员变量、方法参数、方法返回值),不应该在局部变量中依赖陌生朋友。
- 开闭原则
一个软件实体如类,模块和函数应该对扩展开放(架构者),对修改关闭(客户端程序员)。用抽象构建框架,用实现扩展细节。
当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
当我们遵循前面介绍的5大原则,以及使用24种设计模式的目的就是遵循开闭原则。
- 常用设计模式
下面罗列(详细请ctrl进链接,自行学习)
- 单例模式
- 简单工厂模式
- 工厂方法模式
- 抽象工厂模式
- 建造者模式
- 原型模式
- 代理模式
- 适配器模式
- 装饰器模式
- 桥接模式
- 组合模式
- 享元模式
- 外观模式
- 观察者模式
- 模板方法模式
- 命令模式
- 状态模式
- 职责链模式
- 解释器模式
- 中介者模式
- 访问者模式
- 策略模式
- 备忘录模式
- 迭代器模式
更多推荐
关于代码应遵循的设计原则与设计模式使用的建议
发布评论