Exposing aggregation through the interface vs. delegation

I have an Employee object which aggregates a few other objects, such as HRData and AssignmentHistory. In the past all of this logic was contained directly in the Employee object, but for testability and manageability I've split it to use aggregation. However, instead of exposing the aggregate objects directly, I've used delegation so that clients would be kept unaware of the internal working. For example, instead of doing this:

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

Clients would do this:

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

I really liked this because it followed a "black box" approach, which meant that I could change the implementati开发者_如何转开发on at will without affecting the clients, while still consisting of small, testable objects internally. Problem is the Employee object has grown considerably, as it now has 5 aggregate objects, and it's interface is littered with getXXXOn() methods.

Which approach do you use and why? Is there an alternative that I overlooked? My problem with using the delegate approach is that the interface becomes massive, and my problem with exposing the aggregate objects is that the code is less flexible and that the client needs to know which aggregate is responsible for what. Any suggestions?

Consider changing Employee to provide a GetEmployeeDataOn(Date) method, and a class for EmployeeDataOnDate that stores this date and has methods like GetProfile().