Dependency Injection with Factory

Another alternative for consideration

Photo by Fotis Fotopoulos on Unsplash

Introduction

In Java, we have different methods of initializing the object. It can be normal initialization, dependency injection, or factory pattern.

In Spring framework, dependency injection is the fundamental aspect that is commonly used to allow loose coupling of the component without the need to know the dependency of each component otherwise.

Likewise, the factory pattern also promotes loose coupling of the component as it delegates the need to know to the factory.

Dependency Injection vs Factory Pattern

The difference between dependency injection and factory pattern is the lifecycle management of the instance.

For dependency injection, lifecycle management is handled by the framework outside of the code.

For factory pattern, lifecycle management is handled by the programmer within the application.

What is Dependency Injection with Factory?

The based implementation is still dependency injection with the object creation decision logic of the factory pattern.

Let’s look at an example. Suppose we have two classes, InstanceDelivery and ScheduledDelivery, which do different logic while creating orders.

Just Dependency Injection

With just dependency injection, the benefit of it is clear.

• First, the creation of objects is simple using constructor injection.
• Second, the creation of objects is more transparent for classes with multiple instances. For example, ScheduledDelivery class has a dependency on the Scheduler class.

However, there are downsides to constructor injection too.

• First, it will lead to a code smell called the long parameter list. In this example, there are only 2 modes of delivery (Instant and Scheduled) so it may seem acceptable. But what if there are 10 modes of delivery?
• Second, the constructor signature is prone to changes whenever an additional mode of delivery has been introduced. It may seem constructor signature changes will not affect any code with dependency injection. However, they will affect the unit test of DeliveryService class if you are injecting a mocking object in the unit test.

Just Factory Pattern

With just factory pattern, the creation of the objects is not as straightforward as dependency injection.

• First, you will need to know the dependency of each class, in which it might get tedious to create an object.
• Second, unit testing for DeliveryService class is much harder to construct as DeliveryFactory will not be mockable.

However, the benefit of factory pattern is reducing the long parameter list that causes by dependency constructor injection.

Dependency Injection with Factory

With dependency injection with factory, it combines both pros while eliminating the cons.

• First, the creation of an object is transparent.
• Second, the long parameter list is reduced from many to 1.
• Third, less prone to constructor signature changes.
• Fourth, unit testing is easier as it is mockable.

The based implementation is still dependency injection where DeliveryService and DeliveryFactory use constructor injection. The getInstance in DeliveryFactory implemented the object creation decision logic to return the desired object.

Conclusion

There is nothing wrong with just dependency injection or just factory pattern implementation. Dependency injection with factory adds another alternative for consideration to make your code cleaner and organized. It is more suitable when you have more than 2 service classes and the benefit of this technique will be greater as it grows. Ultimately it is important to use any of the design patterns that suit the use cases.

That’s all for the short read. Thanks for your time