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

目录:

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

  设计模式六大原则:接口隔离原则

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

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

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

  设计模式六大原则:开闭原则

迪米特法则(LOD):

  也叫最少知识原则。迪米特法则的定义是只与你的直接朋友交谈,不与"陌生人"说话。如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该应用。其目的是降低类之间的耦合度,提高模块的相对独立性。

  迪米特法则中的朋友是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。

优点:

  1、降低类之间的耦合度,提高模块的相对独立性。

  2、由于亲和度降低,从而提高了类的可复用率和系统的扩展性。

缺点:

  过度使用迪米特法则会使系统产生大量的中介类,从而增加系统的复杂性,使模块之间的通信效率降低。所以,在釆用迪米特法则时需要反复权衡,确保高内聚和低耦合的同时,保证系统的结构清晰。

使用迪米特法则需要注意:

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

  2、在类的结构设计上,尽量降低类成员的访问权限。

  3、在类的设计上,优先考虑将一个类设置成不变类。

  4、在对其他类的引用上,将引用其他对象的次数降到最低。

  5、不暴露类的属性成员,而应该提供相应的访问器(set 和 get 方法)。

  6、谨慎使用序列化(Serializable)功能。

经典案例:

  蔡徐坤与经纪人的关系实例。蔡徐坤只负责浪,经纪人负责处理日常事务,如与粉丝的见面会,与媒体公司的业务洽淡等。

 1 internal class Program
 2 {
 3     private static void Main(string[] args)
 4     {
 5         Agent agent = new Agent();
 6         agent.setStar(new Star("蔡徐坤"));
 7         agent.setFans(new Fans("小明"));
 8         agent.setCompany(new Company("**公司"));
 9         agent.meeting();
10         agent.business();
11     }
12 }
13
14 internal class Agent
15 {
16     private Star myStar;
17     private Fans myFans;
18     private Company myCompany;
19
20     public void setStar(Star myStar)
21     {
22         this.myStar = myStar;
23     }
24
25     public void setFans(Fans myFans)
26     {
27         this.myFans = myFans;
28     }
29
30     public void setCompany(Company myCompany)
31     {
32         this.myCompany = myCompany;
33     }
34
35     public void meeting()
36     {
37         Console.WriteLine($"{myFans.getName()}与明星{myStar.getName()}见面了。");
38     }
39
40     public void business()
41     {
42         Console.WriteLine($"{myCompany.getName()}与明星{myStar.getName()}洽谈业务。"
43     }
44 }
45
46 internal class Star
47 {
48     private string name;
49
50     public Star(string name)
51     {
52         this.name = name;
53     }
54
55     public string getName()
56     {
57         return this.name;
58     }
59 }
60
61 internal class Company
62 {
63     private string name;
64
65     public Company(string name)
66     {
67         this.name = name;
68     }
69
70     public string getName()
71     {
72         return this.name;
73     }
74 }
75
76 internal class Fans
77 {
78     private string name;
79
80     public Fans(string name)
81     {
82         this.name = name;
83     }
84
85     public string getName()
86     {
87         return this.name;
88     }
89 }

view code

原文地址:https://www.cnblogs.com/az4215/p/11489748.html

时间: 2024-10-12 18:32:04

设计模式六大原则:迪米特法则的相关文章

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

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

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

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

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

转载于:http://www.cnblogs.com/muzongyan/archive/2010/08/05/1793000.html 定义: 迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP). 一个对象应该对其他对象有最少的了解.通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的public方法,我就调用这么多,其他的一概不

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

迪米特法则 定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合. 迪米特法则(Law of  Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用. 如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度.迪米特法则可降低系统的耦

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

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

java设计模式六大原则

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

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

开闭原则 定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭.即软件实体应尽量在不修改原有代码

详解设计模式六大原则

设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的:设计模式使代码编制真正工程化:设计模式是软件工程的基石脉络,如同大厦的结构一样. 借用并改编一下鲁迅老师<故乡>中的一句话,一句话概括设计模式: 希望本无所谓有,无所谓无.这正如coding的设计模式,其实coding本没有设计模式,用的人多了,也便成了设计模式 v六大原

设计模式六大原则-----转载

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