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

Wednesday, October 5, 2011

My Android AsyncTask implementation vis-a-vis Command Pattern...

Note: If someone wants to learn about the Asynctask internal, please have a look at this document.

As i was developing a sample Android App to showcase the Android AsyncTask, i found it very much similar to the Command design pattern. i would like to share this with you...


Let me first state about the Command design pattern. The purpose of the command pattern is to associate a command object with its receiver where the receiver knows what to do when this command is called... We have an interface called command, from where we deduce different concrete commend classes... The client creates the concrete command objects passing the information of the receiver for that command... And when the invoker ( which is generally a framework object) calls the execute method of the command, the concrete command actually executes it with the help of the Receiver’s functionalities...


The class diagram of the command pattern is as follows:

And the sequence diagram is as follows:




Now let me decipher my App to show how it implements the command pattern... the class diagram of this application looks like the following:



As it becomes clear from the code, the client (which is the Activity class) creates a concrete command class, the Callback interface through the concept of Anonymous inner class (see the code c = new CallBack() {.....}; it then stores this command in the invoker (the MyAsyncTask class) by passing the reference to the invoker (see the line of code aTask = new MyAsyncTask(c)).. . the invoker (the MyAsyncTask class here) stores a reference to this command object... then if something interesting happens, the invoker calls the functionality from the callback interface (the command)... the functionality of the callback interface have been implemented in the Client (the Activity class)...

hence i think that my implementation of the Asynctask is very similar to the Command design pattern implementation...

Hope this discussion helps the android learners...

Here is my AsyncTask implementation.. Here you can find the callback interface... And you can find the main Activity class here.

And here goes the apk of the sample app... You can clone the whole source from here...