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.

Intro

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.

Definition

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){
this.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 
http://www.devx.com/Java/Article/27583


Labels:

Comments

Post a Comment

Popular posts from this blog

Xamarin Forms Core components Part 1 Dependency Service

Intro Xamarin Forms is a collection of controls that can be used and rendered on multiple platforms, and in order of them to function as they are suppose to, they do need a set of core components that defines the way these controls, in how they are created, how they are rendered to how they are used, of course every platform is different and sometimes a platform specific extra configuration is required, specially that there are so many differences between the different platforms in matter of design, user experience and operating system behavior. So one of the core components of  Xamarin  Forms is the Dependency Service, and by the name suggest it does act as the dependency resolver for all forms controls, if you are not familiar with IOC " I nversion O f C ontrol" and Dependency Injection please refer to the link for a quick intro i wrote a while ago on IOC  IOC Part 1 - Inversion of control Principle .  And as of such the Dependency Service is the concrete inboxe
Post a Comment
Read more

Xamarin Forms: XAML Creating Custom Controls The MVVM Way

Intro For a growing UI page there always comes a need to create sub views that can be used inside a bigger view, and for that we need custom controls, which are controls that are derived either from a layout or a simple view which is the basic control for almost any UI component in Xamarin forms, and therefore for a start i will use that as an example. And in such example we will create a custom control with a set of bindable properties and explain how they work, also how to add an event that can also be bound to Commands Lets Create the control  I have just went ahead and created a custom control that inherits from Xamarin.Forms.View and have some properties such color and checked all properties to be bound to by the ViewModel serving as the datacontext of the this control. here is the code below using System; using Xamarin.Forms; namespace UserControls { public class CustomView : View { public Color Color { get ; set ;
Post a Comment
Read more

Windows Phone 8 - Application bar command binding MVVM

This is a short post in which i will explain how on Windows phone 8 to bind the application bar button or menu item, first this is only a fix for the  BindableApplicationbar  which supports windows phone 7 only, i just made it support windows 8 no features added or anything. i have uploaded the dll file here so it can be accessible easily here is the link to download http://sdrv.ms/RApUal now that you got the link lets check how we gonna use it you can refer to BinableApplicationbar  or check out the code here that i actually used in my app and i already read it there !  Add a reference to the BindableApplicationBar library here is the link again  http://sdrv.ms/RApUal Add XML namespace declaration in your page's XAML: xmlns : bar ="clr-namespace:BindableApplicationBar;assembly=BindableApplicationBar" Set Bindable.ApplicationBar property on your page code as in the snippet below: < phone : PhoneApplicationPage >     …     < bar : Bindable.App
6 comments
Read more