迪米特法则与重构

在面向对象设计的世界里,有一个寻常却又常常为人所忽略的原则——“迪米特(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表达,调用者可以自由地组合它们。

您的赞赏是我创作的动力!