Prototype Pattern

The prototype design pattern is used in scenarios where an application needs to create a number of instances of a class that have almost the same state or differ very little.

A prototype is a template of any object before the actual object is constructed. In Java, it also has the same meaning. The prototype design pattern is used in scenarios where an application needs to create a number of instances of a class that have almost the same state or differ very little.

The prototype pattern is a creational design pattern in software development. It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

In the prototype design pattern, an instance of the actual object (i.e., prototype) is created in the beginning, and thereafter, whenever a new instance is required, this prototype is cloned to have another instance. The main advantage of this pattern is that it has a minimal instance creation process, which is much more costly than the cloning process.

Please ensure that you want to deep clone or shallow clone your prototype because both will have different behavior on runtime. If deep copy is needed, you can use a good technique given here using in memory serialization.

1. Design Participants

  • Prototype: This is the prototype of the actual object, as discussed above.
  • Prototype registry: This is used as a registry service to have all prototypes accessible using simple string parameters.
  • Client: The client will be responsible for using the registry service to access prototype instances.

2. Problem Statement

Let’s understand the prototype pattern using an example. We are creating an entertainment application that will frequently require instances of the Movie, Album, and Show classes.

We do not want to create and initialize these instances every time, as it is costly. So, I will create their prototype instances, and every time I need a new instance, I will just clone the prototype.

3. Prototype Design

Let’s start by creating a class diagram.

prototype-pattern-class-diagram-1492563

The above class diagram explains the necessary classes and their relationship.

Only one interface, “PrototypeCapable” is new addition in solution. The reason to use this interface is broken behavior of Cloneable interface. This interface helps in achieving the following goals:

  • Ability to clone prototypes without knowing their actual types
  • Provides a type reference to be used in the registry

Their workflow will look like this:

prototype-pattren-sequence-diagram-7033432

4. Prototype Pettern Implementation

Lets hit the keyboard and compose these classes.

PrototypeCapable.java

public interface PrototypeCapable extends Cloneable {

  public PrototypeCapable clone() throws CloneNotSupportedException;
}

Movie.java, Album.java and Show.java

// Movie.java

public class Movie implements PrototypeCapable {

  private String name = null;

  // Getter and Setter

  @Override
  public Movie clone() throws CloneNotSupportedException {
    System.out.println("Cloning Movie object..");
    return (Movie) super.clone();
  }

  @Override
  public String toString() {
    return "Movie";
  }
}
 
// Album.java

public class Album implements PrototypeCapable {

  private String name = null;

  // Getter and Setter

  @Override
  public Album clone() throws CloneNotSupportedException {
    System.out.println("Cloning Album object..");
    return (Album) super.clone();
  }

  @Override
  public String toString() {
    return "Album";
  }
}

// Show.java
 
public class Show implements PrototypeCapable {

  private String name = null;

  // Getter and Setter

  @Override
  public Show clone() throws CloneNotSupportedException {
    System.out.println("Cloning Show object..");
    return (Show) super.clone();
  }

  @Override
  public String toString() {
    return "Show";
  }
}

PrototypeFactory.java

public class PrototypeFactory {

  public static class ModelType {

    public static final String MOVIE = "movie";
    public static final String ALBUM = "album";
    public static final String SHOW = "show";
  }

  private static java.util.Map<String , PrototypeCapable> prototypes 
      = new java.util.HashMap<String , PrototypeCapable>();
 
  static {
    prototypes.put(ModelType.MOVIE, new Movie());
    prototypes.put(ModelType.ALBUM, new Album());
    prototypes.put(ModelType.SHOW, new Show());
  }
 
  public static PrototypeCapable getInstance(final String s) throws CloneNotSupportedException {
    return ((PrototypeCapable) prototypes.get(s)).clone();
  }
}

5. Demo

Lets test the implementation by creating new objects using the prototypes.

public class TestPrototypePattern {
	public static void main(String[] args) {

		try {
			String moviePrototype  = PrototypeFactory.getInstance(ModelType.MOVIE).toString();
			System.out.println(moviePrototype);

			String albumPrototype  = PrototypeFactory.getInstance(ModelType.ALBUM).toString();
			System.out.println(albumPrototype);

			String showPrototype  = PrototypeFactory.getInstance(ModelType.SHOW).toString();
			System.out.println(showPrototype);
		} catch (CloneNotSupportedException e){
			e.printStackTrace();
		}
	}
}

When you run the client code, the following is the output.

Cloning Movie object..
Movie
Cloning Album object..
Album
Cloning Show object..
Show

6. When to use?

When an object is required that is similar to an existing object or when the creation would be expensive compared to cloning.

I hope you liked this post on a Java prototype pattern example. If you have any questions, drop a comment.

Happy Learning !!

