精华内容
下载资源
问答
  • 在系统设计中应用迪米特法则
    2022-02-10 11:38:13

    书接上回,本篇继续讲一下设计模式六大原则(有些书认为是7大原则)

    原则定义

    迪米特法则(Law of Demeter,LoD)的定义有点意思,有2种表述

    1> 最少知道原则,指一个对象应当对其他对象有尽可能少的了解。

    2> 只和直接的朋友交流(也有说法:不要与陌生人说话)

    初看有点令人摸不着头脑,细细品品,好像是那么一回事,说下个人理解:

    1> 最少知道原则,指一个对象应当对其他对象有尽可能少的了解。

    其实可以理解为,在符合设计(开发)规范前提下,对象与对象间能不交互就不要交互,保持对象的独立性,降低类间耦合度,提高模块的复用性。

    2>只和直接的朋友交流(也有说法:不要与陌生人说话)

    这里的朋友,是朋友类的意思,理解起来有点抽象,因为我们对象朋友类这词有点陌生。迪米特法则提出者给出朋友类定义:A类如果被B类依赖,那A类就是B类的朋友类。下面都是B类的朋友类存在形式

    public class A{
        //....
    }

    成员变量:

    public class B{
        private A a;
    }

    方法参数:

    public class B{
        public void someMethod(A a){...}
    }

    方法返回值:

    public class B{
        public A someMethod(){
            return a;
        }
    }

    需要注意,这种形式存在时,A类不算是B类的朋友类,而是陌生人

    方法中,A类左右局部变量/对象

    public class B{
        public void someMethod(){
            A a = new A();
        }
    }

    理想状态就是这样啦,但真实操作哪有那么理想,类多之后肯定存在或多或少类间直接较互,特别是上面讲的与陌生类交互,该怎么办?迪米特法则建议通过友元类的方式类避免。这里的友元类可以理解为:中介类,也可以理解为一种统一调配的类。下面例子:

    public class C{
        void doWork(){...}
    }
    
    //A不方便直接与C交互
    public class A{
     	public void doWork(){
            C c = new C();
            c.doWork();
        }
    }
    
    //可以借助B
    public class B{
        public void doWork(){
            this.getC().doWork();
        }
    
        public C  getC(){
           return new C();
        }
    }
    
    //改造后的A
    public class A{
        public void doWork(B b){
            b.doWork();
        }
    }

    B为友元类,A借助B类实现与C类的间接交互。

    案例分析

    需求:乘客预约出租车去上班

    //出租车
    public class TaxiCar {
        public void run() {
            System.out.println("司机大叔开始达到目的地....");
        }
    }
    //司机
    public class Driver {
        public TaxiCar getCar() {
            System.out.println("司机大叔按约定时间达到约定地点等待客户...");
            return  new TaxiCar();
        }
    }
    //乘客
    public class Passenger {
        public void goToWork(Driver driver) {
            TaxiCar car = driver.getCar();
            car.run();
        }
    }

    测试:

    //测试
    public class App {
        public static void main(String[] args) {
            //客人
            Passenger p = new Passenger();
            //司机
            Driver driver = new Driver();
            //上班
            p.goToWork(driver);
        }
    }
    结果:
    司机大叔按约定时间达到约定地点等待客户...
    司机大叔开始达到目的地....

    解析

    上面模拟乘客上班场景,乘客预约司机,司机使用出租车送乘客上班。咋一看毛事没有啥问题,细看有点怪怪的,比如Passenger类goToWork方法,传入Driver类之后,通过Driver类的getCar方法,然后在使用TaxiCar类的run方法完成goToWork功能。这里的TaxiCar对于Passenger类是陌生类,违背了迪米特法则不与陌生人交流的要求。

    改进版

    修改后Drvier类

    //司机
    public class Driver {
        //私有
        private TaxiCar getCar() {
            System.out.println("司机大叔按约定时间达到约定地点等待客户...");
            return  new TaxiCar();
        }
        //新增驾车方法
        public void drive(){
            TaxiCar car = getCar();
            car.run();
        }
    }

    修改后Passenger类

    //乘客
    public class Passenger {
        public void goToWork(Driver driver) {
            driver.drive();
        }
    }

    解析:

    改进后的案例就合理多了。Passenger类不需要在意TaxiCar类怎么操作,只需要Driver能完成driver功能即可。Driver使用drive方法遮蔽Passenger类对TaxiCar类直接引用,这符合迪米特法则。

    使用注意

    迪米特法则,对类之间交互的宽度与深度进行限制,正确使用可以提高系统架构复用率跟拓展性。但过度使用迪米特方法,会使用系统产生大量的友元类,从而增加系统的复杂性,使模块之间的通信效率降低。所以,在釆用迪米特法则时要反复权衡,在确保高内聚和低耦合同时,保证系统的结构清晰。

    那实际编码时,需要注意什么呢?一下几点:

    1:设计类时,考虑类间的耦合情况,合理减少类间交互,如果必要可以尝试使用内部类

    2:尽可能使用private访问权限修饰属性成员,不外泄内部信息

    3:满足需求设计前提,可以将类设置成final类

    4:使用JavaBean规范,合理暴露属性成员

    运用

    这次使用shrio身份验证为例子展开讲:

    Shiro进行身份验证涉及到几个参与方:

    Subject : 用户对象抽象类,里面封装用户信息与用户相关动作,比如鉴权与授权委托操作

    UsernameAndPasswordToken:用户身份信息(username, password)封装对象

    SecurityManager :shiro的大管家,负责资源调配

    Realms:数据来源中间对象,负责与数据库,或者其他来源数据对接,转换成shiro可操作对象

    Authentication:身份验证器

    整个身份验证流程

    UsernameAndPasswordToken

    UsernameAndPasswordToken token = new UsernameAndPasswordToken("账号", "密码");

    Subject类

    public void login(AuthenticationToken token) throws AuthenticationException {
        Subject subject = securityManager.login(this, token);
    }

    SecurityManager 类

    public Subject login(Subject subject, AuthenticationToken token) throws AuthenticationException {
        authenticate(token);
    }
    
    public AuthenticationInfo authenticate(AuthenticationToken token) throws AuthenticationException {
        return this.authenticator.authenticate(token);
    }

    Authentication类

    public final AuthenticationInfo authenticate(AuthenticationToken token){
         doAuthenticate(token);
    }
    
    protected AuthenticationInfo doAuthenticate(AuthenticationToken authenticationToken)  {
        assertRealmsConfigured();
        Collection<Realm> realms = getRealms();
        if (realms.size() == 1) {
            return doSingleRealmAuthentication(realms.iterator().next(), authenticationToken);
        } else {
            return doMultiRealmAuthentication(realms, authenticationToken);
        }
    }

    结合上面核心代码,看下,一层一层委托下去,subject的login操作只需要委托给SecurityManager 类操作即可,不需要关注背后如何实现,只跟它朋友类SecurityManager 交互,这就是典型的迪米特法则使用。有兴趣大家跟踪下shiro鉴权操作,大同小异。

    总结

    迪米特法则使用过程中要明确的:

    1:最少知道原则: A类减少与其他类的交互,其他类仅暴露A类需要方法或属性

    2:不与陌生类交互:A类不可避免与陌生类交互,需要合理使用友元类(中介类)

    更多相关内容
  •       迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目。迪米特法则又称为最少知识原则(LeastKnowledge Pri...

          迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目。迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP),其定义如下:

    迪米特法则(Law of  Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用。

          如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。

          迪米特法则还有几种定义形式,包括不要和“陌生人”说话只与你的直接朋友通信等,在迪米特法则中,对于一个对象,其朋友包括以下几类:

          (1) 当前对象本身(this);

          (2) 以参数形式传入到当前对象方法中的对象;

          (3) 当前对象的成员对象;

          (4) 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友;

          (5) 当前对象所创建的对象。

          任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”。在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与“陌生人”发生直接交互,这样做可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。

          迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度

          在将迪米特法则运用到系统设计中时,要注意下面的几点:在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限在类的设计上,只要有可能,一个类型应当设计成不变类在对其他类的引用上,一个对象对其他对象的引用应当降到最低

          下面通过一个简单实例来加深对迪米特法则的理解:

          Sunny软件公司所开发CRM系统包含很多业务操作窗口,在这些窗口中,某些界面控件之间存在复杂的交互关系,一个控件事件的触发将导致多个其他界面控件产生响应,例如,当一个按钮(Button)被单击时,对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变,在初始设计方案中,界面控件之间的交互关系可简化为如图1所示结构:

    图1 初始设计方案结构图

          在图1中,由于界面控件之间的交互关系复杂,导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码,系统扩展性较差,也不便于增加和删除新控件。

          现使用迪米特对其进行重构。

          在本实例中,可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控件之间的耦合度。引入中间类之后,界面控件之间不再发生直接引用,而是将请求先转发给中间类,再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时,只需修改中间类即可,无须修改新增控件或已有控件的源代码,重构后结构如图2所示:

    图2  重构后的结构图

    展开全文
  • 设计模式原则之迪米特法则 迪米特法则(Law of Demeter, LoD)的核心是一个软件实体应当尽可能少地与其他实体发生相互作用。 如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块...

    设计模式原则之迪米特法则

    迪米特法则(Law of Demeter, LoD)的核心是一个软件实体应当尽可能少地与其他实体发生相互作用。

    如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。该法则能够降低系统的耦合度,使类与类之间保持松散的耦合关系。

    米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的 越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内 部。对外除了提供的public 方法,不对外泄露任何信,只与直接的朋友通信 。

    这里的朋友是指,每个对象都会与其他对象有耦合关系(很难做到一丁点关系都没有),只要两个对象之间有耦合关系, 我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合 等。其中,我们某个类称出现另一个类的成员变量,方法参数,方法返回值中的类为直接的朋友,而仅仅出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量 的形式出现在类的内部

    如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

    在将迪米特法则运用到系统设计中时,要注意下面的几点:

    • 在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及;
    • 在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限;
    • 在类的设计上,只要有可能,一个类型应当设计成不变类;
    • 在对其他类的引用上,一个对象对其他对象的引用应当降到最低;
    • 不暴露类的属性成员,而应该提供相应的访问器(set 和 get 方法);
    • 谨慎使用序列化(Serializable)功能。

    应用实例

    有一个学校,下属有各个学院和 总部,现要求打印出学校总部员 工ID和学院员工的id 。

    import java.util.*;
    
    
    
    //学校总部员工类
    class Employee {
    	private String id;
    
    	public void setId(String id) {
    		this.id = id;
    	}
    
    	public String getId() {
    		return id;
    	}
    }
    //学院的员工类
    class CollegeEmployee {
    	private String id;
    
    	public void setId(String id) {
    		this.id = id;
    	}
    
    	public String getId() {
    		return id;
    	}
    }
    //管理学院员工的管理类
    class CollegeManager {
    	//返回学院的所有员工
    	public List<CollegeEmployee> getAllEmployee() {
    		List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
    		for (int i = 0; i < 10; i++) { //这里我们增加了10个员工到 list
    			CollegeEmployee emp = new CollegeEmployee();
    			emp.setId("学院员工id= " + i);
    			list.add(emp);
    		}
    		return list;
    	}
    }
    
    //学校管理类
    
    //分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
    //CollegeEmployee 不是 直接朋友 而是一个陌生类,这样违背了 迪米特法则 
    class SchoolManager {
    	//返回学校总部的员工
    	public List<Employee> getAllEmployee() {
    		List<Employee> list = new ArrayList<Employee>();
    		
    		for (int i = 0; i < 5; i++) { //这里我们增加了5个员工到 list
    			Employee emp = new Employee();
    			emp.setId("学校总部员工id= " + i);
    			list.add(emp);
    		}
    		return list;
    	}
    
    	//该方法完成输出学校总部和学院员工信息(id)
    	void printAllEmployee(CollegeManager sub) {
    		
    		//分析问题
    		//1. 这里的 CollegeEmployee 不是  SchoolManager的直接朋友
    		//2. CollegeEmployee 是以局部变量方式出现在 SchoolManager
    		//3. 违反了 迪米特法则 
    		//获取到学院员工
    		List<CollegeEmployee> list1 = sub.getAllEmployee();
    		System.out.println("------------学院员工------------");
    		for (CollegeEmployee e : list1) {
    			System.out.println(e.getId());
    		}
    		//获取到学校总部员工
    		List<Employee> list2 = this.getAllEmployee();
    		System.out.println("------------学校总部员工------------");
    		for (Employee e : list2) {
    			System.out.println(e.getId());
    		}
    	}
    }
    
    //客户端
    public class Demeter1 {
    
    	public static void main(String[] args) {
    		//创建了一个 SchoolManager 对象
    		SchoolManager schoolManager = new SchoolManager();
    		//输出学院的员工id 和  学校总部的员工信息
    		schoolManager.printAllEmployee(new CollegeManager());
    	}
    }
    
    

    改进思路:

    1. 前面设计的问题在于SchoolManager中,CollegeEmployee类并不是 SchoolManager类的直接朋友 (分析)

    2) 按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合

    import java.util.ArrayList;
    import java.util.List;
    
    
    
    //学校总部员工类
    class Employee {
    	private String id;
    
    	public void setId(String id) {
    		this.id = id;
    	}
    
    	public String getId() {
    		return id;
    	}
    }
    
    
    //学院的员工类
    class CollegeEmployee {
    	private String id;
    
    	public void setId(String id) {
    		this.id = id;
    	}
    
    	public String getId() {
    		return id;
    	}
    }
    
    
    //管理学院员工的管理类
    class CollegeManager {
    	//返回学院的所有员工
    	public List<CollegeEmployee> getAllEmployee() {
    		List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
    		for (int i = 0; i < 10; i++) { //这里我们增加了10个员工到 list
    			CollegeEmployee emp = new CollegeEmployee();
    			emp.setId("学院员工id= " + i);
    			list.add(emp);
    		}
    		return list;
    	}
    	
    	//输出学院员工的信息
    	public void printEmployee() {
    		//获取到学院员工
    		List<CollegeEmployee> list1 = getAllEmployee();
    		System.out.println("------------学院员工------------");
    		for (CollegeEmployee e : list1) {
    			System.out.println(e.getId());
    		}
    	}
    }
    
    //学校管理类
    
    //分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
    //CollegeEmployee 不是 直接朋友 而是一个陌生类,这样违背了 迪米特法则 
    class SchoolManager {
    	//返回学校总部的员工
    	public List<Employee> getAllEmployee() {
    		List<Employee> list = new ArrayList<Employee>();
    		
    		for (int i = 0; i < 5; i++) { //这里我们增加了5个员工到 list
    			Employee emp = new Employee();
    			emp.setId("学校总部员工id= " + i);
    			list.add(emp);
    		}
    		return list;
    	}
    
    	//该方法完成输出学校总部和学院员工信息(id)
    	void printAllEmployee(CollegeManager sub) {
    		
    		//分析问题
    		//1. 将输出学院的员工方法,封装到CollegeManager
    		sub.printEmployee();
    	
    		//获取到学校总部员工
    		List<Employee> list2 = this.getAllEmployee();
    		System.out.println("------------学校总部员工------------");
    		for (Employee e : list2) {
    			System.out.println(e.getId());
    		}
    	}
    }
    
    //客户端
    public class Demeter1 {
    
    	public static void main(String[] args) {
    		System.out.println("~~~使用迪米特法则的改进~~~");
    		//创建了一个 SchoolManager 对象
    		SchoolManager schoolManager = new SchoolManager();
    		//输出学院的员工id 和  学校总部的员工信息
    		schoolManager.printAllEmployee(new CollegeManager());
    
    	}
    
    }
    
    

    迪米特法则注意事项和细节

    1) 迪米特法则的核心是降低类之间的耦合
    2) 但是注意:由于每个类都减少了不必要的依赖,因此迪米特法则只是要求降低 类间(对象间)耦合关系, 并不是要求完全没有依赖关系

    展开全文
  • 如果一个系统满足迪米特法则,那么当其中一个软件实体发生变化时,就会尽量少的影响其他软件实体,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可以...

    一、迪米特法则定义

    迪米特法则又最少知识原则,其定义如下:

    迪米特法则(Law of Demeter, LoD):一个软件实体应当尽可能少的与其他实体发生相互作用。

    二、迪米特法则描述

    如果一个系统满足迪米特法则,那么当其中一个软件实体发生变化时,就会尽量少的影响其他软件实体,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可以降低系统的耦合度,使类与类之间保持松耦合状态。

    迪米特法则还有几种定义形式,包括:不要和"陌生人"说话、只与你的直接朋友通信等,在迪米特法则中,对于一个对象,其朋友包括以下几类:

    • 当前对象本身(this)
    • 以参数形式传入到当前对象方法中的对象
    • 当前对象的成员对象
    • 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友。
    • 当前对象创建的对象

    任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”。在应用迪米特法则时,一个对象只能与直接朋友发生交互,不能与“陌生人”发生直接交互,这样子可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。

    迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象不必直接通信,那么这两个对象就不应该发生任何直接的相互作用,如果其中一个对象需要调用另外一个对象的某个方法时,可以通过第三者转发这个调用。就是通过引入一个合理的第三者来降低先有对象之间的耦合度

    在迪米特法则运用到系统设计中时,要注意以下几点:

    • 在类的划分上,应该尽可能的创建松耦合的类,类之间的耦合度越低,复用率越高,一个松耦合的类发生修改不会对关联的类造成太大的影响。
    • 在类的结构设计上,每一个类都应当尽可能的降低其成员变量和成员方法的访问权限。
    • 在类的设计上,只要有可能,一个类型应当设计成不变类。
    • 在对其他类的引用上,一个对象对其他对象的引用应该降到最低。

    三、迪米特法则栗子

    栗子一

    以下是关于关闭计算机的很经典的案例,当我们手动按下计算机的关闭按钮时,电脑还会附带其他的动作,比如关闭电脑正在执行的任务,关闭其他运行的程序,然后关闭显示器,最后才把电源关闭。

    不满足迪米特法则
    public class Computer {
        public void saveCurrentTask() {
            // do something
        }
        
        public void closeService() {
            // do something
        }
        
        public void closeScreen() {
            // do something
        }
        
        public void closePower() {
            // do something
        }
        
        public void close() {
           saveCurrentTask();
           closeService();
           closeScreen();
           closePower();
        }
    }
    
    public class Person {
        private Computer computer;
        
        public void clickCloseButton() {
            // 关闭计算机, 正常来说你只要调用close()方法即可
            // 但是你发现Computer类所有的方法都是公开的, 不知道怎么调用了
            computer.saveCurrentTask();
            computer.closePower();
            computer.close();
            
            //也可以是
            computer.closePower();
            
            //还可以是
            computer.close();
            computer.closePower();
        }
    }
    

    通过以上的代码我们可以看出,人这个类在调用电脑类的方法时发现电脑类暴露的方法有很多,不知道该调用哪一个,很明显,电脑这个类中的方法有些杂乱,对于我们人来说,我们只需要调用关闭电脑的操作,关闭电脑的方法就可以了,其他的方法完全没有必要暴露在外。

    满足迪米特法则

    根据迪米特法则只暴露该暴露的方法的要义作出如下修改:

    public class Computer {
        private void saveCurrentTask() {
            // do something
        }
        
        private void closeService() {
            // do something
        }
        
        private void closeScreen() {
            // do something
        }
        
        private void closePower() {
            // do something
        }
        
        public void close() {
           saveCurrentTask();
           closeService();
           closeScreen();
           closePower();
        }
    }
    
    public class Person {
        private Computer computer;
        
        public void clickCloseButton() {
            computer.close();
        }
    }
    

    栗子二

    明星与经纪人的例子,像我们普通的明星工作繁忙,他的日常工作、日程安排都是由那个经纪人带做,明星是不可能自己亲力亲为的,不然的话会很累。

    不满足迪米特法则
    public class Star {
        private Project project;
     
        public void do() {
            project.make();
        }
    }
    
    public class Project {
        public void make() {
            // do something
        }
    }
    

    上面代码明星直接和安排行程直接有关系了,按道理明星不可能自己亲力亲为,这个时候就可以通过引入一个经纪人类将明星和行程关联起来,任何事物都交由经纪人类代为安排,这样的话便符合最小依赖原则,明星类只依赖经纪人类,改造如下:

    满足迪米特法则
    public class Star {
        private Business business;
     
        public void do() {
            business.do();
        }
    }
    
    public class Business {
        private Project project;
     
        public void do() {
            project.make();
        }
    }
    
    public class Project {
        public void make() {
            // do something
        }
    }
    
    展开全文
  • 迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)
  • 设计原则-迪米特法则

    2016-11-14 00:00:00
    等, 在迪米特法则中, 对于一个对象他的朋友包括以下几类: 当前对象本身. 以参数形式传入当前对象/方法中的对象. 当前对象的成员对象. 如果当前对象的成员对象是一个集合, 那么集合中的元素也都是朋友. ...
  • 设计模式6大原则-迪米特法则 定义:迪米特法则也称为最少知识原则,一个对象应该对其他对象有最少的了解,迪米特法则的一个英文解释为: Only talk to your immediate friends (只和你最亲近的朋友交谈)。 一个类...
  • 迪米特法则 定义:一个对象应该对其他对象保持最少的了解。 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越...如果一个系统符合迪米特法则,那么当其中某一个模块发...
  • 定义 一个软件实体应当尽可能少地与其他实体发生相互作用。 详细概述 迪米特法则又叫最少知道原则,通俗的来讲,就是一个类对自己...迪米特法则可降低系统耦合度,使类与类之间保持松散的耦合关系。 其他定义形式 ...
  • 一、定义 迪米特法则的定义是:只与...迪米特法则中的“朋友”是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些
  • 一、原则:  如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发...过渡使用迪米特法则会使系统产生大量的中介类,从而增加系统的复杂性,使模块之间的通信效率降低。所以,采用...
  • 迪米特法则

    2021-05-07 18:21:23
    迪米特法则中的“朋友”是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。 迪米特法则的优点: ...
  • 一、迪米特法则的定义 迪米特法则,也称为最少知识原则,虽然名字不同,但描述的是同一个规则:一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,被耦合或调用的类的...
  • 迪米特法则的定义 迪米特法则(Law of Demeter,LoD)又叫作最少知识原则(Least Knowledge Principle,LKP),产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目,由...
  • 设计模式选择题复习

    2022-05-16 21:00:22
    1.UML提供的图,( )用于描述系统与外部系统及用户之间的交互 A.用例图 B.类图 C.对象图 D.部署图 2.UML提供的图,( )用于按时间顺序描述对象之间的交互。 A、对象图 B、状态图 C、活动图 D、时序图 ...
  • 迪米特法则一个叫做迪米特的项目提出来的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫做最少知识原则。迪米特法则的意义是降低类之间的耦合,由于每个对象应该尽量减少对其他对象的了解,...
  • 迪米特法则,又作最少知道原则,着眼于降低类之间的耦合。
  • 迪米特法则的定义 迪米特法则(Law of Demeter,LoD)又叫作最少知识原则(Least Knowledge Principle,LKP),产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目,由...
  • 一、概述 引入一个外观角色来简化客户端与子系统之间的交互,为复杂的子系统调用提供一个统一的入口。...外观模式又称为门面模式,是迪米特法则的一种具体实现。 二、结构与实现 结构 (1)Facade类: 客户
  • SRP原则侧重高内聚,指导类功能的设计要单一,LOD法则侧重低耦合,指导类间依赖关系要松耦合,ISP原则是从调用者的角度出发确保接口的设计具备对调用者有良好的隔离性。基于接口而非实现编程思想也是从调用者的角度...
  • 1 迪米特法则概述 迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项 目。迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP),其定义如下: 迪米特法则:每...
  • 设计模式之六大原则之——接口隔离原则详解 1、接口隔离原则(Interface Segregation Principle,ISP) 概念 将接口隔离原则之前,首先要明确“接口”的概念,接口分为两种: 实力接口 Java通过new关键子...
  • 迪米特法则 开闭原则 迪米特法则定义 一个对象应该对其他对象有最少的了解。 通俗地讲, 一个类应该对自己需要耦合或调用的类知道得最少, 你(被耦合或调用的类) 的内部是如何复杂都和我没关系, 那是你的事情...
  • 迪米特法则解决类与类之间耦合度问题,如果类A调用了B类的某一个方法,则这两个类就形成了一种紧耦合的方式,当B类这个方法发生变化时,一定会影响A类的执行结果。迪米特法则要求每一个类尽可能少的与其他类发生关系...
  • 设计原则_迪米特法则

    2018-09-04 00:23:11
    迪米特法则(Law of Demeter ,LoD)也称为最少知识原则(Least Knowlege Principle,LKP),虽然名字不同,但描述的是同一个规则:一个对象应该对其他对象有最少的了解。 二、优势 强调类间解耦,增强程序的复用性...
  • 迪米特法则的英文翻译是:Law of Demeter,缩写是 LOD。它还有另外一个更加达意的名字,叫作最小知识原则,英文翻译为:The Least Knowledge Principle。 简言之,不该有直接依赖关系的类之间,不要有依赖;有依赖...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,855
精华内容 5,142
热门标签
关键字:

在系统设计中应用迪米特法则