设计模式之六大原则——迪米特法则(LoD,LKP)

转载于:http://www.cnblogs.com/muzongyan/archive/2010/08/05/1793000.html

定义:

迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)。

一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的public方法,我就调用这么多,其他的一概不关心。

含义:

  • 只和朋友交流

朋友类的定义是这样的:出现在成员变量、方法的输入输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类。

下面的代码在方法体内部依赖了其他类,这严重违反迪米特法则


1

2

3

4

5

6

7

8

9

10

11

12

13

public class Teacher {

 

    public void commond(GroupLeader groupLeader) {

        List<Girl> listGirls = new ArrayList<Girl>();

 

        for (int i = 0; i < 20; i++) {

            listGirls.add(new Girl());

        }

 

        groupLeader.countGirls(listGirls);

    }

 

}

方法是类的一个行为,类竟然不知道自己的行为与其他类产生了依赖关系,这是不允许的。

正确的做法是:

?


1

2

3

4

5

6

7

public class Teacher {

 

    public void commond(GroupLeader groupLeader) {

        groupLeader.countGirls();

    }

 

}

?


1

2

3

4

5

6

7

8

9

10

11

12

13

public class GroupLeader {

 

    private List<Girl> listGirls;

 

    public GroupLeader(List<Girl> _listGirls) {

        this.listGirls = _listGirls;

    }

 

    public void countGirls() {

        System.out.println("女生数量是:" + listGirls.size());

    }

 

}

注意:一个类只和朋友交流,不与陌生类交流,不要出现getA().getB().getC().getD()这种情况(在一种极端情况下允许出现这种访问,即每一个点号后面的返回类型都相同),类与类之间的关系是建立在类间的,而不是方法间,因此一个方法尽量不引入一个类中不存在的对象,当然,JDK API提供的类除外。

  • 朋友间也是有距离的

一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险扩散也就越大。因此,为了保持朋友类间的距离,在设计时需要反复衡量:是否还可以再减少public方法和属性,是否可以修改为private、package-private(包类型,在类、方法、变量前不加访问权限,则默认为包类型)、protected等访问权限,是否可以加上final关键字等。

注意:迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。

  • 是自己的就是自己的

如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,就放置在本类中。

  • 谨慎使用Serializable

最后,迪米特法则的核心观念就是类间解耦,弱耦合,只有弱耦合了以后,类的复用率才可以提高。

时间: 2024-10-06 17:20:08

设计模式之六大原则——迪米特法则(LoD,LKP)的相关文章

设计模式六大原则——迪米特法则(LoD)

1.背景 在图书馆借书,刚开始的时候,直接跑到相应的楼层去,到里面去转,去找要借的书,在里面溜达半天才能找到:后来知道图书馆有一个电脑查询处,然后直接在电脑上输入想要借的书,电脑就会显示你想要借的书的信息,还有所在的相关楼层存放的相关位置. 2.定义 迪米特法则(Law of Demeter)又叫作最少知识原则(LKP,Least Knowledge Principle),就是说一个对象应当对其他对象有尽可能少的了解,类与类之间的了解的越多,关系越密切,耦合度越大,当一个类发生改变时,另一个类也

10设计模式六大原则——迪米特法则

设计模式六大原则(5):迪米特法则 定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合. 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的. 迪米特法则又叫最少知道原则,最早是在1987年

设计模式--迪米特法则(Lod/LKP)

迪米特法则:(Law of Demeter, LoD),也称最少知识原则(Least Knowledge Principle, LKP) 理解: 如果两个类不必彼此直接通信,那么这两个类就不应该发生直接的相互作用.如果其中一个类需要调用另一个类的某一个放发的话,可以通过第三者转发这个调用. 只和朋友交流(更准确来讲是:直接的朋友) 每个对象都必然会与其他对象有耦合关系,两个对象之间的耦合就成为朋友关系,这种关系的类型有很多,如组合.聚合.依赖等. 朋友类的定义:出现在成员变量.方法的输入输出参数

设计模式之六大原则(转载)

关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来. 原作者博客链接:http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 原文链接:http://blog.csdn.net/lovelion/article/details/7536542 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大

设计模式的六大原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

【设计模式的六大原则】

设计模式的六大原则 1.开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭.在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果.所以一句话概括就是:为了使程序的扩展性好,易于维护和升级.想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点. 2.里氏代换原则(Liskov Substitution Principle) 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的

【设计模式】六大原则

设计模式的六大原则: * 开闭原则(Open Close Principle) 开闭原则的意思是:对扩展开放,对修改关闭.在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果.简言之,是为了使程序的扩展性好,易于维护和升级.想到达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点. * 里氏代换原则(Liskov Substitution Principle) 里氏代换原则是面向对象设计的基本原则之一.里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现

无废话设计模式(0)--设计模式的六大原则

设计模式的六大原则: 1.单一职责原则:对于一个类,应该只有一个引起它变化的原因: 2.里氏替换原则:子类必须能够替换掉他们的父类型: 3.开放封闭原则:程序的对象应该可以扩展,但不应该可以修改: 4.依赖倒转原则:高层模块不应依赖于底层模块,两者都应依赖于抽象:抽象不依赖于集体细节,而细节应该依赖于抽象: 5.合成/聚合复用原则:尽量不要使用类继承,而尽量使用合成/聚合: 6.迪米特法则:如果两个类之间不必直接通信,则这两个类不应该发生直接的相互作用:如果其中一个类需要调用另外一个类的某个方法

关于设计模式的六大原则

目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则(6):开闭原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案