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

简介: 设计模式六大原则(五)----迪米特法则

一. 什么是迪米特法则



迪米特法则(Law of Demeter )又叫做最少知识原则,也就是说,一个对象应当对其他对象尽可能少的了解。不和陌生人说话。英文简写为: LoD。


迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系。


迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系,也希望能通过它的友元类来转达。因此,应用迪米特法则有可能造成的一个后果就是:系统中存在大量的中介类,这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。


二. 为什么要遵守迪米特法则?



在面向对象编程中有一些众所周知的抽象概念,比如封装、内聚和耦合,理论上可以用来生成清晰的设计和良好的代码。虽然这些都是非常重要的概念,但它们不够实用,不能直接用于开发环境,这些概念是比较主观的,非常依赖于使用人的经验和知识。对于其他概念,如单一责任原则、开闭原则等,情况也是一样的。迪米特法则的独特之处在于它简洁而准确的定义,它允许在编写代码时直接应用,几乎自动地应用了适当的封装、低内聚和松耦合。


三. 迪米特法则的广狭义



3.1. 狭义的迪米特法则


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

朋友圈的确定“朋友”条件:


1)当前对象本身(this)


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


方法入参是一个对象, 这是这个对象和当前类是朋友


3)当前对象的实例变量直接引用的对象


定一个一个类, 里面的属性引用了其他对象, 那么这个对象的实例和当前实例是朋友


4)当前对象的实例变量如果是一个聚集,那么聚集中的元素也都是朋友


如果属性是一个对象, 那么属性和对象里的元素都是朋友


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

任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”;否则就是“陌生人”。

狭义的迪米特法则的缺点:

在系统里造出大量的小方法,这些方法仅仅是传递间接的调用,与系统的业务逻辑无关。

遵循类之间的迪米特法则会是一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有直接的关联。但是,这也会造成系统的不同模块之间的通信效率降低,也会使系统的不同模块之间不容易协调。


2. 广义的迪米特法则在类的设计上的体现:


优先考虑将一个类设置成不变类。
  尽量降低一个类的访问权限。
  谨慎使用Serializable。
  尽量降低成员的访问权限。

四. 迪米特法则在设计模式中的应用



设计模式的门面模式(Facade)和中介模式(Mediator),都是迪米特法则的应用

下面我们已经租房为例, 来研究迪米特法则.


通常 客户要找房子住, 我们就直接建一个房子类, 建一个客户类, 客户找房子即可.


public interface IHouse {
    // 住房子
    public void Housing();
}
public class House implements IHouse{
    @Override
    public void Housing() {
        System.out.println("住房子");
    }
}
public class Customer {
    public String name;
    public void findHourse(IHouse house) {
        house.Housing();
    }
}

客户找房子住, 逻辑很简单, 这样是ok的. 虽然违背了迪米特法则, 但符合业务逻辑也说得通.


但是, 通常我们找房子, 不是一下子就能找到的, 我们要找很多家, 这就很费劲, 那不如交给中介. 中介有很多房源, 房东吧房子给了中介, 不需要关心租户是谁, 租户将找房的事交给房东, 他也不用管房东是谁, 而且租户+房东都很省事.


/**
 * 房子
 */
public interface IHouse {
    // 住房子
    public void Housing();
}
public class House implements IHouse{
    @Override
    public void Housing() {
        System.out.println("住房子");
    }
}
public interface ICustomer {
    void findHourse(IHouse house) ;
}
public class Customer implements ICustomer {
    public void findHourse(IHouse house) {
        house.Housing();
    }
}
/**
 * 中介
 */
public class Intermediary {
    // 找房子
    public IHouse findHouse(ICustomer customer){
        // 帮租户找房子
        return null;
    }
}

房子,客户是相互独立的, 彼此之间没有引用. 他们之间建立关系是通过中介. 也就是, 客户找中介租房子, 房东吧房子交给租户, 最后中介将找好的房子给到客户. 客户和房东彼此隔离, 符合迪米特法则.


五. 迪米特法则实践



那么在实践中如何做到一个对象应该对其他对象有最少的了解呢?如果我们把一个对象看作是一个人,那么要实现“一个人应该对其他人有最少的了解”,做到两点就足够了:


1.只和直接的朋友交流;


2.减少对朋友的了解。下面就详细说说如何做到这两点。


1. 只和直接的朋友交流


迪米特法则还有一个英文解释是:talk only to your immediate friends(只和直接的朋友交流)。


什么是朋友呢?


每个对象都必然会与其他的对象有耦合关系,两个对象之间的耦合就会成为朋友关系。那么什么又是直接的朋友呢?出现在成员变量方法的输入输出参数中的类就是直接的朋友。迪米特法则要求只和直接的朋友通信。


注意:


只出现在方法体内部的类就不是直接的朋友,如果一个类和不是直接的朋友进行交流,就属于违反迪米特法则。

我们举一个例子说明什么是朋友,什么是直接的朋友。很简单的例子:老师让班长清点全班同学的人数。这个例子中总共有三个类:老师Teacher、班长GroupLeader和学生Student。


