Dependency Injection and Aspect Oriented Programming

Inversion of Control (IOC), Dependency Injection (DI) and Aspect Oriented Programming are three popular keywords in Software Designing and Programming. But these terms are quite confusing to others and to each others some time. Let us try to understand what are these terms and how these are used.

If we think about Inversion of Control, it seems like we are changing the flow of control from, and a new King is coming in picture who will control all the flow now onward. Actually it is right. Earlier when we have started with Procedural programming, we tend to have control at single point. Later when we shift to OOP, we did better by decentralizing the logic and hence the control also to respective object. However, as we move on, we still find something missing which was hard coding of object dependencies on each other. If anytime, we need to change the implementation of a specific object, it means that we need to change the code and it may probably have some impact on implementation style. Then we strive hard to find the solution for providing such flexibility in the application and devised various design patterns like Service Locator, and Factory Pattern etc.This gave us good solutions by keeping knowledge of actual object implementation away from user object and hence gives the flexibility to change the implementation at any point of time. Things moves well, and applications used to be more and more flexible in design with increased use of such design patterns. However, one end of control was still in the hand of user object. It was still aware and the one who will initiate the factory or service locator to further get the right implementation of service. But desirable stage was, when user object is just aware about type of service it wants, not the source and actual instance of this service.....


Here comes the inversion of control, which takes the control from the hand of a main object in application and settle it elsewhere. Now user object only knows, that it needs some specific type of service to complete its operations however it is not aware that from where, who and when will provide this service to it. It means now something from surrounding environment will control all of these things for the object. And of course, this surrounding environment have to be highly configurable so that whole control flow can be itself controlled easily anytime without coding or with minimal coding. This is the inversion of control, where points of control have been changed. And actually this is a right way which we generally try to implement to make our application code more flexible, and configurable.

Starting from this concept, application used to grow around these design. However to make it more configurable and generic, we saw many frameworks in market. IOC is a very generic term, and hence its creator/users adopt a new term called as Dependency Injection, which means implementation of services  in a way when Service users are not aware; who, and when will set the required services to them. So it means,       an object is dependent on some services for its working, and the someone from sourrounding environment is injecting these dependencies to this object in the run time. So isn't this a Dependency Injection.. Dependency Injection can be primarily of three types, which are, by Interface, by Constructor and by Setters.

• DI by interface means, when we declare a interface for specific type of dependency requirement. Like, if we need to insert a file name to a object, we can define a Interface called as InjectFileName with a method as injectFileName (String fileName). Now any object needs to have a specific file name can implement it. Environment can be configured in a way that at run time it can search for the objects implementing this interface and can insert the configured file name to this object. So this is DI by interface. However, in this approach, we need to define many interfaces every time we add different dependencies. 
• DI by Constructor means, when we define a specific constructor with all dependencies as constructor parameters. Then environment can be configured to find/instantiate the corresponding type of objects before creating the this object and pass those object in constructor as parameters. This approach is good to have always a valid object in existence, having all of its dependencies readily set to it. It also enables the immutable object scenarios, if we remove all setters for these properties. However, this approach can be awkward if we have too many dependencies or class is extending other classes having different constructors with varied contracts.
• DI by setters means, when we define different setters for each type of dependency. And then we configure the environment in a way so that each dependency can be set to the object using these setters as these are required. This is a preferred way if you have many dependencies, however, you have to be sure that you are configuring the environment properly so that no one can use this object before all dependencies are set.    

All types of DI are good, however, everyone has its on pros and cons. Now you need to decide as per your application design and requirement, which one suits to you most. Di by constructor can be called a good and safe approach as it enables to have only valid objects in environment which all dependencies set to it. However, it is not possible to use it in all scenarios as discussed above.   

Now let us come to Aspect Oriented Programming. Above two terms and AOP are linked together because many of the frameworks in market nowadays providing all of these features. Aspect Oriented Programming is where you define or declare your aspect for your program somewhere outside the code file and you get this aspect implemented at run time automatically. So some code is working for you, as per your wish, whenever wherever you want it, still this code is not written in your code. You write code (advice) anywhere and tells environment your aspect to insert this code, or to run this code at specific point in program. Same aspect can be used at multiple places in program. Most common used places are,

• Before running a method, 
• After running a method
• Around the method i..e before and after both
• If any method throw error
• In case of final code block executes

You just declares the desired code block at one place and then tell your aspect or wish to the environment  to apply this aspect at specific places; and it is being taken care of. Mostly this is not used for implementing business logic, as business logic used to be specific to a place or scenario. It is mostly used for infrastructure services kind of requirements like Logging, Transaction Management, Connection Management, Thread Pools, and other similar Resource Management etc. So for example, if we want that whenever any control thread enters into the method written by us, a log should be generated with some values and similarly log should be generated just before exit. We can definitely use the AOP to declare your aspect to log the information on entry and exit. J2EE containers using this concept since long by providing declarative Transaction and Isolation levels for each bean method in configuration files. However, they were not providing the flexibility to define our own advice. So this is the AOP, which if used properly, can really feel you like having fun while doing some very complex integrated programming.

Many of the frameworks today providing all of these fantastic design concepts, like Spring is one of these which is very generic and powerful framework. So select anyone of these frameworks available freely on internet and make best use of these design principles for your application. These principles are good coding practices, which probably, many of us must be using before also. However, now these are coming in a more Organized manner with various ready to use and mature frameworks.

People who read this post also read :