迪米特法则详解--七大面向对象设计原则(6)

迪米特法则的来源:

迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出。类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。于是就提出了迪米特法则。通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。

迪米特法则的简单定义:

    只与直接的朋友通信。

首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,当前对象本身(this)、成员变量、以参数形式传入当前对象方法中的对象、方法返回值中的类,当前对象创建的对象为直接的朋友。

迪米特法则的作用:

     迪米特法则可降低系统的耦合度,使类与类之间保持较低的耦合关系。我们知道,软件编程有一个总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。

迪米特法则的示例:

        如图1所示,类之间存在复杂的交互关系,一个ClassBase类的动作执行将导致多个其它关联类产生响应,例如,当ClassBase有动作时时,和它有关联的类ClassB、ClassC、ClassD等都将发生改变,在初始设计方案中,对象之间的交互关系可简化为如图1所示结构:

在图1中,由于类之间的交互关系复杂,导致在该系统中增加新的对象时需要修改与之交互的其它类的源代码,系统扩展性较差,也不便于增加和删除新对象。

在本示例中,可以通过引入一个专门用于控制对象间交互的中介类(Mediator)来降低各对象之间的耦合度。引入中间类之后,相关对象之间不再发生直接引用,而是将请求先转发给中间类,再由中间类来完成对其它对象的调用。当需要增加或删除新的对象时,只需修改中间类即可,无须修改新增对象或已有对象的源代码,重构后结构如图2所示:

迪米特法则的使用总结:

(1).在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及;

(2).在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限;

(3).在类的设计上,只要有可能,一个类型应当设计成不变类;

(4).在对其他类的引用上,一个对象对其他对象的引用应当降到最低。

时间: 2024-10-26 22:41:12

迪米特法则详解--七大面向对象设计原则(6)的相关文章

里氏替换原则详解--七大面向对象设计原则(2)

里氏替换原则来源: 我们都知道面向对象有三大特性:封装.继承.多态.所以我们在实际开发过程中,子类在继承父类后,根据多态的特性,可能是图一时方便,经常任意重写父类的方法,那么这种方式会大大增加代码出问题的几率.比如下面场景:类C实现了某项功能F1.现在需要对功能F1作修改扩展,将功能F1扩展为F,其中F由原有的功能F1和新功能F2组成.新功能F由类C的子类C1来完成,则子类C1在完成功能F的同时,有可能会导致类C的原功能F1发生故障.这时就有人提出了里氏替换原则.里氏替换原则这项原则最早是在19

依赖倒置原则详解--七大面向对象设计原则(3)

依赖倒置原则来源: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口,不要依赖于具体实现.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合. A.高层模块不应该依赖低层模块,二者都应该依赖其抽象.抽象

接口隔离原则详解--七大面向对象设计原则(4)

 接口隔离原则的来源: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法.因为使用多个专门的接口比使用单一的总接口要好,所以便提出了接口隔离原则. 接口隔离原则的目的: 将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 接口隔离原则的两种定义:  (1) 当把"接口"理解成一个类型所提供的所有方法特征的集合的时候,这就是一种逻辑上的概念,接口的划分

单一职责原则详解--七大面向对象设计原则(1)

单一职责原则来源: 定义:单一职责就是一个类负责一项职责.就一个类而言,应该只专注于做一件事和仅有一个引起它变化的原因. 所谓职责,我们可以理解为功能,就是设计的这个类功能应该只有一个,而不是两个或更多.也可以理解为引用变化的原因,当你发现有两个变化会要求我们修改这个类,那么你就要考虑撤分这个类了.因为职责是变化的一个轴线,当需求变化时,该变化会反映类的职责的变化. 单一职责原则,很太简单.大多数开发人员,在设计软件时也会自觉的遵守这一重要原则,因为这是常识.在软件编程中,谁也不希望因为修改了一

七大面向对象设计原则

一.面向对象原则综述 七大原则总脉络图: 二.常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充. . 三.以下详细分析: (一)单一职责原则(Single Responsibility Principle, SRP) 1.定义:一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中    或者:就一个类而言,应该仅有一个引起它变化的原因. 2.分析:一个类(或者大到模块,小到方法)承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于

程序员七大面向对象设计原则

在没有了解到面向对象设计的7大原则前,我只是一只豆子!   但豆子终将会成长不是吗? 1.开闭原则:一个软件实体应当对扩展开放,对修改关闭.也就是说在所涉及一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为. 在开闭原则的定义中,软件实体可以指一个软件模块.一个由多个类组成的局部结构或一个读库的类. 抽象化是开闭原则的关键. 是添加新代码完成方法的重构  而不是修改源代码 声明: 本文源自 2.依赖倒转原则:高层模块不应该依赖低层模块,他们

7大面向对象设计原则

面向对象设计原则 一.概述 针对软件的可维护性和可复用性,知名软件大师Robert C.Martin认为一个可维护性(Maintainability) 较低的软件设计,通常由于如下4个原因造成:过于僵硬(Rigidity) ,过于脆弱(Fragility) ,复用率低(Immobility) ,黏度过高(Viscosity) .软件工程和建模大师Peter Coad认为,一个好的系统设计应该具备如下三个性质:可扩展性(Extensibility) ,灵活性(Flexibility),可插入性(P

设计模式2 面向对象设计原则

面向对象设计原则  原则的目的 面向对象设计原创表  单一职责原则案例 开闭原则 案例 依赖倒转原则 案例 面向对象设计原则  对于面向对象软件系统的设计而言,在支持可维护性的同时,提高系统的可复用性是一个至关重要的问题,如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一.在面向对象设计中,可维护性的复用是以设计原则为基础的.每一个原则都蕴含一些面向对象设计的思想,可以从不同的角度提升一个软件结构的设计水平.  面向对象设计原则为支持可维护性复用而诞生,这些原则蕴含

第二章 【面向对象设计原则】

(一)如何衡量软件设计的质量 内聚度: 表示一个应用程序的单个单元所负责的任务数量和多样性.内聚与单个类或者单个方法单元相关.(好的软件设计应该做到高内聚.) 耦合度: 耦合度表示类之间关系的紧密程度.低耦合是指尽量使用抽象耦合,少用具体耦合. 设计原则名称 设计原则简介 重要性 单一职责原则 的职责要单一,不能将太多的职责放在一个类中. ★★★★☆ 开闭原则 软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件实体的基础上去扩展其功能.  ★★★★★ 历史替换原则 在软件系统中,一个可