Issues with this approach: 1. Whenever you need to support a new Service Provider you need to add/change logic using if-else-if. 2. You can’t Unit Test with some Dummy AddressVerificationService (Using Mock Objects)

IOC/DI Approach:

In the above approaches AddressVerificationService is taking the control of creating its dependencies. So whenever there is a change in its dependencies the AddressVerificationService will change.

Now let us rewrite the AddressVerificationService using IOC/DI pattern.

With this approach we elemenated the issues with above Non-IOC/DI based approaches. 1. We can provide support for as many Provides as we wish. Just implement AddressVerificationServiceProvider and inject it. 2. We can unit test using Dummy Data using Mock Implementation.

So by following Dependency Injection principle we can create interface-based loosely-coupled and easily testable services.

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Join Us

With 1,043,221 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!