迪米特原则

一，介绍

1.前言

迪米特原则（Law of Demeter，简称LoD）也被称为最少知识原则（Least Knowledge Principle，LKP），是面向对象设计的一种重要原则。迪米特原则的核心思想是尽量减少对象之间的交互，使得系统中的模块能够相对独立地变化。

迪米特原则最初是由Ian Holland和Richard Gabriel在1987年的OOPSLA（Object-Oriented Programming, Systems, Languages & Applications）会议上提出的，并由C. J. Date和Barbara Liskov进一步发展完善。迪米特原则被广泛应用于软件设计、系统架构等领域，并成为面向对象设计中的一个重要原则之一。

迪米特原则的核心思想可以用“不要和陌生人说话”来形象地概括。也就是说，一个对象应该尽可能地减少与其他对象之间的直接交互，只与它所认识的朋友类进行交互。朋友类包括两种：一种是当前对象本身，另一种是当前对象所持有的对象（成员变量）、方法参数中传入的对象、或内部创建的对象等。

迪米特原则的优点在于：

- 降低类之间的耦合度，使得系统更加灵活，易于维护和扩展。

- 促进类的复用，提高代码的重用性和可读性。

- 提高系统的稳定性和安全性，减少由于类之间直接交互而带来的风险。

迪米特原则的实现主要有以下几种方式：

1. 只与朋友类交互。即一个类只与自己的成员、参数、返回值中所涉及到的类进行交互，而不直接与其他类进行交互。

2. 封装类的内部细节。即一个类不应该暴露其内部的实现细节，只提供必要的接口进行交互。

3. 引入第三方代理。即通过引入一个中间类来封装和隔离两个不同的类之间的交互。

2.何时使用米莱迪原则

1. 当一个类或模块承担了过多的功能或任务，导致其代码的可读性、可维护性和可测试性降低时，我们可以使用米莱迪原则来拆分这个类或模块，使其承担更加明确的单一责任。
   
2. 当我们需要修改一个类或模块时，如果这个类或模块承担了多种不相关的责任，那么修改的影响范围可能会很大，也容易引入错误。在这种情况下，使用米莱迪原则将这个类或模块拆分成多个承担单一责任的小模块，可以降低修改的风险和成本。
   
3. 当我们需要进行代码重构时，根据米莱迪原则对代码进行重组和重构，可以使代码更加清晰、易于理解和维护。同时，这也可以避免模块之间的耦合和依赖过度，提高系统的可扩展性和灵活性。
   

二，代码示例

下面以一个简单的例子来说明迪米特原则：

public class Person {
    private String name;
    private List<Friend> friends;
    public Person(String name, List<Friend> friends) {
        this.name = name;
        this.friends = friends;
    }
    public void sendGifts(Friend friend) {
        System.out.println(name + " is sending gifts to " + friend.getName());
    }
    public void sendGiftsToAll() {
        for (Friend friend : friends) {
            sendGifts(friend);
        }
    }
}
public class Friend {
    private String name;
    public Friend(String name) {
        this.name = name;
    }
    public String getName() {
        return name;
    }
}

在这个例子中，`Person`类尝试给自己的好友们送礼物。`Person`类持有一个`List`类型的`friends`成员变量，表示它的朋友列表。在`sendGiftsToAll`方法中，`Person`类遍历它的所有好友，并调用`sendGifts`方法给每个好友送礼物。

然而，这个设计违反了迪米特原则。`Person`类直接操作`Friend`对象，即它和陌生的`Friend`类直接进行交互。这样做的问题在于`Person`类对`Friend`类的依赖过于紧密，增加了系统的耦合性。如果系统需要修改`Friend`类或者更换成其他类型的好友，那么就会导致`Person`类的修改，从而影响整个系统的稳定性和安全性。

为了符合迪米特原则，我们可以通过引入中间类来隔离`Person`类和`Friend`类之间的交互。具体做法是在`Person`类中引入`GiftSender`类，让`GiftSender`类来负责处理礼物的送出：

public class Person {
    private String name;
    private List<Friend> friends;
    public Person(String name, List<Friend> friends) {
        this.name = name;
        this.friends = friends;
    }
    public void sendGiftsToAll(GiftSender giftSender) {
        for (Friend friend : friends) {
            giftSender.sendGifts(name, friend);
        }
    }
}
public class GiftSender {
    public void sendGifts(String senderName, Friend friend) {
        System.out.println(senderName + " is sending gifts to " + friend.getName());
    }
}

在这个设计中，`Person`类不再直接操作`Friend`对象，而是通过`GiftSender`类来进行交互。`GiftSender`类只对外公开一个方法`sendGifts`，它是`Person`类的朋友类，负责处理礼物的送出。这样做的好处在于，如果系统需要更换成其他类型或者更改礼物送出的方式，只需要修改`GiftSender`类即可，`Person`类无需做出任何修改，从而减少了系统维护的成本。

总之，迪米特原则要求我们尽量减少对象之间的交互，使得系统中的模块能够相对独立地变化。通过遵循迪米特原则，我们可以降低类之间的耦合度，提高系统的灵活性、扩展性和可维护性，从而实现更加优秀的软件设计。

三，优缺点

迪米特原则（Law of Demeter，LoD），也被称为最少知识原则（Principle of Least Knowledge），是面向对象设计的一个原则，它强调一个对象应该尽量减少与其他对象之间的交互，只与直接的朋友进行通信。迪米特原则具有以下优点和缺点：

优点：

1. 降低耦合度：迪米特原则要求一个对象只与其直接的朋友发生交互，而不需要了解其他对象的内部细节。这降低了对象之间的耦合度，使得系统更加灵活、可扩展和易于维护。

2. 提高模块的独立性：根据迪米特原则，对象只与其直接的朋友进行通信，而不需要与其他对象产生联系。这使得每个模块具有较高的独立性，可以更容易地被理解、修改和重用。

3. 增强了系统的可测试性：由于对象之间的耦合度降低，模块间的依赖减少，提高了系统的可测试性。我们可以更容易地对单个模块进行测试，而不需要关注其依赖的其他模块。

4. 减少了代码的脆弱性：当一个对象只与其直接的朋友进行通信时，即使其他对象发生变化，也不会对该对象产生直接的影响。这减少了代码的脆弱性，使得系统更加健壮和稳定。

缺点：

1. 增加了消息传递的复杂性：迪米特原则要求对象只与其直接的朋友进行通信，这可能增加了消息传递的复杂性。需要引入额外的中间对象作为消息的传递者，导致系统的结构变得复杂。

2. 可能导致过多的中间对象：为了减少对象之间的直接交互，可能会引入过多的中间对象。这增加了系统的复杂性和维护成本，也会影响系统的性能。

3. 可能破坏封装性：迪米特原则强调对象只与其直接的朋友进行通信，这可能会泄露一些内部的实现细节，破坏了对象的封装性。

总结起来，迪米特原则通过降低对象之间的耦合度、提高模块的独立性和可测试性来改善软件系统的设计质量。然而，它也可能增加消息传递的复杂性、引入过多的中间对象，并破坏封装性。因此，在应用迪米特原则时需要权衡利弊，根据具体的设计需求和实际情况选择适合的设计方案。