I have a class for products import from CSV file operation which requires about 7 parameters. This is an info which is definitely needed for importer.
All of this parameters have the same life time. In the end we must have an Immutable Object.
I was too scared to list all of them in constructor because of its affect to readability and decided to move 3 of them to setters injection. But obviously it's not an elegant solution.
Questions:
1) Is mixing constructor-based and setter-based injections a bad practice?
2) How this particular problem can be solved?
I was thinking about applying "Introduce Parameter Object" refactoring by Martin Fowler, but there is a problem with this.
4 Parameters can be moved to Parameter object quite easily (customerId, projectId, languageId etc.) - all integers.
Other 3 parameters are an object I inject(it is required for Mock unit-tests).
It's not necessarily a bad thing to mix Constructor Injection and Property Injection, but it may not be that common. As an overall strategy, avoid Property Injection since it's much more difficult to implement correctly (this may sound counter-intuitive, but it's true).
It's important to understand when to use each pattern.
- Constructor Injection should be your default injection pattern. It's super-easy to implement and can guarantee invariants: assign it to a read-only field to ensure the consumer's invariants.
- Property Injection can be used when you have a good Local Default implementation, but you want to follow the Open/Closed Principle and allow advanced users to extend the class by providing an alternative implementation.
You should never apply Property Injection because of constructor cosmetics.
When you require too many dependencies, it's a sign that you may be violating the Single Responsibility Principle - the class is simply trying to do too much at once.
Instead of introducing a Parameter Object (otherwise a good suggestion), a better option is to encapsulate two or more of the dependencies into an aggregating service that orchestrates the interaction of these dependencies.
Imagine that your initial constructor looks like this:
public MyClass(IDep1 dep1, IDep2 dep2, IDep3 dep3, IDep4 dep4, IDep5 dep5)
After applying a bit of analysis, you figure out that in this case IDep1, IDep3 and IDep4 will be used together in a particular way. This will allow you to introduce an aggregation service that encapsulated these like this:
public class AggService : IAggService
{
public AggService(IDep1 dep1, IDep3 dep3, IDep4 dep4)
{
// ...
}
// ...
}
You can now rewrite the original constructor to this:
public MyClass(IAggService aggSrvc, IDep2 dep2, IDep5 dep5)
and so forth...
It is very common that the aggregate service turns out to be a proper concept in it's own right, and suddenly you have a richer API than when you started.
