デマーターの混乱の法則

Question

誰かが私にデメーターの法則を説明するのを助けることができることを願っています。私が想定しているクラスが集約されていて、その中に子クラスのコレクションがある場合は、それらにアクセスすることによってそれらの子クラスのプロパティを更新することは違法ですか？

e.g.

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
}

.

最初に会社クラスにアクセスしているクライアントがあるとしてみましょう。

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");

.

2番目のものは良いようですが、更新したい従業員のIDを知る必要があるクライアントに問題があるのですか？

これは、あなたがたくさんの入れ子になった集計を持っている場所に複雑になることができるようです。

ありがとう

Answer 1

あなたの2番目の選択肢は、デメテルの法則が目的とするものです。

現地の法則は基本的に「あなたが知っているものと話すだけ」を述べています。それはCompanyについて知っています。

Companyに委任すると、この機能の各特定のインスタンスをクライアントから変更する必要なしに、従業員の更新方法を変更する柔軟性が得られます。ある日、Companyの従業員だけが自分の名前を変更できると判断した場合は、オプション1のすべてのインスタンスをこれに更新する必要があります。

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

.

Activeで包まれていることは、将来的には将来的に対処するために（DEMETERの法則に従うかどうかにかかわらず）。

2番目のものは良いようですが、更新したい従業員のIDを知る必要があるクライアントに問題があるのですか？

両方の例は従業員のIDを知っています。だから私はこれによって何を意味するのかわからない。集計を通じて情報を渡すときにコードを消費することは非常に一般的です。