Ubuntu insights, Programming in groovy, java, et als!

Showing posts with label Design Patterns. Show all posts
Showing posts with label Design Patterns. Show all posts

Wednesday, June 20, 2012

Design Patterns: Factory Method Pattern

/**
* A simple implementation of Factory Method Pattern
* using a real time CricketPlayer example
*/


//Base
public interface CricketPlayer{
    public String play();
}


//Subclass
class Bowler implements CricketPlayer{
    public String  play (){
        return "takes a wicket";
    }
}


//Subclass
class Batsman implements CricketPlayer{
    public String  play (){
        return "hits a six";
    }
}


//Factory class - contains the logic of instatiating players
public class CricketPlayerFactory{
    CricketPlayer player;
   
    public CricketPlayer getPlayerWho(String does){
        if(does.equals("bats"))
            player = new Batsman();
        else if(does.equals("bowls"))
            player = new Bowler();
        return player;              
    }
}


//Factory method implementation
public class FactoryImplementation{
    public static void main(String args){
        //create a factory
        CricketPlayerFactory factory = new CricketPlayerFactory();
        //ask factory to instantiate the player
        CricketPlayer player = factory.getPlayerWho("bats");
        //use the player
        System.out.prinln(player. play ());
    }
}

Design Patterns: Singleton Pattern

/**
* A simple Implementation of a singleton
*/
class MySingleton{
   
    static MySingleton singletonInstance;
   
   //****** instantiation ******


    static MySingleton getInstance(){
        if(singletonInstance == null)
            singletonInstance = new MySingleton();
        return singletonInstance;
    }
   
    private MySingleton(){
        //cannot be called public with new
    }


   //****** logic ******   
    ....
    ....
}


MySingleton.getInstance();


FYI, Points to remember

  • Singletons are bad. 
  • They are just glorified statics and hence against OOP principles. 
  • They should be rarely used. A classic example: for logging purposes.
  • Singletons are hard to unit test.
  • Also bad because it is NEVER a good practice to mix instantiation and logic in a single class.