If I break my Objects down to 'Single Responsibilities', is there a fundamental thought whether like objects should live together or separately, for example if I have
class Employee_DataProvider() : IEmployee_DataProvider { ... };
class Employee_Details() : IEmployee_Details { ... };
class Employee_Payroll() : IPayroll() { ... };
class Employee_LeaveProcessing() : ILeaveProcessing_Client { ... };
...
Is it bad smell to have all these living inside, yet loosely coupled to through interfaces, an owning Employee class:
class Employee
{
IEmployee_DataProvider _dataProvider;
IEmployee_Details _details;
IPayroll _payroll;
ILeaveProcessing_Client _leaveProcessing;
//My functions call the interfaces above
}
or is the thinking more around keeping these classes completely separate (or as least as separate as is posible) in the code? Or are both these methods a valid usage of SRP?
EDIT: I do not want critique on the feasibility of the object given in the example, I just made it up to illustrate the question. I agree data, leave and payroll processing are not the domain of the employee class.
It does appear though that SRP is asking me to move away from the object as real world representation to object as a properties and methods around a single functional concept
Go back to OOP basics: the Employee object should have methods that reflect what it does, not what is done to it.
Although no one has yet addressed my actual question regarding the principle itself, rather than the somewhat poor example I gave, of an Employee object knowing too much about the processes that affect it, for those who are obviously interested in the question (there are 2 'favourites' stars) I've done a bit more further reading, although I was hoping for more of a discussion.
I think what the two current answers are trying to say is that responsibilities separated should be able to be stand alone, and that my example was a perfect example of what not to do. I am more than happy to accept that.
There is a paragraph from ObjectMentor (Uncle Bob's site) that has an example that combines Connection and DataReader objects (two objects previously living in a modem class then separated out) into a ModemImplementation, but states
However, notice that I have recoupled
the two responsibilities into a single
ModemImplementation class. This is not
desirable, but it may be necessary.
There are often reasons, having to do
with the details of the hardware or
OS, that force us to couple things
that we’d rather not couple. However,
by separating their interfaces we have
decoupled the concepts as far as the
rest of the application is concerned.
We may view the ModemImplementation
class is a kludge, or a wart; however,
notice that all dependencies flow away
from it. Nobody need depend upon this
class. Nobody except main needs to
know that it exists. Thus, we’ve put
the ugly bit behind a fence. It’s
ugliness need not leak out and pollute
the rest of the application.
I think the line 'notice that all dependencies flow away from it' is an important one here