1

HRDataAssignmentHistoryなど、他のいくつかのオブジェクトを集約するEmployeeオブジェクトがあります。これまで、このロジックはすべてEmployeeオブジェクトに直接含まれていましたが、テストのしやすさと管理のしやすさのために、集計を使用するように分割しました。ただし、集約オブジェクトを直接公開する代わりに、委任を使用して、クライアントが内部の動作を認識しないようにしました。たとえば、これを行う代わりに:

employee.getHRDataOn("2010-01-01").getProfile();

クライアントはこれを行います:

employee.getProfileOn("2010-01-01");

これは「ブラック ボックス」アプローチに従っているため、非常に気に入りました。つまり、クライアントに影響を与えずに実装を自由に変更でき、内部的には小さなテスト可能なオブジェクトで構成されていました。問題は、Employeeオブジェクトが大幅に大きくなったことです。これは、現在 5 つの集計オブジェクトがあり、そのインターフェイスにはgetXXXOn()メソッドが散らばっています。

どのアプローチを使用し、その理由は何ですか? 私が見落とした代替手段はありますか?デリゲート アプローチの使用に関する私の問題は、インターフェイスが巨大になることです。集約オブジェクトの公開に関する問題は、コードの柔軟性が低く、クライアントがどの集約が何を担当しているかを知る必要があることです。助言がありますか?

4

1 に答える 1

0

Employee を変更して、GetEmployeeDataOn(Date) メソッドと、この日付を格納し、GetProfile() などのメソッドを持つ EmployeeDataOnDate のクラスを提供することを検討してください。

于 2011-02-13T15:28:13.643 に答える