У меня есть Employee объект, который объединяет несколько других объектов, таких как HRData и AssignmentHistory . В прошлом вся эта логика содержалась непосредственно в объекте Employee , но для удобства тестирования и управляемости я разделил его для использования агрегации. Однако вместо непосредственного раскрытия агрегированных объектов я использовал делегирование, чтобы клиенты не знали о внутренней работе. Например, вместо этого:
employee.getHRDataOn("2010-01-01").getProfile();
Клиенты будут делать это:
employee.getProfileOn("2010-01-01");
Мне очень понравилось это, потому что оно следовало подходу «черного ящика», что означало, что я мог изменять реализацию по своему усмотрению, не затрагивая клиентов, хотя по-прежнему состоял из небольших тестируемых объектов внутри. Проблема в том, что объект Employee значительно вырос, поскольку теперь у него есть 5 агрегатных объектов, а его интерфейс замусорен методами getXXXOn () .
Какой подход вы используете и почему? Есть ли альтернатива, которую я упустил? Моя проблема с использованием подхода делегата состоит в том, что интерфейс становится массивным, а моя проблема с представлением объектов агрегата заключается в том, что код менее гибок, и что клиент должен знать, какой агрегат за что отвечает. Есть предложения?