Factory pattern – Design Patterns in Java/J2EE

Creational pattern deals with the creation of objects and it hides the complex logic involved in the object creation object from the clients. One of the common creational patterns is the Factory pattern and it is used extensively in Applications. Let us understand what factors should be considered in mind while designing a Factory pattern or a Factory method pattern.

also read:

Depending on the client input, the Factory pattern may create and return an object which is one of the several sub-classes in consideration. But the reverse is not always true. Any classes that creates and returns objects should not be considered as Factory classes.
Let us take an example of a Factory class which is used to create Button objects. Assume that we have two variations of Button objects, one is the WindowsButton in an typical Windows Operating system and the other is the LinuxButton in Linux operating System.
Consider the following Button class, which has a single draw() method. Since this class is a generic class, we have made it as abstract.

package tips.pattern.factory;
public abstract class Button {
    public abstract void draw();

Given below are the concrete implementations of the Button class, WindowsButton and LinuxButton, each providing a much simplified implementation for the draw() method.

package tips.pattern.factory;
public class WindowsButton extends Button{
    public void draw() {
        System.out.println("Drawing Windows Button");


package tips.pattern.factory;
public class LinuxButton extends Button{
    public void draw() {
        System.out.println("Drawing Linux Button");

Now let us come to the core implementation, the Factory class itself. The ButtonFactory class has one static method called createButton() which the clients can invoke to get the Button object. Note the return type of the method, it is neither WindowsButton nor LinuxButton, but the super type of the both, i.e, Button. Whether the return type of method is WindowsButton or LinuxButton is decided based on the input operating system.

package tips.pattern.factory;
public class ButtonFactory {
    public static Button createButton(String os){
        if (os.equals("Windows")){
            return new WindowsButton();
        }else if (os.equals("Linux")){
            return new LinuxButton();
        return null;

Given below is the client Application that makes use of the above ButtonFactory class. The client is un-aware of the fact there is multiple implementations of the Button class. It accesses the draw() operation through a single unified type Button.

package tips.pattern.factory;
public class FactoryClient {
    public static void main(String[] args) {
        Button windowsButton =
        Button linuxButton =



About Krishna Srinivasan

He is Founder and Chief Editor of JavaBeat. He has more than 8+ years of experience on developing Web applications. He writes about Spring, DOJO, JSF, Hibernate and many other emerging technologies in this blog.

  • Premkumar Masilamani

    The example is good. How does this code perform in a multi-threaded environment?
    If two threads accessing the same factory at the same time with the arguments “windows” and “linux”, what would be the result?

    Shouldn’t this be a singleton class?

    • winnetou

      There is definitely nothing to do with this code in a multithreaded environment. Because there is no shared or global data access in the method, an arbitrary number of threads can call it the same time and it will work perfectly.

      And if it would have a thread-safety issue, a singleton pattern would absolutely not solve it. Singleton has nothing to do with thread-safety, these terms are orthogonal (there can be thread-safe and thread-unsafe singleton classes).

  • Raheel Arif

    nice tutorial

  • Venkat

    good and easily understandble

  • venu

    awesome!! thanks a lot!!

  • Pingback: Working with Virtual Proxy Pattern()

  • Pingback: Design Patterns in Java()