Saturday, April 27, 2013

Enums and Singleton - A Friendly Relation


Those coming from C++ background must be knowing what enumerated datatypes are. But Java enums may give you some surprises. Enums are used to define the predefined set of constants that are logically related to each other. For an example, a set of months names or a set of colours or currency notes that are fixed in numbers.

Enums in Java were introduced in jdk 1.5. Prior to that developers had to create a class containing public static final integers to define constants. Something like this:

public static final int CONST1 = 0;
public static final int CONST2 = 1;

They could be accessible using CLASS_NAME.CONST1, and so on.
Though introduced late in Java, enums are much more powerful than any other programming languages.

Here are some of its highlights:


  • Enums can be defined as simply as following:


public enum Color
{
  RED, BLUE, BLACK, GREEN
}

Keep in mind that enums can be compared only with enums and not with integers or any other data type. Enums can be compared in switch statement as well.


  • Enums are like classes and interfaces. They can have member variables as well as member functions defined in it. Unlike C++ where enum can contain only constants. 

public enum Color
{
  RED, BLUE, BLACK, GREEN;
  
  private int x;
  public void show()
  {
    System.out.println("inside show" + x);
  }
}


  • Enums can have abstract methods which mean that the methods can behave differently for different values of enum variable.

public enum Color
{
  RED {
    @Override
    public void show()
    {
      System.out.println("inside show" + RED);
      
    }
  }, BLUE {
    @Override
    public void show()
    {
      System.out.println("inside show" + BLUE);
      
    }
  }, BLACK {
    @Override
    public void show()
    {
      System.out.println("inside show" + BLACK);
      
    }
  }, GREEN {
    @Override
    public void show()
    {
      System.out.println("inside show" + GREEN);
      
    }
  };
  
  private int x;
  public abstract void show();
}


  • Another special behavior different from C++ is that it can implement interfaces as well. By default it has implicitly implemented Serializable and Cloneable interfaces.

public enum Color implements Runnable
{
  RED, BLUE, BLACK, GREEN;
  
  @Override
  public void run()
  {
    // TODO Auto-generated method stub
    
  }
}


  • Enums can have private constructor. In the following example enum variable with RED as value would have x as 1 and enum variable with BLACK value would have x as 7. Defining RED(1) instead of RED calls the contructor.


public enum Color
{
  RED(1), BLUE(3), BLACK(7), GREEN(9);
  
  private int x;
  private Color(int in_x)
  {
    this.x = in_x;
  }
}


Though enums can implement interfaces but they cannot extend the classes.

For more information on enums.
http://javarevisited.blogspot.in/2011/08/enum-in-java-example-tutorial.html

Now how enums can be used in Singleton pattern. We know how to implement a Singleton pattern. A static private object, a private constructor, and a public static getter method of the instance  in a class form a Singleton class.

Then there comes popular multi-threading issue which can be easily solved using double checking solution

public class Singleton{
     private Singleton instance;
  
     private Singleton(){}
  
     public Singleton getInstance(){
         if(instance== null){
            synchronized(Singleton.class){
                // Double check here
                if(instance== null){
                    instance= new Singleton();
                }
            }
         }
         return instance;
     }
}

The other possible and better way of implementing Singleton is by having early initialization of the instance variable. The instance would be initialized when the class is first loaded and thus ensures the that only single instance is created.

public class Singleton{

    private static final Singleton instance = new Singleton();
  
    private Singleton(){}

    public static Singleton getInstance(){
        return instance ;
    }
}

So these are some of the possible variants of Singleton pattern. But these all are using classes. The most simple way of implementing the Singleton pattern came into the picture when enums were introduced in the world of java. 

public enum Logger
{
  instance;
  
  public void log(String str)
  {
    
  }
}

That's it!! Java ensures that Enums are type safe as well as thread safe. The instance can be accessed in following way:

Logger.instance.log("test");

Since enums can implement any of the interface (they are Serializable and Cloneable) and can also have member methods, they can be pretty useful in achieving Singleton behavior.

This is the power of enums and thus the power of java.

Read more: http://javarevisited.blogspot.com/2012/07/why-enum-singleton-are-better-in-java.html#ixzz2RZA7XTvL

Thanks for reading!

Tuesday, April 23, 2013

Dependency Injection in Spring - Short Article


Any software's life depends upon it's architecture and design. Stronger is the design better would be the sustainability against the series of changes that come along with the journey. Weaker design makes the software vulnerable and thus fragile. There are certain design principles that act as the pillars of good design. You may not be knowing the design patterns but following these principles could lead you to strong design. 

The beauty of java is that it's frameworks force you to follow certain principles. One of these is Dependency Inversion in Spring.

Let us understand this principle through a hypothetical example. Suppose there is a car manufacturing unit which manufactures different models of the car. Now, initial code may look like this:

class CarManufacturingUnit
{
 public void setup(int index)
{
    if (index == 0)
    {
      return new Omni();
    }
    else if (index == 1)
    {
      return new Alto();
    }
    else ...
  }
}

CarManufacturingUnit --> Omni, Alto

Here the class CarManufacturingUnit is directly depending on the low level classes  of different car models viz. Omni, Alto, Esteem, Swift etc.. That means any modifications done to these low level classes would eventually may modify the high level class as well. We may not want to get into the situation where code suffers from the ripple effect of any small change which would then result in increasing testing effort as QA would have to test other scenarios as well.

To get out of this problem we could create an abstraction layer between these two levels. The high level class would depend only on the abstraction of these low level classes. Some what like this:

class CarManufacturingUnit
{
  private CarFactory carFactory;
  public void setup(int index)
  {
    CarModel carModel = carFactory.getCar(index);
  }
  
}

class CarFactory
{
  CarModel getCar(int index)
  {
    if (index == 0)
    {
      return new Omni();
    }
    else if (index ==1)
    {
      return new Alto();
    }
    else ...
  }
}

Here, CarManufacturingUnit doesn't depend directly upon the low level classes, rather an abstraction layer CarModel has been created.

CarManufacturingUnit --> CarModel <-- Omni, Alto

Thus by having the abstraction we have inverted the dependency. Now car manufacturing unit doesn't depends directly on models of the car. Changing any of these models wouldn't effect the high level class. 

The principle is also called as Inversion of Control(IoC). This dependency Inversion can very easily achieved using factory class or factory methods which segregate the object creation logic from the main business method.

Now when we study spring in Java we would found that this is the core principle of spring technology. Spring achieves this principle and forces in developers to use this by Dependency Injection technique.

class CarManufacturingUnit
{
  private CarFactory carFactory;
  
  public void setCarFactory(CarFactory carFactory)
  {
    this.carFactory = carFactory;
  }
  public void setup(int index)
  {
    CarModel carModel = carFactory.getCar(index);
  }
  
}

The low level object creation role has been taken care by spring container's initialization logic itself. Whenever the object is instantiated it's dependencies are also get initiated automatically. 

In the above example, we have provided setter method for carFactory member variable. The entry in bean registry XML creates the bean of CarFactory and injects it's object in dependent class, CarManufacturingUnit via setter method. We can have constructor as well in place of setter.

Entry in spring bean:

<bean id="CarManufacturingUnit" class="CarManufacturingUnit">
     <property name="carFactory" ref="carFactory"/>
</bean>


<bean id="carFactory" class="CarFactory">
</bean>


Thus spring has completely segregated the business logic and object creation logic. Developer needs not to take care of objects life cycle as well. Spring controls the their life cycle pretty well.

I tried to cover Dependency Inversion / IoC principle implemented inside Spring container.