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

    1、背景

     在图书馆借书,刚开始的时候,直接跑到相应的楼层去,到里面去转,去找要借的书,在里面溜达半天才能找到;后来知道图书馆有一个电脑查询处,然后直接在电脑上输入想要借的书,电脑就会显示你想要借的书的信息,还有所在的相关楼层存放的相关位置。

      

   

    2、定义

     迪米特法则(Law of Demeter)又叫作最少知识原则(LKP,Least Knowledge Principle),就是说一个对象应当对其他对象有尽可能少的了解,类与类之间的了解的越多,关系越密切,耦合度越大,当一个类发生改变时,另一个类也可能发生变化。

  核心思想:最少依赖

  具体体现:

  • 类内部应该高内聚,设置相应的权限,有选择的暴露方法,这就是封装的奥秘。
  • 类的依赖关系尽量减少,保持简单和独立,降低耦合。

  有些东西,可以适当的知道,知道的太多对你不好。关系越复杂,人越不敢接近你。要达到很高的内修养,才能有很好的表现。

  

  3、设计模式中的具体应用

  1)、门面(外观)模式

   如果一个子系统内部的对象构成自己的朋友圈,而子系统外部 对象都属于陌生人的话,那么子系统外部的对象与内部的对象就不应当直接通信,而应当通过一个双方都认可的朋友,也就是门面对象进行通信,这就导致了门面模式。

 

   2)、中介者模式

   这里一些对象形成一个中等规模的朋友圈,而圈内很多的对象都有排列组合般的交互作用。这时,可以通过创造一个大家共有的朋友对象,然后大家都通过这个朋友对象发生相互作用,而将相互之间的直接相互作用省略掉,这就导致了中介者模式。

  

    3、规则建议

    在类的划分上,应当创建弱耦合的类,类与类之间的耦合越弱,就越有利于实现可复用的目标。

   在类的结构设计上,每个类都应该降低成员的访问权限。

   在类的设计上,只要有可能,一个类应当设计成不变的类。

   在对其他类的应用上,一个对象对其他类的对象的应用应该降到最低。尽量限制局部变量的有效范围。

 

时间: 2024-09-19 03:07:56

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

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

       背景        在学校学习时,可能因为某些事你得去其他二级学院的老师帮忙,大部分老师都是忙的(也许是的)很可能一件小事你要跑很多次.但是如果你这件事直接找的是其他学院的院长,并且院长同意帮忙的话这件事解决起来就容易多了.不知怎地最近老是瞎想感觉这件事又能和设计模式中的迪米特法则(Law of Demeter,LOD),也叫最少知识原则(Least Knowledge Principle,LKP)扯上关系,接下来就由小生带大家粗略的了解一下这个法则吧.        定义    

java设计模式六大原则之场景应用分析

看了一篇文章,感觉收获蛮大,不过还有一些不懂,收藏慢慢研究. 面对项目中如此众多的设计模式,我们有时候无法下手.在强大的设计框架也终脱离不了23种设计模式,6大原则.我们只要把内功修炼好,掌握其精髓也离我们不远了...     目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则(6):开闭原则 设计模式六大原则(1):单一职责原则 设计

设计模式六大原则(6):开闭原则

定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.          开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统.开闭原则可能是设计模式六项原则中定义最模糊的一个了,它

设计模式六大原则 里氏替换原则

设计模式六大原则(2):里氏替换原则 是不是有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的. 2002年,软件工程大师Robert C. Martin,出版了一本<Agile Software Development Principles Patterns and Practices>,在文中他把里氏代换原则最终简化为一句话: "Subtypes must b

设计模式六大原则 依赖倒置原则

设计模式六大原则(3): 依赖倒置原则 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 所谓依赖倒置原则(Dependence Inversion Principle )就是要依赖于抽象,不要依赖于具体.简单的说就是对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合. 依赖倒置原则的核心思想是面向接口编程. 而面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变化时,上层也要跟着变化,这就会导致模块的复用性降低而且大大提高

设计模式六大原则 单一职责原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责,一个人只负责做一件事. ( 一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离 ) 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修

设计模式六大原则——合成/聚合复用原则(CARP)

   1.定义    简而言之,对于合成/聚合复用原则的定义就是:要尽量使用合成和聚合,尽量不要使用继承.           2.释义     为什么"要尽量使用合成和聚合,尽量不要使用继承"呢?      这是因为:      第一,继承复用破坏包装,它把父类的实现细节直接暴露给了子类,这违背了信息隐藏的原则:      第二:如果父类发生了改变,那么子类也要发生相应的改变,这就直接导致了类与类之间的高耦合,不利于类的扩展.复用.维护等,也带来了系统僵硬和脆弱的设计.而用合成和聚合

设计模式六大原则(5):迪米特法则

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

PHP设计模式——六大原则

      声明:本系列博客参考资料<大话设计模式>,作者程杰.      一般认为遵从以下六大原则的代码是易扩展可复用的代码:                                        这六大原则任何面向对象的语言都应该遵守的,要想让你的代码易扩展高服用就尽量去满足这六大原则吧,不一定严格按照某种设计模式,但是如果你的代码符合这六大原则,那么你的代码就是好代码了,好的代码不一定是严格按照设计模式写的代码.          1.单一职责         定义:不要存在多于