围观设计模式(5)--迪米特法则(Lod,Law of Demeter)或最少知道原则(Least Knowledge Principle)

得墨忒耳(迪米特)定律（Law of Demeter，缩写LoD）亦称为“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，特别是面向对象的程序设计。得墨忒耳(迪米特)定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末在发明的，可以简单地以下面任一种方式总结:

1. 每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；

2. 每个单元只能和它的朋友交谈：不能和陌生单元交谈；

3. 只和自己直接的朋友交谈。

这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。

很多面向对象程序设计语言用"."表示对象的域的解析算符，因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此，a.b.Method()违反了此定律，而a.Method()不违反此定律。一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。----WIKIPIDIA

个人的理解：

面向对象的程序设计中，对象与对象之间尽量相互独立，具体对象的行为由具体的对象去完成，而不是由某个对象去指定另一个对象去实施行为而且是具体的行为。迪米特法则，核心的思想就是，要求我们在设计的时候，尽量避免类与类之间的耦合，弱化耦合关系可以提升复用率，但是这样的话，会产生中间的跳转类等，导致系统复杂。实际使用的过程中尽量在保证可读性与复杂性较低的情况下，按照迪米特法则去弱化类与类之间的耦合关系（高内聚、低耦合）。

下面看这样的一个例子：

场景介绍：想象一下，你是这家的主人，雇佣了管家帮你安排一些家务事，还雇佣了一些佣人去帮你完成管家吩咐的家务事。你想吃饭，这时候，需要向管家吩咐一下，然后你就不需要管了，具体谁去做饭这不需要你去关系，你只需要知道，待半个小时左右，我看到餐桌上有饭，你可以去品尝就好了，这样才是比较合理的事情。

直接看代码：

佣人：

public class Maid {private String maidName;public Maid() {super();}public Maid(String maidName) {super();this.maidName = maidName;}public void cook(){System.out.println(this.maidName + ">>做饭！");}}

管家：

public class Butler {public void cook(List<Maid> maidList){for (Maid maid : maidList) {maid.cook();}}
}

主人：

public class Master {public void cookCommand(Butler butler){List<Maid> maidList = new ArrayList<Maid>();for(int i = 0; i < 2; i++){maidList.add(new Maid("maid" + i));}butler.cook(maidList);}
}

问题来了，这里的设计的时候，是不是太不合理了，你作为一个主人，管的太多了，因为你要去创建好一些佣人，交给管家去吩咐，这个任务对你来说显然是多余的，因为有管家在，你不用去做这么多事情，你只需要跟管家说，管家，我想吃点东西，管家接到命令之后，去找来几个佣人，然后去给你做饭。这样才是好的设计。

上面的这个设计违背了迪米特法则，因为，Master与Butler、Maid是层级的关系，在Master这个类中，只需要去管理Butler而Butler中去管理Maid,通俗来说是Master给Butler吩咐任务，Butler接到任务后然后再给Maid分配任务。

我们按照这个思路再来设计一下上面的例子。

public class Master {public void cookCommand(Butler butler){butler.cook();}
}

public class Butler {public List<Maid> getMaidList(){List<Maid> maidList = new ArrayList<Maid>();for(int i = 0; i < 2; i++){maidList.add(new Maid("maid" + i));}return maidList;}public void cook(){List<Maid> maidList = getMaidList();for (Maid maid : maidList) {maid.cook();}}
}

这样设计的话，你会发现，Master不用跟Maid打交道，而是和Butler打交道，这样的话，减少了类与类之间不必要的耦合，使得系统更稳定，扩展更容易。

根据迪米特法则设计类的时候，尽量降低非朋友类之间的耦合。

源代码：源代码下载

围观设计模式(5)--迪米特法则(Lod,Law of Demeter)或最少知道原则(Least Knowledge Principle)相关推荐

深入理解迪米特法则（Law Of Demeter）
@[TOC](迪米特法则(Law of Demeter)) 迪米特法则(Law of Demeter) 迪米特法则来自于1987年美国东北大学的一个名为Demeter的一个研究项目. 迪米特法则又称为 ...
迪米特法则（Law of Demeter, LoD）
迪米特法则又叫作最少知识原则,就是说一个对象应当对其他对象有尽可能少的了解. 狭义的迪米特法则的缺点: 在系统里造出大量的小方法,这些方法仅仅是传递间接的调用,与系统的商务逻辑无关. 遵循类之间的迪米 ...
迪米特法则 php,迪米特法则(The Law of Demeter) -解道Jdon
迪米特法则父母都会教育孩子们,不要和陌生人讲话,如果有陌生人试图和他们讲话,必须告诉爸爸妈妈,这是因为孩子们还不成熟,会相信一切成人告诉他们的事情,我们这样做是为了包含他们. 在面向对象编程中,我们 ...
【设计模式】迪米特法则
迪米特法则LoD Law of Demeter ,最少知识原则(Least Konwledge Principle,简写LKP).如果两个类不彼此直接通信,那么这两个类就不应当发生直接的相互作用.如果 ...
软件设计模式之迪米特法则(Darren)
各位博友晚上好先回顾一下之前学习的设计模式和原则简单工厂模式,策略模式,单一职责原则,开放封闭原则,依赖倒转原则,装饰模式,代理模式,抽象工厂模式,原型模式(Copy,深复制,浅复制)以及昨天刚刚 ...
嘻哈说：设计模式之迪米特法则
1.疑惑在我们刚开始学习编程的时候,通常会将所有的方法都声明为public,例如: package com.fanqiekt.principle.lod;/*** 厨师** @author 番茄课堂 ...
【设计模式】迪米特法则和六种原则的总结
迪米特法则一个对象应该对其他对象保持最少的了解类与类关系越密切,耦合度越大迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好.也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装 ...
【设计模式】迪米特法则（Demeter Principle）
又称最少知道原则.指:一个实体应当尽量少地与其他实体之间发生相互作用,使得系统功能模块相对独立. 其含义是:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用.其目 ...
java 迪米特法则_Java设计模式之迪米特法则
迪米特法则是在一个叫做迪米特的项目中提出来的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫做最少知识原则. 迪米特法则的意义是降低类之间的耦合,由于每个对象应该尽量减少对其他对象的了解 ...

围观设计模式(5)--迪米特法则(Lod,Law of Demeter)或最少知道原则(Least Knowledge Principle)

围观设计模式(5)--迪米特法则(Lod,Law of Demeter)或最少知道原则(Least Knowledge Principle)相关推荐

最新文章

热门文章