4

我希望有人可以帮助向我解释得墨忒耳定律。如果我有一个类，我假设它是一个聚合根，并且其中有一个子类的集合，通过聚合根访问它们来更新这些子类的属性是非法的吗？

例如

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
}

假设我有一个客户首先访问 Company 类，它是否会违反 demeter 法则。

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

或者这是否应该始终委托给公司

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 有什么问题吗？

如果您有许多嵌套聚合，这似乎会开始变得复杂。

谢谢

4

1 回答 1

7

您的第二个选择是得墨忒耳法则的目标。

由于得墨忒耳法则基本上规定“只谈论你所知道的”......无论“客户”在第一个场景中是什么，实际上根本不了解员工。它知道Company......但不知道Company内部的复杂性。

委托Company给您可以灵活地更改员工的更新方式，而无需从客户端更改此功能的每个特定实例。如果有一天您决定只有Active员工可以更改姓名，那么您必须将选项一的每个实例更新为：

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

将其包裹起来Company可以使将来更好地处理（无论是否尝试遵循得墨忒耳法则）。

第二个似乎更好，但是客户端必须知道要更新的员工的 id 有什么问题吗？

您的两个示例都知道 Employee 的 ID。所以我不确定您的意思。在通过聚合传递信息时，使用代码知道 ID 是很常见的。

于 2014-04-10T22:25:02.097 回答