public interface ITeacher {
    void command(IGroupLeader groupLeader);
}
public class Teacher implements ITeacher{
    @Override
    public void command(IGroupLeader groupLeader) {
        // 全班同学
        List<Student> allStudent = new ArrayList<>();
        allStudent.add(new Student());
        allStudent.add(new Student());
        allStudent.add(new Student());
        allStudent.add(new Student());
        allStudent.add(new Student());
        // 班长清点人数
        groupLeader.count(allStudent);
    }
}
**
 * 班长类
 */
public interface IGroupLeader {
    // 班长清点人数
    void count(List<Student> students);
}
/**
 * 班长类
 */
public class GroupLeader implements IGroupLeader{
    /**
     * 班长清点人数
     * @param students
     */
    @Override
    public void count(List<Student> students) {
        // 班长清点人数
        System.out.println("上课的学生人数是: " + students.size());
    }
}
/**
 * 学生类
 */
public interface IStudent {
}
/**
 * 学生类
 */
public class Student implements IStudent {
}
/**
 * 客户端
 */
public class Client {
    public static void main(String[] args) {
        // 老师类
        ITeacher wangTeacher = new Teacher();
        // 班长
        IGroupLeader zhangBanzhang = new GroupLeader();
        wangTeacher.command(zhangBanzhang);
    }
}

运行结果:


上课的学生人数是: 5

在这个例子中,我们的Teacher有几个朋友?两个,一个是GroupLeader,它是Teacher的command()方法的入参;另一个是Student,因为在Teacher的command()方法体中使用了Student。


那么Teacher有几个是直接的朋友?按照直接的朋友的定义


出现在成员变量、方法的输入输出参数中的类就是直接的朋友

只有GroupLeader是Teacher的直接的朋友。


Teacher在command()方法中创建了Student的数组,和非直接的朋友Student发生了交流,所以,上述例子违反了迪米特法则。方法是类的一个行为,类竟然不知道自己的行为与其他的类产生了依赖关系,这是不允许的,严重违反了迪米特法则


为了使上述例子符合迪米特法则,我们可以做如下修改:


public interface ITeacher {
    void command(IGroupLeader groupLeader);
}
public class Teacher implements ITeacher {
    @Override
    public void command(IGroupLeader groupLeader) {
        // 班长清点人数
        groupLeader.count();
    }
}
/**
 * 班长类
 */
public interface IGroupLeader {
    // 班长清点人数
    void count();
}
/**
 * 班长类
 */
public class GroupLeader implements IGroupLeader {
    private List<Student> students;
    public GroupLeader(List<Student> students) {
        this.students = students;
    }
    /**
     * 班长清点人数
     */
    @Override
    public void count() {
        // 班长清点人数
        System.out.println("上课的学生人数是: " + students.size());
    }
}
/**
 * 学生类
 */
public interface IStudent {
}
/**
 * 学生类
 */
public class Student implements IStudent {
}
/**
 * 客户端
 */
public class Client {
    public static void main(String[] args) {
        // 老师类
        ITeacher wangTeacher = new Teacher();
        List<Student> allStudent = new ArrayList(10);
        allStudent.add(new Student());
        allStudent.add(new Student());
        allStudent.add(new Student());
        allStudent.add(new Student());
        // 班长
        IGroupLeader zhangBanzhang = new GroupLeader(allStudent);
        wangTeacher.command(zhangBanzhang);
    }
}

运行结果:

上课的学生人数是: 4


这样修改后,每个类都只和直接的朋友交流,有效减少了类之间的耦合


2. 减少对朋友的了解


如何减少对朋友的了解?如果你的朋友是个话痨加大喇叭,那就算你不主动去问他,他也会在你面前说个不停,把他所有的经历都讲给你听。所以,要减少对朋友的了解,请换一个内敛一点的朋友吧~换作在一个类中,就是尽量减少一个类对外暴露的方法。


举一个简单的例子说明一个类暴露方法过多的情况。一个人用咖啡机煮咖啡的过程,例子中只有两个类,一个是人,一个是咖啡机。


首先是咖啡机类CoffeeMachine,咖啡机制作咖啡只需要三个方法:1.加咖啡豆;2.加水;3.制作咖啡:


/**
 * 咖啡机抽象接口
 */
public interface ICoffeeMachine {
    //加咖啡豆
    void addCoffeeBean();
    //加水
    void addWater();
    //制作咖啡
    void makeCoffee();
}
/**
 * 咖啡机实现类
 */
public class CoffeeMachine implements ICoffeeMachine{
    //加咖啡豆
    public void addCoffeeBean() {
        System.out.println("放咖啡豆");
    }
    //加水
    public void addWater() {
        System.out.println("加水");
    }
    //制作咖啡
    public void makeCoffee() {
        System.out.println("制作咖啡");
    }
}
/**
 * 人, 制作咖啡
 */
public interface IMan {
    /**
     * 制作咖啡
     */
    void makeCoffee();
}
/**
 * 人制作咖啡
 */
