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.....
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.....
