德米特混乱定律 [英] Law of Demeter confusion

查看:94
本文介绍了德米特混乱定律的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我希望有人可以向我解释of门铁律。如果我假设一个类是一个聚合根,并且其中有一个子类集合,那么通过聚合根访问这些子类的属性来更新这些子类的属性是否非法?

I'm hoping someone can help explain the law of demeter to me. If I have a class which I'm assuming is an aggregate root and within that have a collection of child classes is it illegal to update the properties of those child classes by accessing them through the aggregate root?

例如

public class Company
{
    // company has a number of employees
    public List<Employee> Employees {get; set;}
}

public class Employee
{
    // each employee has a lastname
    public int Id {get; set;}
    public string LastName {get; set;}
    // other properties of employee
}

让我说如果某个客户首先访问了公司类别,那么它是否会违反诸如《得克萨斯州法律》之类的法律。

lets say I have a client that is accessing the Company class firstly would it be violating the law of demeter with something like.

Employee e = aCompany.Employees.Where(e => e.Id == 1).Single();
e.LastName = "MarriedName";

还是应该始终将其委托给公司

Or should this always be delegated to Company

public class Company
{
    public UpdateEmployeeLastName(int employeeId, string newName)
    {
        Employee e = Employees.Where(e => e.Id == employeeId).Single();
        e.LastName = newName;
    }
}

在客户端中

aCompany.UpdateEmployeeLastName(1, "Marriedname");

第二个似乎更好,但是客户必须知道员工的ID是否有问题它想要更新吗?

The second one seems better but is there anything wrong with the client having to know the id of the Employee it wants to update?

如果您有许多嵌套聚合,这似乎会变得复杂起来。

This seems like it could start to get complicated where you have a number of nested aggregates.

谢谢

推荐答案

第二个选择就是Demeter法则的目标。

Your second option is what the Law of Demeter aims for.

因为得墨meter耳定律基本上说只谈论您所知道的事情。在第一种情况下,无论客户是什么,实际上根本不了解员工。它知道公司 ..,但不知道公司内部细节的复杂性。

Since the Law of Demeter basically states "only talk to what you know about".. whatever the "client" is in the first scenario doesn't actually know about employees at all. It knows about a Company.. but not about the intricacies of the Company internals.

委托给公司使您可以灵活地更改员工的更新方式,而不必从客户端更改此功能的每个特定实例。如果有一天您决定只有 Active 名员工可以更改其姓名,那么您将不得不将选项一的每个实例更新为此:

Delegating to the Company gives you the flexibility to change how an employee is updated without having to change each specific instance of this functionality from the client. If one day you decide that only Active employees can have their names changed, then you would have to update every instance of option one to this:

Employee e = aCompany.Employees.Where(e => e.Id == 1 && e.IsActive).Single();
//                                                        ^^^^ active flag
e.LastName = "MarriedName";

将其包装在 Company 中将来会更好地处理(不管是否尝试遵循Demeter定律)。

Wrapping it up in Company makes this much nicer to deal with in future (regardless of attempting to follow the Law of Demeter or not).


第二个似乎更好,但是在那里客户必须知道要更新的员工ID是否有问题?

The second one seems better but is there anything wrong with the client having to know the id of the Employee it wants to update?

您的两个示例都知道员工..所以我不确定你的意思。通过汇总传递信息时,使用代码的用户通常会意识到ID。

Both of your examples know the ID of the Employee.. so I'm not sure what you mean by this. It is very common for consuming code to be aware of the ID when passing information through an Aggregate.

这篇关于德米特混乱定律的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