德墨忒耳定律和集合的构图如何协同工作？总结
2022-09-04 23:20:44
我读过几乎所有标有德墨忒耳定律的问题。我的具体问题在其他任何问题中都没有得到解答，尽管它非常相似。我的主要问题是，当你有一个具有组合层的对象，但是需要从各种对象中检索属性值时，你如何实现这一点，为什么要采取一种方法而不是另一种方法？
假设您有一个由其他对象组成的非常标准的对象，如下所示：
public class Customer {
private String name;
private ContactInfo primaryAddress;
private ContactInfo workAddress;
private Interests hobbies;
//Etc...
public getPrimaryAddress() { return primaryAddress; }
public getWorkAddress() { return workAddress; }
public getHobbies() { return hobbies; }
//Etc...
}
private ContactInfo {
private String phoneNumber;
private String emailAddress;
//Etc...
public getPhoneNumber() { return phoneNumber; }
public getEmailAddress() { return emailAddress; }
//Etc...
}
private Interests {
private List listOfInterests;
}
以下两者都违反了得墨忒耳定律：
System.out.println("Phone: " + customer.getPrimaryAddress().getPhoneNumber());
System.out.println("Hobbies: " + customer.getHobbies().getListOfInterests().toString());
我认为这也会违反得墨忒耳定律（澄清？
ContactInfo customerPrimaryAddress = customer.getPrimaryAddress();
System.out.println("Phone: " + customerPrimaryAddress.getPhoneNumber());
因此，据推测，您将向客户添加“getPrimaryPhoneNumber（）”方法：
public getPrimaryPhoneNumber() {
return primaryAddress.getPhoneNumber();
}
然后只需调用：System.out.println（“Phone： ” + customer.getPrimaryPhoneNumber（））;
但随着时间的推移，这样做似乎会带来很多问题，并且违背了德墨忒耳定律的意图。它使客户类成为一个巨大的包包，其中包含有关其内部类的太多知识。例如，Customer 对象似乎有一天会有不同的地址（而不仅仅是“主”和“工作”地址）。也许甚至 Customer 类也只是具有 ContactInfo 对象的列表（或其他集合），而不是特定的命名 ContactInfo 对象。在这种情况下，你如何继续遵循得墨忒耳定律？这似乎违背了抽象的目的。例如，在客户具有 ContactInfo 项目列表的情况下，这似乎是合理的：
Customer.getSomeParticularAddress(addressType).getPhoneNumber();
当你想到有些人拥有手机和固定电话时，这似乎会变得更加疯狂，然后ContactInfo必须拥有一系列电话号码。
Customer.getSomeParticularAddress(addressType).getSomePhoneNumber(phoneType).getPhoneNumber();
在这种情况下，我们不仅要引用对象内对象中的对象，而且还必须知道有效的地址类型和phoneType是什么。我绝对可以看到这个问题，但我不知道如何避免它。特别是当任何阶级正在称呼这个时，可能确实知道他们想要为有问题的客户的“主要”地址拉取“移动”电话号码。
这怎么能被重构以符合得墨忒耳定律，为什么这是好的呢？
