设计原则(5) : 迪米特法则

2019-01-13  本文已影响0人  a_salt_fish

一个对象应该对其他对象保持最少的了解(又叫最少知道原则)


朋友指出现在成员变量, 方法的输入输出参数的类称为朋友类, 方法体中出现的类不是朋友类


老板发布任务给主管,主管接收任务下发给员工完成任务.
Boss

public class Boss {
    public void plan(Manager manager, String plan){
        Employ employ = new Employ();
        manager.releaseTask(employ, plan);
    }
}

主管

public class Manager {
    public void releaseTask(Employ employ, String plan) {
        employ.work(plan);
    }
}

员工

public class Employ {
    public void work(String plan) {
        System.out.println("employ do " + plan);
    }
}

测试

public class Test {
    public static void main(String[] args) {
        Boss boss = new Boss();
        Manager manager = new Manager();
        boss.plan(manager, "5万亿");
    }
}

run , 没问题 一个5万亿的项目完成了,但是我们看一下Boss类, 这个类中我们创建了一个员工,然后由主管给该员工发布任务, 但在实际生活中, 老板是完全不用关心员工的, 老板只需要对主管发布任务即可, 跟员工沟通是主管的事情. 这明显违背了迪米特法则,因为我们在Boss类中import进了一个Boss完全不关心的员工类.


改进一下, 第二版,我们只需修改Boss 和 Manager类
Boss类只需要让管理员知道任务

public class Boss2 {
    public void plan(Manager2 manager, String plan){
        manager.releaseTask(plan);
    }
}

主管负责找人完成任务

public class Manager2 {
    public void releaseTask(String plan) {
        Employ employ = new Employ();
        employ.work(plan);
    }
}

再次运行

public class Test2 {
    public static void main(String[] args) {
        Boss2 boss = new Boss2();
        Manager2 manager = new Manager2();
        boss.plan(manager, "5万亿");
    }
}

完成!


迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。

但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系,例如本例中,总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。

过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。

github源码

上一篇下一篇

猜你喜欢

热点阅读