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.
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 assumes the following design decisions:
- Class A needs a reference to
Class B.
- Class B is a concrete class
that has a default constructor.
- Class A owns the instance of
class B.
- 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);
}
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:
- A needs a reference to B, and
it doesn't need to know how B is instantiated.
- B can be an interface, an
abstract class, or a concrete class.
- 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
thanks for reading,
Notes: This example is taken from a java blog here is the link
http://www.devx.com/Java/Article/27583
Comments
Post a Comment