《大话设计模式》:迪米特原则

复习一下之前提到的几个原则:

单一职责:就一个类而言,应该仅有一个引起它变化的原因。

开放-封闭:软件实体(类,模块,函数等等)应该可以扩展,但是不可修改。

依赖倒转:子类型必须能够替换掉他们的父类型。



下面要介绍的是迪米特原则,也叫最少知识原则。

这些原则的提出是为了实现面向对象的几个好处:可维护、可扩展、可复用、灵活性好

迪米特原则

如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

其根本思想是强调了类之间的松耦合,类之间的耦合越弱,越有利于复用,一个处于弱耦合的类被修改,不会对有关系的类造成波及。

时间: 2024-12-25 06:45:56

《大话设计模式》:迪米特原则的相关文章

小菜学设计模式——迪米特原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:迪米特原则(最少知识原则) 书面理解 迪米特原则:如果两个类不必彼此直接通信,那么这两个类就应当发生直接的相互作用.如果其中一个类需要调用另一个类的某一个方法

大话设计模式C++版——原则和引言

转贴请注明转自:http://blog.csdn.net/gufeng99/article/details/45832711 读程杰的<大话设计模式>有一段时间了,将其C#版的设计模式代码用C++全部重新实现了一遍,并记下个人的一些心得,同时也对一些设计模式进行了改造.网上有份<大话设计模式实现(C++版)>的资料,但稍看后错误不少,比如用作接口的基类不将析构函数申明为虚函数,仅内部使用的成员变量不申明为private(公然违背迪米特法则),new出的对象不进行释放等等一些错误或不

报童、钱包和迪米特法则(设计模式迪米特原则经典论文翻译)

写在文章前: 或许你写过无数代码,参与过很多大型系统的设计,但,你是否曾经思考过,你的设计可扩展.易维护么,在高速变化的互联网世界里,它能经得起这种急速变化的考验么?如果你没想过这些问题,那请先放下你那些牛逼的梦想,放下你的高傲,好好去理解.回味设计六大原则和23种设计模式,因为它们是你腾飞的基石.今天,我勇敢的尝试翻译一篇有关设计原则的经典论文,希望对大家有帮助.(翻译是一项很费时.费精力的活,而且博主英语水平也不是特别好,翻译时多采用意译,见谅) 前言 在我读大学的时候,我的一个教授说每个程

《大话设计模式》——六大原则

谈到设计模式,它是骨灰级任务给我们总结的经验,也是我们对面向对象编程学习的深入.而设计模式中的六大原则,则是我们在学习它时要遵循的规则.下面宏观的看一看六大原则的导图吧! 一.导图分析 二.导图分析 1.单一职责:就一个类而言,应该仅有一个引起它变化的原因. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P

大话设计模式---迪米特法则

迪米特法则/最少知识原则 如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用.如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用. 前提:在类的结构设计上,每一个类都应当尽量降低成员的访问权限. 根本思想:强调类之间的松耦合.

大话设计模式---依赖倒转原则

依赖倒转原则 高层模块不应该依赖低层模块.两个都应该依赖抽象. 抽象不应该依赖细节.细节应该依赖抽象. 里氏代换原则:子类型必须能够替换掉它们的父类型.

大话设计模式---单一职责原则

单一职责原则(SRP):就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责互相分离.    如果能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责分离.

大话设计模式---开放-封闭原则

对于扩展是开放的:对于更改是封闭的. 无论模块是多么的“封闭”,都会存在一些无法对之封闭的变化.既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择.他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化. 在我们最初编写代码时,假设变化不会发生.当变化发生时,我们就创建抽象来隔离以后发生的同类变化.

设计模式—— 五:迪米特原则

目录 什么是迪米特原则? 迪米特法则的含义 1. 只和朋友交流 不遵循迪米特法则的定义 遵循迪米特法则的定义 2. 朋友间也是有距离的 不遵循迪米特原则的设计 遵循迪米特原则的设计 3. 是自己的就是自己的 4. 谨慎使用Serializable @ 什么是迪米特原则? 迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为"Demeter"的研究项目.迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP),