Constructor Injection vs Field Injection

Question

I know this topic has been discussed a lot already so I don't want to get into which one is the "best way".

I have been using field injection for a couple of years now but recently I discovered that many people prefer constructor injection because the collaborators of a class have to be explicitly set before you can create an instance of a class.

One argument to use constructor injection is that it makes you think about how many classes you are actually depending on. I have been looking over the classes in one of my projects to see if I have too many dependencies.

I noticed a class of mine had about 6 dependencies, when I provide them via the constructor I get a really ugly constructor. This makes me think I may be depending on too much here.

When I think about it however, I don't think it makes sense in this case to split up the class in smaller ones.

The case is this:

There is a service class with one method "createContract" that takes input from a form and makes a contract with the provided data.

The form has 5 dropdowns in which you choose certain codes / types for that contract. Each one corresponds with a separate entity stored in another database table.

class FormData {
    private String aFieldOnTheContract
    private String fictiveCode1Id;
    private String fictiveCode2Id;
    private String fictiveCode3Id;
    private String fictiveCode4Id;
    private String fictiveCode5Id;
}

Later in the service when I want to create this contract I use 5 "XyzRepository" classes to look up the entity by the id of the one you have selected in the form.

I'm not sure how I could change my design to not have to do this and be able to remove these 5 dependencies. Any ideas?

Possible duplicate of [Dependency Injection: Field Injection vs Constructor Injection?](http://softwareengineering.stackexchange.com/questions/300706/dependency-injection-field-injection-vs-constructor-injection) — gnat, Apr 06 '17 at 10:24

score 4 · Accepted Answer · answered Apr 01 '16 at 08:24

Put all the data access for your codes on a single repository

If the codes are similar enough, you might be able to limit yourself to a single repository that has five different GET methods, or even a single generic method that takes the type of entity as an argument. The latter is similar to what NHibernate actually does: you have the one Session object that has a generic Get method that allows you to fetch any mapped entity by id in a strongly-typed fashion.

This might work best if your codes have some kind of shared parent class as you can create a repository named after the parent and have separate methods on that per child.

Put the codes onto one or more components

By not putting the five entities directly on the Contract but instead using a class that holds just those entities and putting that on Contract, you can have a single class that maps just the codes onto the separate class. The class that does the mapping still takes the five repositories, but any other classes that need to map the five entities can simply use the one class.

If you still want to get rid of the five repositories, see if you can group the codes onto multiple separate classes. Chances are at least some of the codes are related, but this strongly depends on your domain.

Constructor Injection vs Field Injection

1 Answers1