通过接口与委托公开聚合答案

【问题标题】：Exposing aggregation through the interface vs. delegation通过接口与委托公开聚合
【发布时间】：2011-05-03 03:40:11
【问题描述】：

我有一个 Employee 对象，它聚合了一些其他对象，例如 HRData 和 AssignmentHistory。过去，所有这些逻辑都直接包含在 Employee 对象中，但为了可测试性和可管理性，我将其拆分为使用聚合。但是，我没有直接公开聚合对象，而是使用了委托，这样客户就不会知道内部工作。例如，不要这样做：

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

客户会这样做：

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

我真的很喜欢这个，因为它遵循“黑盒”方法，这意味着我可以在不影响客户端的情况下随意更改实现，同时仍然由内部可测试的小型对象组成。问题是 Employee 对象已经显着增长，因为它现在有 5 个聚合对象，并且它的界面上充斥着 getXXXOn() 方法。

您使用哪种方法，为什么？有没有我忽略的替代方案？使用委托方法的问题是接口变得庞大，而暴露聚合对象的问题是代码不太灵活，并且客户端需要知道哪个聚合负责什么。有什么建议吗？

【问题讨论】：

标签： design-patterns interface aggregation delegation

【解决方案1】：

考虑更改 Employee 以提供 GetEmployeeDataOn(Date) 方法，以及用于 EmployeeDataOnDate 的存储此日期并具有 GetProfile() 等方法的类。

【讨论】：

感谢您的回答。也许我没有正确理解您，但这不会解决乱七八糟的界面问题，对吗？如果有 20 个 getXXXOn() 方法，那么新的 EmployeeDataOnDate 对象仍然有 20 个 getXXX() 方法。
肯定会的。但是您将它们与其他 Employee 行为隔离开来，例如 DoSomeWork() 或 GoOnStrike() 或其他任何东西，并将这些关于获取员工记录的方法集合放在与此相关的某个对象上。它有助于凝聚力和 SRP。如果您根据需要适当地管理它们，许多方法本身并不是问题。