设计模式六大原则

1.设计模式的目的

引用自:https://www.cnblogs.com/shijingjing07/p/6227728.html

设计模式是为了更好的代码重用性,可读性,可靠性,可维护性。

2.常用的六大设计模式

1)单一职责原则2)里氏替换原则3)依赖倒转原则4)接口隔离原则5)迪米特法则6)开闭原则

3.单一职责原则

该原则是针对类来说的,即一个类应该只负责一项职责。

如类T负责两个不同职责:职责P1,职责P2。当职责P1需求变更而改变T时,可能造成职责P2发生故障,所以需要将类T的粒度分解为T1,T2。

4.里氏替换原则

该原则是在1988年,由麻省理工学院的以为姓里的女士提出的。

如果对每个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型。

换句话说,所有引用基类的地方必须能透明地使用其子类的对象。

由定义可知,在使用继承时,遵循里氏替换原则,在子类中尽量不要重写和重载父类的方法。

继承包含这样一层含义:父类中凡是已经实现好的方法(相对抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。

继承作为面向对象三大特性之一,在给程序设计带来巨大遍历的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能产生故障。

举例说明继承的风险,我们需要完成一个两数相减的功能,由类A来负责。

5.依赖倒转原则

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

类A直接依赖类B,如果要将类A改为依赖类C,则必须通过修改类A的代码来达成。此时,类A一般是高层模块,负责复杂的业务逻辑,类B和类C是低层模块,负责基本的原子操作;修改A会给程序带来风险。

将类A修改未依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或类C发生联系,则会大大降低修改类A的记几率。

依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中,抽象指的是接口或抽象类,细节就是具体的实现类,使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。

依赖倒置的中心思想是面向接口编程。

采用依赖倒置原则给多人并行开发带来极大的便利,比如上列中Mother类与Book类直接耦合,Mother必须等Book类编码完成后才可以进行编码,因为Mother类依赖于Book类。修改后的程序可以同时开工,互不影响。

依赖关系的传递有三种方式,接口传递,构造方法传递和setter方法传递。


6.接口隔离原则

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

类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类C来说不是最小接口,则类B和类D必须去实现他们不需要的方法。

将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

说到这里,可能会觉得接口隔离原则和之前的单一职责原则很相似,其实不然。一,单一职责注重职责,而接口隔离原则注重对接口依赖的隔离;二,单一职责是约束类,其次是方法,针对的是程序中的实现和细节;而接口隔离原则约束的是接口,针对的是抽象,程序整体框架的构建。

7.迪米特法则

一个对象应该对其他对象保持最少的了解。

类与类关系越密切,耦合度越大。

迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public 方法,不对外泄露任何信息。

迪米特法则还有个更简单的定义:只与直接的朋友通信。

什么是直接的朋友:每个对象都会与其他对象由耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部。

举例额说明如下,有一个集团公司,下属单位有分公司和直属部门,现要求打印出所有下属单位的员工ID。

迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。

8.开闭原则

一个软件实体如类,模块和函数应该对扩展开放,对修改关闭。用抽象构建框架,用实现扩展细节。

当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。

当我们遵循前面介绍的5大原则,以及使用23中设计模式的目的就是遵循开闭原则。

推荐阅读更多精彩内容

  • 目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒...
    大宝来巡山阅读 580评论 0 4
  • 设计模式六大原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类...
    viva158阅读 366评论 0 1
  • 转载标注声明:http://www.uml.org.cn/sjms/201211023.asp 目录:[设计模式六...
    Bloo_m阅读 356评论 0 7
  • 转载自 设计模式六大原则 目录:- 设计模式六大原则(1):单一职责原则- 设计模式六大原则(2):里氏替换原则-...
    厨子阅读 552评论 2 5
  • 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 ...
    Jabir_Zhang阅读 244评论 0 3