设计原则之迪米特原则

设计原则之迪米特原则

1、概念

• 狭义定义：迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP）。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

• 广义定义：一个模块设计得好坏的一个重要的标志就是该模块在多大的程度上将自己的内部数据与实现有关的细节隐藏起来。信息的隐藏非常重要的原因在于，它可以使各个子系统之间脱耦，从而允许它们独立地被开发、优化、使用阅读以及修改。

2、主张

（1）在类的划分上，应该创建有弱耦合的类，即只与直接朋友交流：

两个对象之间的耦合关系称之为朋友，耦合关系通常有依赖、关联、聚合和组成等。直接朋友则通常表现为关联、聚合和组成关系，即两个对象之间联系更为紧密，通常以成员变量，方法的参数和返回值的形式出现。而出现在方法体内部的类不属于朋友类。

（2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限；

在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

（3）在类的设计上，只要有可能，一个类应当设计成不变类；

（4）在对其他类的引用上，一个对象对其它对象的引用应当降到最低；

（5）谨慎使用序列化功能；

（6）不要暴露类成员，而应该提供相应的访问器(属性)。

3、代码演示，简单示例

/**
 * @Author: css
 * @Description: 迪米特原则
 * @Date:2019-07-29
 */
public class Demeter {

        public static void main(String[] args) {
            Phone phone = new Phone();
            phone.listenSongs();
        }

    }
    /**
     * 手机内有App,App可以听歌
     */
    class Phone {

        private App app = new App();

        public void listenSongs() {
            app.listen();
        }

    }
    /**
    * App内才可以看到歌曲名称
    */
    class App {
        
        private Song song = new Song("一个像夏天一个像秋天");

        public void listen() {
            System.out.println(song.getTitle());
        }

    }
    /**
    * 歌曲详情
    */
    class Song {

        private String title;

        public Song(String title) {
            this.title = title;
        }
        public String getTitle() {
            return title;
        }
        public void setTitle(String title) {
            this.title = title;
        }

}

4、优缺点

• 优点：让类之间解耦，降低耦合度，提高类的复用性，使类具有很好的可读性和可维护性。
• 缺点：会产生大量的中转类或跳转类，导致系统的复杂度提高，而且通信效率会降低。