As I understand from your description, currently both the Employee
and Location
are mandatory dependencies for every instance of Organization
. When you are creating this dependencies in the constructor, you create two problems here (thy are kinda like two ends of same ugly stick):
The
Organization
class becomes tightly coupled to the names of "Employee" and "Location"It becomes very hard to test the behavior of
Organization
instances, because you have no direct control over its dependencies. You are unable to isolate the "unit under test".
Note A: actually an organization require a collection of employees/members, with minimum number of one. In this case a collection of domain objects would seem like a better choice from bit aspects of logic and API implementation.
To avoid these problems there are two solution for situation when you have to create a complicated object graph:
Use a factory (supplemented by properly implemented DIC), which creates all the requirements of your
Organization
class and injects them, when you are constructing new instance.Create the create all the dependencies and then inject them manually in the
Organization
, when instantiating the object.
Note B: to create domain any domain objects within a service you should be using a factory for said objects. To facilitate this, you would have to inject a domain object factory in the constructor of any service, that you instantiate. Otherwise you just end up with classes that are coupled to names of other classes.
The choice would depend on what else you want to do with the Employee
EmployeeCollection
and Location
instances in that and similar cases and on what style you prefer.
If you are doing extensive and very specific manipulation with these dependencies, then they should definitely be instantiated separately (via a simple domain object factory) and only then injected. If you are only creating an object graph, the the DIC-based factory would be favorable solution.
P.S.: I would recommend for you to watch the The Clean Code Talks - Don't Look For Things! lecture.