正如Dancrumb上面所说，我认为法律的想法是确保人们在适当的水平上访问物体。
想象一下，我们班级模拟乐队办公室的前台。它的工作是充当乐队成员的PA，并与任何想要与乐队互动的人打交道。Band
现在，假设我们有一个来自公关公司的旅游推广人，他想为他们的下一次巡演整理一些公关材料。我们可以用一个类来模拟他：
class TourPromoter {
public String makePosterText(Band band) {
String guitaristsName = band.getGuitarist().getName();
String drummersName = band.getDrummer().getName();
String singersName = band.getSinger().getName();
StringBuilder posterText = new StringBuilder();
posterText.append(band.getName()
posterText.append(" featuring: ");
posterText.append(guitaristsName);
posterText.append(", ");
posterText.append(singersName);
posterText.append(", ")
posterText.append(drummersName);
posterText.append(", ")
posterText.append("Tickets £50.");
return posterText.toString();
}
}
在现实生活中，这相当于旅游发起人打电话给办公室并说：
可以说，PA很快就会被解雇。大多数理性的人会问：“难道你不能为我们处理那个电话吗？
我们可以有一种方法，从技术上讲，这种方法会尊重德墨忒耳定律，但我们仍然要求我们的班级记住有关乐队的细节 - 即他们有一个吉他手 - 而这些信息应该真正属于乐队本身。getGuitaristsName()TourPromoter
为了确保我们以合理的方式引入方法，我们需要看看巡演发起人实际上在寻找什么 - 即所有乐队成员的名字。如果我们在代码中对该方法进行建模，它将为我们提供更大的灵活性，以便以后对方法进行更改，甚至不必触摸 ：BandTourPromoter
public class Band {
private Singer singer;
private Drummer drummer;
private Guitarist guitarist;
public String[] getMembers() {
return {singer.getName(), drummer.getName(), guitarist.getName()};
}
}
public class TourPromoter {
public String makePosterText(Band band) {
StringBuilder posterText = new StringBuilder();
posterText.append(band.getName());
posterText.append(" featuring: ");
for(String member: band.getMembers()) {
posterText.append(member);
posterText.append(", ");
}
posterText.append("Tickets: £50");
return posterText.toString();
}
}
如果我们现在添加一个贝斯手或键盘播放器，只有乐队类需要知道差异，而巡演发起人不需要改变。这意味着我们现在也遵守了单一责任原则 - 即我们的方法只需要在改变海报格式时改变，而不是在乐队改变时改变。makePosterText()
我不认为德墨忒耳定律会告诉你需要采用哪种方法才能以最佳方式满足原则（例如 而不是上面）这样，我认为你是对的 - 它确实向你展示了当事情坏了，但不一定如何解决它们。但是，牢记LoD意味着您可以留意可以通过其他设计原则（如SRP）的组合来修复的违规行为。getMembers()getGuitaristsName()
