Monday, October 31, 2011

Tackling the Circular Dependency in Java...

Let me first define what we mean by circular dependency in OOAD terms vis-a-vis Java.

Suppose we have a class called A which has class B’s Object. (in UML terms A HAS B). at the same time we class B is also composed of Object of class A (in UML terms B HAS A). obviously this represents circular dependency because while creating the object of A, the compiler must know the size of B... on the other hand while creating object of B, the compiler must know the size of A. this is something like egg vs. chicken problem...

this may be possible in real life situation as well. for example suppose a multi storied building has a lift. so in the UML terms, the building HAS lift... but at the same time, suppose, while constructing the lift object, we need to give it the information about the building object to access various functionalities of the Building class... for example, suppose the speed of the lift is set depending on the number of floors of the Building... hence while constructing the Lift object it must access the functionalities of the Building object which will give the number of floors the building has got...hence in UML terms the lift HAS building... so this is a sure case of circular dependency...

in real java code it will look something as follows:


public class Building {
private Lift lift;
private int floor;
public Building(){
lift = new Lift();
setFloor(15);
}
public int getFloor(){
return floor;
}

public void setFloor(int floor){
this.floor = floor;
}
}//end of class building
//class Lift
public class Lift {
private Building building;
private int Speed;
public Lift(){
building = new Building();
setSpeed();
}

public void setSpeed(){
if (building.getFloor()>20){
//one set of functionalities
//may be the the speed of the lift will be more
this.Speed = 10;
}
else {
//different set of functionalities
//may be the speed of the lift will be less
this.Speed = 5;
}
}

public int getSpeed(){
return Speed;
}
}//end of class Lift


As it becomes clear from the above code, that while creating the Building object it will create the Lift object, and while creating the Lift object, it will try to create a Building object to access some of its functionalities... So, ultimately it will go out of memory and we get a StackOverflow runtime exception...

So how do we handle this problem in Java? We actually tackle this problem by declaring an IBuildingProxy interface and by deriving our Building class from that... the lift class, instead of Having Building object, it Has IBuildingProxy...

the source code of the solution looks like the following...


//IBuildingProxy
public interface IBuildingProxy {

int getFloor();
void setFloor(int floor);
}//IBuildingProxy


//class Building
public class Building implements IBuildingProxy{
private Lift lift;
private int floor;
public Building(){
lift = new Lift(this);
setFloor(15);
}
public int getFloor(){
return floor;
}

public void setFloor(int floor){
this.floor = floor;
}
}

//class Lift
public class Lift {
private IBuildingProxy building;
private int Speed;
public Lift(Building b){
this.building = b;
setSpeed();
}
public void setSpeed(){
if (building.getFloor()>20){
//one set of functionalities
//may be the the speed of the lift will be more
this.Speed = 10;
}
else {
//different set of functionalities
//may be the speed of the lift will be less
this.Speed = 5;
}
}

public int getSpeed(){
return Speed;
}
}

and the code of the main class is

public class CircularDependencyTest {
public static void main(String[] args){
Building b = new Building();
Lift l = new Lift(b);
}
}

So whats the principle behind such work around... It will be clear soon...

As it becomes clear from the code that Building HAS Lift... That is not a problem... Now when it comes to solve the part that Lift HAS Building, instead of the Building object, we have created an IBuildingProxy interface and we pass it to the Lift class... what it essentially means, that the building class knows the memory requirement to initialize the Lift object, and as the Lift class HAS just a proxy interface of the Building, it does not have to care for the Building's memory requirement... and that solves the problem...

Hope this discussion becomes helpful for Java learners...

No comments: