Clean Code- Day 2

Last night, after I published my post on the Mediator Pattern, I got into an ugly fight with my girlfriend. Apparently, she didn’t like the idea of having a mediator controlling the communication between things. “What if some messages are misinterpreted by the mediator, it can cause serious communication issues!”. Probably, it was the fear of losing directness of communication or may be her privacy issues. So, we broke up and today is the day of being single again. Because she is insane and I just made up that story. Which however, brings us to an important design pattern known as Single(ton)!

The Problem

Lets say that you have are building a really cool web application which does something uhh…. cool! And there are certain resources which should be shared among different entities in your app. For example, you have a database connection which should be shared by various database transactions (trust me, you certainly don’t want to create a new database connection for every request! Why? because it takes a lot of effort, both CPU and I/O to set up and tear down connections every time). So you set up your connection once when your application starts and then as long as your application is running, every request uses the same connection. Now some of you Geeks might be laughing out loud and calling me nuts for using a single database connection for your “cool” app. Its just to keep things simple for this discussion, you can have a connection pool abstracted out as a singleton as well. Anyways, back to the point. Now how do you share this connection among different entities in your app….

The Solution- Singleton Pattern

What the heck does Singleton mean any way? It just means being Single, maybe… Singleton pattern guarantees that at any given point in time, one and only one instance of your class exists and every body else uses the same instance though out the life cycle of your application. You DON’T instantiate new instances of the singleton classes. How you enforce this restriction depends on your language but lets see how to do in Java. This is just one way of implementing it by the way…

public class DatabaseConnection {
    static DatabaseConnection sharedConnection = new DatabaseConnection();
    //Make the constructor private.
    // So it cannot be used anywhere outside this class
    private DatabaseConnection(){
        //do your initialization
    }
    // a super sophisticated database call to save some data..
    public void saveData(String data){
        System.out.println(“Yay, I have saved the data”);
    }
}
public class CoolApp {
    public static void main(String[] args){
        //lets get the database connection
        // You cannot call new DatabaseConnection()
        // we made the constructor private
        // the only way to get the database connection is 
        //by using the sharedConnection
        DatabaseConnection connection =    DatabaseConnection.sharedConnection;
        connection.saveData(“I am some important data that needs to be saved in the database”);
    }
}

We first make the constructor of our DatabaseConnection class private, so it cannot be accessed by any where else, outside the DatabaseConnection class. Next we create a static sharedConnection property which is initialized to a DatabaseConnection instance. Inside the main, we get the database connection by calling DatabaseConnection.sharedConnection. Every entity gets the database connection this way because you cannot create new instances of DatabaseConnection since the constructor is private. Thus every request can use the same database connection rather than creating a new one every time.

How can you be sure that you have implemented the Singleton Pattern correctly? Well, if you find yourself creating new objects of your Singleton class in different places of your application, then you know that you messed up. Most often, the shared instance is initialized within the Singleton class (like we did it here).

I hope you find this useful. Happy Hacking.