迪米特法则：参数方法及代码合规性咨询

嘿，这个问题问得特别精准，刚好摸到了迪米特法则（Law of Demeter）里最容易搞混的边界点～咱们先把核心逻辑理清楚，再针对你的场景分析：

首先，你对迪米特法则的核心理解是对的——它本质就是要减少模块间的耦合，让每个类只和自己的「直接朋友」打交道。你提到的可调用类集合也是准确的：

• 当前类本身（比如你的Car类）
• 方法的参数类
• 当前类的实例变量所属类
• 方法内部创建的对象
• 方法的返回值类（补充一个你没提到的直接朋友范畴）

接下来回到你的疑问：通过Car类自身的方法对Truck进行操作，是否符合法则？

答案是：取决于这个Truck是怎么来的——只要它是Car的「直接朋友」，就完全符合；如果是通过「非直接朋友」间接拿到的，就违反了。

举两个具体的代码例子对比：

符合迪米特法则的情况 #

public class Car {
    // Truck是Car的实例变量，属于直接朋友
    private Truck myTruck;

    public void loadGoods() {
        // 通过Car自身方法操作Truck，完全合规
        myTruck.loadCargo();
    }
}

或者如果Truck是方法参数传入的：

public class Car {
    public void helpLoad(Truck truck) {
        // Truck是方法参数，直接朋友，操作它没问题
        truck.loadCargo();
    }
}

违反迪米特法则的情况 #

public class Car {
    private Garage myGarage;

    public void loadGoods() {
        // 这里的Truck是通过Garage间接获取的，Garage是Car的直接朋友，但Truck不是
        Truck truck = myGarage.getTruck();
        truck.loadCargo(); // 违反：和陌生人（Truck）直接说话了
    }
}

简单总结一下：你说的「通过Car自身方法操作Truck」，只要这个Truck是Car自己的实例变量、方法参数、或者方法内部new出来的，就完全符合迪米特法则；但如果是通过另一个对象（比如Garage）的方法返回的，那就踩坑了。

内容的提问来源于stack exchange，提问作者tara