得墨忒耳定律 - 现实问题

时间:2016-12-12 09:45:42

标签: solid-principles law-of-demeter

我试图在现实世界中更好地理解得墨忒耳的法则(也就是我的应用程序),但我对于在辞去一系列责任时得到的理由和好处有些混淆。

我有一个例子,我在考虑使用它。有关系的课程

Enquiry -> assignedTo -> Room Rooms -> assignedTo -> Building Building -> assignedTo -> Company

现在我需要访问一些公司数据,例如。公司名称,我可以访问查询。所以我目前的流程是: enquiry.getManager().getRoom().getBuilding().getCompany().getName() - 很长,不是吗?

我认为如果我关注LoD,它应该更改为enquiry.getHostingCompanyName()但在我看来我需要创建 预先room.getHostingCompanyName()building.getHostingCompanyName(),因此,它将非常脆弱,并且在重构时需要比以前的方法更多的更改。

你能提供任何建议吗?或许我的假设完全错误,应该以不同的方式完成?

2 个答案:

答案 0 :(得分:3)

您不是仅使用对象而是使用数据结构。 你写的东西是:

new Human().getStomach().getContent().insert(new Cake());

而不是

new Human().eat(new Cake());

真实对象应封装/隐藏内部结构,并公开特定于域的API。另外对我而言,Room包含公司有点奇怪。

在我看来,房间应该不知道公司,而应该从公司对象获得房间参考。

在我看来,你的对象结构是由数据库驱动的,但它并不好。

以上所有内容都适用于富域系统,而不适用于某些简单的CRUD。在CRUD系统中,数据结构更好。

答案 1 :(得分:0)

the Law of Demeter(或the Principle of Least Knowledge)的真实世界问题是这样的:

哦,亲爱的,刚刚意识到建筑物并不总是只分配给一家公司。必须要改变这个类的接口。这是一个突破性的变化。好吧,把这个班级的朋友们整理好并改变他们......为什么这会导致101个错误呢?一个班级需要多少朋友?

Demeter法则实际上是关于封装的。这是一种你不太了解的封装。通常,封装是关于对象中的内容。这是关于对象本身的知识。

如果你的对象有几个与世界其他地方打交道的朋友,那么它就没有必要,即使它是公共的,它实际上也是封装的。如果来自外部世界的对象通过这些朋友进入对象,则此操作将停止。现在任何对象都可以知道您的对象。这需要解决很多问题。物体藏在朋友后面。不想受欢迎。他们想为一些亲密的朋友做一些工作。他们想要封装。

这就是为什么如果你不得不要求朋友的朋友做某事你就打破了这种封装。你应该告诉你的朋友为你做事,不要担心他们的朋友是谁。你有足够的朋友。

关键是,如果你发现自己需要通过课程来达到你所需要的东西,那就意味着一些工作没有完成,这将使你甚至不知道你所达到的课程。做好工作,不要对一切都如此友好。

如果您需要更多,我实际上已经写过before