写在前面:
设计模式能在不同的场景中得到反复推敲,实践,必然有其精华之处,这篇文章就带你揭开设计模式这本程序界的《孙子兵法》的精髓与奥妙~
一、单一职责原则:
官方论述:
就一个类而言,应该仅有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责偶合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力,这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。
个人理解:
让每个类尽可能只做一件事,类之间的业务关联尽量减少,理想化是完全无关联,即解耦。
这样做的优点:
A、可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
B、提高类的可读性,提高系统的可维护性;
C、变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
二、开放封闭原则:
官方论述:
软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。
个人理解:
你设计的时候,时刻要考虑,尽量让这个类足够好,写好了就不要去修改了,如果新需求来,最好的方式是我们增加一个类,原来的代码能不动则不动,可以避免其他对这个类有依赖类的不必要的麻烦。
这样做的优点:
A、对扩展开放:意味着有新的需求或变化时,可以对先有代码进行扩展,以适应新的情况。
B、对修改封闭:意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。
也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象,然而,对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
三、依赖倒转原则:
官方论述:
依赖倒置原则是程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。
个人理解:
设计业务时:将类与类之间的依赖转化为接口之间的依赖,即面向接口编程,因为相对于细节的多变性,接口则相对稳定得多,接口去制定业务规范和契约,而不要去涉及任何操作和细节,这些操作和细节交给具体的实现类去完成。
这样做的优点:
可以减少类间的耦合性,提高系统的稳定性,减少并行开发引起的风险(风险扩散),提高代码的可读性和可维护性。
A依赖B、B依赖C、C依赖D...... 若是修改A中的某个方法,B中依赖A的那个方法也要相应的修改,同样的,C、D中的方法也都需要修改,这就是风险扩散。
四、里氏替换原则:
官方论述:
如果对每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都换成o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。
里氏替换原则包含以下4层含义:
1、子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法。
2、子类中可以增加自己特有的方法。
3、当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
4、当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
个人理解:
子类可以扩展父类的功能,但是不能改变父类原有的功能,尽量不用重载,不用重写,原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合,组合等关系代替。
这样做的优点:
使用继承会给程序带来侵入性,程序的可移植性降低,增加了对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能会产生故障。
五、接口隔离原则
官方论述:
客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上
个人理解:
接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
这样做的优点:
A、减少了继承接口时不必要的冗余空实现、使得业务框架更加规范
B、依赖几个专用的接口要比依赖一个综合接口更灵活
C、通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
注:与单一职责原则的区别:
单一职责针对的是职责,注重的是具体实现和细节;接口隔离原则针对的是接口的约束,更加注重整体框架的构建
六、迪米特法则
官方论述:
一个对象应该对其他对象保持最少的了解。
网上更易理解的定义:只与直接的朋友通信。
首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。
个人理解:
就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,隐藏实现细节,对外提供方法给别人调用。
这样做的优点:
降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系
注意:迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。
迪米特法则遵循是自己的就是自己的,如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,就放置在本类中。
不知不觉已经过了零点^_^#
以上,便是设计模式要遵循的六大原则。主要参考书籍有《大话设计模式》以及网上一些零散的文章,但主要内容还是个人对这六个原则的感悟。这些原则对设计模式开篇系统地整理一下,一方面也与广大的网友分享,因为设计模式对编程人员来说,的确非常重要。如果大家对这六项原则有自己独到的见解,欢迎留言,大家共同探讨、共同进步@-@!