Skip to main content

IOC Part 1 - Inversion of control Principle

IOC Inversion of control Principle

Series Intro

This is the first article of a series targeting the deep understanding of what it means to IOC mostly using dependency injection, this will a really extensive study to what goes underneath the usage of a framework, so basically it is going to exceed the high level usage of a frame work such as Unity or Ninject, This will concentrate more on what goes under the hood and how does it communicate through the pipelines,
This Article is An introduction to IOC.


It’s an infinite and everlasting purpose for us problem solvers to seek development practices and development techniques to lower the cost and increase the productivity of the problem solving principle, however terms of productivity, complexity, extendibility, maintainability and development cycle  are not determined by how partitioned, abstracted or object implemented your application is. All these relay heavily on how these objects are coupled, integrated and manipulated all together, so many techniques were introduced such as CBD (Component Base Development), and one example of these is the Inversion of Control. What is it?
Inversion of control is a software practice that has been put as most under the umbrella of OOP (object oriented programming) along with its most basic ones encapsulation, polymorphism,etc to Design patterns.


Inversion of Control Is a practice the most problem solvers use when faced by an extendibility issue or even when trying to make their application more maintainable by removing the objects dependencies and define them in runtime rather in compilation.

Application types and methods

public class A{
private B b;
public A(){
b=new B();

Listing 1. Class A Directly Refers Class B
Listing 1 assumes the following design decisions:
  1. Class A needs a reference to Class B.
  2. Class B is a concrete class that has a default constructor.
  3. Class A owns the instance of class B.
  4. No other class can access the instance of Class B.

If any one of the above design decisions change, then the code in Listing 1 must be modified. For example, if Class B changed to have a non-default constructor, which takes Class C (see Figure 2), then Listing 1 would change to Listing 2.

public class A{
private B b;
public A(){
C c=new C();
b=new B(c);

Listing 2. Class A Directly Refers Class B and Class C
Once again, Listing 2 assumes certain design decisions. Now Object "a" owns both Object "b" and Object "c". If Class B or Class C changes at all, then Class A needs to change as well. In essence, a simple design of a simple class with implicit design assumptions becomes a maintenance nightmare in the future. Consider how difficult making changes would be if you had this scenario in a typical application with several classes.
Alternatively, if you use a framework that uses the IoC pattern, the responsibility of creating Object "b" moves from Object "a" to the IoC framework, which creates and injects Object "b" into Object "a". This insulates Class A from the changes in Class B. Before Object "a" is used, it needs the reference to Object "b". The IoC framework will inject Object "b" into Object "a".

Listing 3 shows Class A from the previous listings modified to use the IoC pattern.

public class A{
private B b;
public A(){
public setB(B b){

Listing 3. Class A Gets the Reference to Class B via setB
Listing 3 assumes the following design decisions:
  1. A needs a reference to B, and it doesn't need to know how B is instantiated.
  2. B can be an interface, an abstract class, or a concrete class.
  3. Before the instance of Class A is used, it needs a reference to the instance of Class B.
From the above design decisions, you can see that there is no tight coupling between Class A and Class B. Both can be changed independently without affecting each other. Of course, if there is any change in the public methods of Class B, Class A needs to change as well. But how Object "b" is created and managed is not decided in the implementation of Object "a". Instead, the IoC framework uses the setB() method in Object "a" to inject Object "b" (see Figure 3).

thanks for reading,

Notes: This example is taken from a java blog here is the link


Popular posts from this blog

(AsyncWebClient) Async Webclient for windows phone 8

Using windows phone web client is pretty common but the thing is you can not use it using Async -> Await mechanism so i used threading to create an async functionality for The Download string and upload string methods here is the code below // Comment public class AsyncWebClient { public Task DownloadString(Uri uri) { var task = new TaskCompletionSource(); try { var client = new WebClient(); client.DownloadStringCompleted += (s, e) => { task.SetResult(e.Result); }; client.DownloadStringAsync(uri); } catch (Exception ex) { task.SetException(ex); } return task.Task; } public Task UploadString(Uri uri, string content) { var task = new TaskCompletionSource(); try { var client…

RuntimeBinderException cannot resolver property in Unit Test in case of dynamic return.. Solved

Xamarin UI Tests – Deep dive Part 1

IntroAs the title may describe this is the first of the series of articles that will cover the UI Test of Xamarin in a deep dive, we will start simple and then dig deeper as we go. Since this is very well the first of the series, it will mostly cover up the architecture and the testing technique that Xamarin UI Tests uses.

The Technology
Xamarin UI Test is an automation testing framework similar to selenium, Watir, Watin (.net), Robot and Sikuli, if you have used BDD (Behavioral Driven Development) or a more advanced TDD (Test Driven Development) approach at least you must have come across one of these frameworks, and in that perspective comes Xamarin UI Testing as an automation framework designed specifically for Xamarin Automation testing, For starter Xamarin UI Tests was not build from scratch, instead it was built on top of another UI Automation testing framework that is targeting android and iOS sepecifically which is Calabash, I have to say that this choice was made wisely as of n…