Leave a Comment

  1. Why do we have to create new 3 objects (movie, album, show) when loading PrototypeFactory?
    btw everything else is great.

    Reply
    • because movie, album, and show are different classes and when asked they should return their own instance. what can be done here to make sense is that instead of creating the movie, album and show with a default constructor, A parameterized constructor can be used with some default values.

      Reply
    • Because the idea of the pattern is to create serval instances of objects using the cloning technique instead of using an instance creation. We want serval objects of these prototype templates: Movie, Album, and Show.

      Reply
  2. Your main method should be demonstrating something like

    PrototypeFactory myCopyMaker = new PrototypeFactory();
    
    Movie myMovie = new Movie();
    myMovie.setName("Red Planet");
    
    Movie clonedMovie = myCopyMaker.getInstance(myMovie);
    
    //Verify myMovie and clonedMovie have the same names but they are different objects
    
    

    You need to change your PrototypeFactory class to spit out the copy of given PrototypeCapable object type.

    Your example doesn’t demonstrate the Prototype pattern because it doesn’t copy/clone the object we want to copy/clone. The ‘prototype’ part of the pattern is missing :)

    Imagine a scenario where the object’s state evolves over time and it is significantly different from the creation time. This pattern is handy when you want to make one or several copies of this evolved object.

    Reply
  3. Hi,
    I didn’t get what is the difference between cloning an object by implementing Clonable(I) normally,and by using prototype pattern.what is the advantages in prototype design pattern over normal cloning process….

    Thanks in advance….

    Reply
  4. Very good article,easy to understand the design patterns with real examples and also with perfect class diagram.
    Really useful

    Reply
  5. I didn’t see much of value of introducing PrototypeCapable interface to enable clone() method, which is build-in in Object. It is not the contract obligation broken on Cloneable in java, it is the implementation was build-in for a purpose to make sure the Clone mechanism is working even across inheritance hierarchy, otherwise, the type inheritance will be mismatch. That means, there is no free way to correctly implement “clone” behavior defined in PrototypeCapable interface other than call “super.clone()” which binding to Object.clone build-in mechanism. What’s the point?

    Reply
    • In java, to make an object cloning supported, it takes two steps: 1) Implement Cloneable 2) Override clone()

      Lets say, a new developer joined a team which knows only basics in java. He is assigned a task in which he has to add one more object in prototype registry(factory) i.e. “Ticket”.

      By which design, you can force that developer to perform above both steps??

      It is only possible when you tie both steps together otherwise behavior will be surprising.

      Reply
      • Lokesh,
        So, in other words what you mean to say is the only purpose of this prototype pattern is to introduce an interface which actually has the method clone( ), that somehow Cloneable interface missed in it, so that the rule of overriding the clone( ) method is followed in future.

        That’s the only only only thing in this whole jargon I guess. That’s it. Nothing else. I wonder why we create so many classes and confuse things when all we are doing here is just creating one interface! This whole thing is confusing and not worth the effort.

        By the way, that little java programmer has to learn stuff, we cannot design software components keeping worries of junior programmers in focus. Someone who can spend 1 or 2 hours to understand how java is handling the concept of cloning its objects can easily understand how to override clone and why it’s important to call the clone of super class.

        Frankly, I think this is a design pattern is confusing and not worth studying and remembering, rather programmers should spend time on understanding the basics of cloning in java, that is enough.

        Your thoughts?

        Thanks,
        Saurabh

        Reply
        • Hi Saurabh, Thanks for sharing your thoughts. Much appreciated.

          I believe that design patterns will feel like a burden if someone will try to apply them forcefully. They are solution of some specific problem. Until you encounter the problem in your design/implementation, you shouldn’t inject patterns just to make code fancy. I agree with you that simplicity is the best thing you can do with your code.

          Regarding prototype design pattern, I do not feel that it is not worth studying. Yes, proper use of clone() will also achieve the target, but you need some code to wrap the actual logic somewhere centralized. So when in future, a junior programmer find a tiny fault in cloning process, he does not have to change it multiple places.

          Remember that if you have to change you code in more than place, to solve one specific problem, then your code need redesign/refactoring.

          Reply
        • First of all, design patterns are not designed for java only. There is clone() in java but this is not the entire universe of programming.
          Second, clone() works his own specific way, sometimes we want to achive other results and have to get rid of default clone() behaviour.
          Third, I do not agree that ‘keep it simple’ always do the trick. Usually, you ‘keep it simple’ on one level and ‘make it very hard’ on the other: only global look and careful design let you avoid critical difficulties. Applaying design patterns makes code ready to develop and change; avoid problems before even noticed. My expirience tells me, that it really works.

          Reply
  6. Using an enum for the ModelType is way better, plus strongly typed.

    As a matter of fact, you can do all of this with enums. I love enums ;-)

    Reply
  7. Dear Lokesh
    ModelType is static subclass of PropertyFactory class ,so Following correction is required in running class TestPropertytypePattern

    String moviePrototype = PrototypeFactory.getInstance(PrototypeFactory.ModelType.MOVIE).toString();

    rest is fine ,I have tested it

    Reply

Leave a Comment

About Us

HowToDoInJava provides tutorials and how-to guides on Java and related technologies.

It also shares the best practices, algorithms & solutions and frequently asked interview questions.