迪米特法则与重构

在面向对象设计的世界里，有一个寻常却又常常为人所忽略的原则——“迪米特（Law of Demeter）”法则。这个原则认为，任何一个对象或者方法，它应该只能调用下列对象：

该对象本身
作为参数传进来的对象（也可以是该对象的字段）
在方法内创建的对象

这个原则用以指导正确的对象协作，分清楚哪些对象应该产生协作，哪些对象则对于该对象而言，又应该是无知的。如何理解这个原则？我们可以看看David Bock就该原则给出的一个绝佳案例。假设一个超市购物的场景，顾客（Customer）到收银台结账，收银员（Paper Boy）负责收钱。我们来看看代码：

public class Customer {
    private String firstName;
    private String lastName;
    private Wallet myWallet;
    public String getFirstName(){
        return firstName;
    }
    public String getLastName(){
        return lastName;
    }
    public Wallet getWallet(){
        return myWallet;
    }
}

public class Wallet {
    private float value;
    public float getTotalMoney() {
        return value;
    }
    public void setTotalMoney(float newValue) {
        value = newValue;
    }
    public void addMoney(float deposit) {
        value += deposit;
    }
    public void subtractMoney(float debit) {
        value -= debit;
    }
}

public class Paperboy {
    public void charge(Customer myCustomer, double payment) {
        Wallet theWallet = myCustomer.getWallet();
        if (theWallet.getTotalMoney() > payment) {
            theWallet.subtractMoney(payment);
        } else {
            //money not enough
        }
    }
}

让我们将PaperBoy中charge()方法的代码翻译成这幕小话剧的对白。

“把钱包交出来！”收银员算出顾客要买的商品总价后，“温柔”地对顾客说道。
顾客言听计从，赶紧将钱包掏出来，恭恭敬敬地递给收银员。
接过钱包，收银员毫不客气地打开，检查里面的钱够不够。噢，不错，钱够了。收银员从钱包取出钱，心满意足地笑了。

如果你是顾客，你敢去这样的超市shopping吗？

对于PaperBoy而言，Wallet不满足迪米特法则三个条件中的任何一个，因此让PaperBoy与Wallet对象直接交互是错误的行为。若从拟人化的角度思考，则Wallet其实属于Customer的隐私。如此重要的隐私，怎么能直接交给收银员这个陌生人呢？这里所谓的“隐私”，可以视为是“数据”，是“信息”，是“知识”，因此我们往往又将迪米特法则称之为“最小知识法则”。

当我们理解“最小知识法则”时，又可以从职责的角度去思考以上代码。对于收银员角色，他的职责应该是负责收钱，而不用去管钱包里的钱够不够，如果够了怎么办，如果不够又该怎么办，这些统统都不属于他的职责。设想一下，当超市里人流如织，大家都在购买商品时，如果每一个收银员都要承担这般的职责时，会出现什么样的景象？所以“最小知识法则”乃善法，在对象社区中，我们就应该刻意减少对象之间彼此深入的了解。了解最小的知识，就意味着依赖最小，彼此产生的影响就会最小。这实际上是KISS（keep it simple and stupid）原则的体现。

信息专家模式告诉我们：“信息的持有者即为操作该信息的专家。”对于对象，所谓信息就是该对象内部的字段。在前面的例子中，Wallet是Customer的字段，那么操作Wallet的行为自然就应该分配给Customer了。这是题中应有之义。“信息专家模式”其实是面向对象最重要原则“数据与行为应该封装在一起”的别名。若在领域建模时能遵循该原则，则可以规避我们设计出贫血模型。

如何修改以上代码？注意，charge()行为仍然属于PaperBoy的职责，因此我们不应该将该方法整体搬迁到Customer中，而应该先进行方法的提取：

提取的pay()的方法体与charge()方法完全相同，但是在PaperBoy类中却保留了charge()方法，只是这个方法什么也没有做，在接收方法请求后，转而将请求委派给了pay()方法。我们可以这样理解：在抽象层面，收款是收银员的职责；在实现层面，是pay()方法支持了收款行为，该实现归属于顾客。

观察pay()方法，我们发现该方法操作的数据皆来自Customer。我们嗅到了一种坏味道，即Martin Fowler所谓的“特性依恋（Feature Envy）”。对于该坏味道，老马是这样阐释的：“函数对某个类的兴趣高过对自己所处类的兴趣。”不要再嫉妒了，桥归桥，路归路，让方法回到自己最喜欢的地方吧。运用“Move Method”重构手法，将pay()方法移动到Customer中：

在将方法移到正确的位置后，我们发现暴露的getWallet()方法根本就没有意义。更何况，将钱包裸露出去，难道是想要炫富吗？还是低调一点为好，隐藏自己的“隐私”，总好过被人觊觎而招来飞来横祸之险。于是，内联（inline）之。

判断一段代码是否违背了迪米特法则，有一个小窍门，就是看调用代码是否出现形如a.m1().m2().m3().m4()之类的代码。这种代码在Martin Fowler《重构》一书中，被名为“消息链条（Message Chain）”，有人更加夸张地名其为“火车残骸”。车祸现场啊，真是惨不忍睹。

那么，如下代码是否这样的残骸呢？

str.split("&")
	.stream()
	.map(str -> str.contains(elementName) ? str.replace(elementName + "=", "") : "")
	.filter(str -> !str.isEmpty())
	.reduce("", (a, b) -> a + "," + b);

不是的。这样的代码我们一般称之为“流畅接口或连贯接口（Fluent Interface）”。二者的区别在于观察形成链条的每个方法返回的是别的对象，还是对象自身。如果返回的是别的对象，就是消息链条。所谓m1().m2().m3().m4()的调用，其实是调用者不需要也不想知道的“知识”，把这些中间过程的细节暴露出来没有意义，调用者关心的是最终结果；而上述代码中的map()与filter()等方法其实返回的还是Stream类。这一调用方式其初衷并非告知中间过程的细节，而是一种声明式的DSL表达，调用者可以自由地组合它们。