Реализация принципа единой ответственности

Question

Если я разбиваю свои Объекты на «Отдельные Обязанности», возникает ли фундаментальная мысль, должны ли объекты жить вместе или по отдельности, например, если у меня

class Employee_DataProvider() : IEmployee_DataProvider { ... };
class Employee_Details() : IEmployee_Details { ... };
class Employee_Payroll() : IPayroll() { ... };
class Employee_LeaveProcessing() : ILeaveProcessing_Client { ... };
...

Это неприятный запах - иметь все эти живущие внутри, но слабо связанные через интерфейсы, класс Employee:

class Employee
{
    IEmployee_DataProvider _dataProvider;
    IEmployee_Details _details;
    IPayroll _payroll;
    ILeaveProcessing_Client _leaveProcessing;

    //My functions call the interfaces above

}

или больше стоит задуматься о том, чтобы эти классы были полностью отделены (или, по крайней мере, настолько малы, насколько это возможно) в коде? Или оба эти метода являются допустимым использованием SRP?

РЕДАКТИРОВАТЬ: Я не хочу критиковать осуществимость объекта, приведенный в примере, я просто придумал, чтобы проиллюстрировать вопрос. Я согласен, что обработка данных, отпусков и начисления заработной платы не относится к классу сотрудников.

Похоже, однако, что SRP просит меня отойти от объекта как представления реального мира к объекту как свойствам и методам вокруг единой функциональной концепции

Answer 1

Вернемся к основам ООП: объект Employee должен иметь методы, отражающие то, что он делает, а не то, что с ним делают.

Answer 2

Хотя никто еще не обратился к моему актуальному вопросу относительно самого принципа, а не к довольно скудному примеру, который я привел, для объекта Employee, знающего слишком много о процессах, которые его затрагивают, для тех, кто явно заинтересован в этом вопросе ( есть 2 звезды «фаворитов») Я прочел еще немного, хотя надеялся на дальнейшее обсуждение.

Я думаю, что два нынешних ответа пытаются сказать, что разделенные обязанности должны быть в состоянии быть одинокими, и что мой пример был прекрасным примером того, чего не следует делать. Я более чем счастлив принять это.

Есть абзац из ObjectMentor (сайт дяди Боба), в котором есть пример, который объединяет объекты Connection и DataReader (два объекта, ранее живших в классе модема, а затем отделившихся) в ModemImplementation, но заявляет

Однако обратите внимание, что я отыграл две обязанности в одном Класс ModemImplementation. Это не желательно, но это может быть необходимо. Часто есть причины, чтобы сделать с деталями оборудования или ОС, которая заставляет нас соединять вещи что мы предпочли бы не пара. Тем не мение, отделяя их интерфейсы, мы имеем развязаны понятия, насколько Остальная часть заявки касается.

Мы можем посмотреть ModemImplementation класс - это кладжа или бородавка; тем не мение, обратите внимание, что все зависимости утекают от него. Никто не должен зависеть от этого учебный класс. Никто кроме главных потребностей знаю, что это существует. Таким образом, мы поставили уродливый бит за забором. Это уродство не должно вытекать и загрязнять остальная часть приложения.

Мне кажется, здесь важна строка «обратите внимание, что все зависимости вытекают из нее»