public class Man implements IMan {
    private ICoffeeMachine coffeeMachine;
    public Man(ICoffeeMachine coffeeMachine) {
        this.coffeeMachine = coffeeMachine;
    }
    /**
     * 制作咖啡
     */
    public void makeCoffee() {
        coffeeMachine.addWater();
        coffeeMachine.addCoffeeBean();
        coffeeMachine.makeCoffee();
    }
}
/**
 * 客户端
 */
public class Client {
    public static void main(String[] args) {
        ICoffeeMachine coffeeMachine = new CoffeeMachine();
        IMan man = new Man(coffeeMachine);
        man.makeCoffee();
    }
}

运行结果:

加水


放咖啡豆


制作咖啡

在这个例子中,CoffeeMachine是Man的直接好友,但问题是Man对CoffeeMachine了解的太多了,其实人根本不关心咖啡机具体制作咖啡的过程。所以我们可以作如下优化:

优化后的咖啡机类,只暴露一个work方法,把制作咖啡的三个具体的方法


addCoffeeBean、addWater、makeCoffee设为私有:

/**
 * 咖啡机抽象接口
 */
public interface ICoffeeMachine {
    //咖啡机工作
    void work();
}
/**
 * 咖啡机实现类
 */
public class CoffeeMachine implements ICoffeeMachine {
    //加咖啡豆
    public void addCoffeeBean() {
        System.out.println("放咖啡豆");
    }
    //加水
    public void addWater() {
        System.out.println("加水");
    }
    //制作咖啡
    public void makeCoffee() {
        System.out.println("制作咖啡");
    }
    @Override
    public void work() {
        addCoffeeBean();
        addWater();
        makeCoffee();
    }
}
/**
 * 人, 制作咖啡
 */
public interface IMan {
    /**
     * 制作咖啡
     */
    void makeCoffee();
}
/**
 * 人制作咖啡
 */
public class Man implements IMan {
    private ICoffeeMachine coffeeMachine;
    public Man(ICoffeeMachine coffeeMachine) {
        this.coffeeMachine = coffeeMachine;
    }
    /**
     * 制作咖啡
     */
    public void makeCoffee() {
        coffeeMachine.work();
    }
}
/**
 * 客户端
 */
public class Client {
    public static void main(String[] args) {
        ICoffeeMachine coffeeMachine = new CoffeeMachine();
        IMan man = new Man(coffeeMachine);
        man.makeCoffee();
    }
}

这样修改后,通过减少CoffeeMachine对外暴露的方法,减少Man对CoffeeMachine的了解,从而降低了它们之间的耦合。


在实践中,只要做到只和直接的朋友交流和减少对朋友的了解,就能满足迪米特法则。因此我们不难想象,迪米特法则的目的,是把我们的类变成一个个“肥宅”。“肥”在于一个类对外暴露的方法可能很少,但是它内部的实现可能非常复杂(这个解释有点牵强~)。“宅”在于它只和直接的朋友交流。在现实生活中“肥宅”是个贬义词,在日本“肥宅”已经成为社会问题。但是在程序中,一个“肥宅”的类却是优秀类的典范。


六. 注意事项


第一:在类的划分上,应当创建弱耦合的类,类与类之间的耦合越弱,就越有利于实现可复用的目标。
第二:在类的结构设计上,每个类都应该降低成员的访问权限。
第三:在类的设计上,只要有可能,一个类应当设计成不变的类。
第四:在对其他类的引用上,一个对象对其他类的对象的引用应该降到最低。
第五:尽量限制局部变量的有效范围,降低类的访问权限。
相关文章
|
2月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
2月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
29天前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
设计模式——设计模式简介和七大原则
|
2月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
2月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
2月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
4月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
30 2
|
4月前
|
设计模式 Java 数据库
深入理解设计模式六大原则
深入理解设计模式六大原则
|
15天前
|
设计模式 数据库连接 PHP
PHP中的设计模式:提升代码的可维护性与扩展性在软件开发过程中,设计模式是开发者们经常用到的工具之一。它们提供了经过验证的解决方案,可以帮助我们解决常见的软件设计问题。本文将介绍PHP中常用的设计模式,以及如何利用这些模式来提高代码的可维护性和扩展性。我们将从基础的设计模式入手,逐步深入到更复杂的应用场景。通过实际案例分析,读者可以更好地理解如何在PHP开发中应用这些设计模式,从而写出更加高效、灵活和易于维护的代码。
本文探讨了PHP中常用的设计模式及其在实际项目中的应用。内容涵盖设计模式的基本概念、分类和具体使用场景,重点介绍了单例模式、工厂模式和观察者模式等常见模式。通过具体的代码示例,展示了如何在PHP项目中有效利用设计模式来提升代码的可维护性和扩展性。文章还讨论了设计模式的选择原则和注意事项,帮助开发者在不同情境下做出最佳决策。
|
29天前
|
设计模式 算法 安全
设计模式——模板模式
模板方法模式、钩子方法、Spring源码AbstractApplicationContext类用到的模板方法
设计模式——模板模式

热门文章

最新文章