Prototype pattern
Intent
Prototype is a creational design pattern that lets you copy existing objects without making your code dependent on their classes.
Problem
Say you have an object, and you want to create an exact copy of it. How would you do it? First, you have to create a new object of the same class. Then you have to go through all the fields of the original object and copy their values over to the new object.
Nice! But there’s a catch. Not all objects can be copied that way because some of the object’s fields may be private and not visible from outside of the object itself. What can go wrong when copying things “from the outside”?" width=
Copying an object “from the outside” isn’t always possible.
There’s one more problem with the direct approach. Since you have to know the object’s class to create a duplicate, your code becomes dependent on that class. If the extra dependency doesn’t scare you, there’s another catch. Sometimes you only know the interface that the object follows, but not its concrete class, when, for example, a parameter in a method accepts any objects that follow some interface.
Analogy
In some games, we want trees or buildings in the background. We may realize that we don’t have to create new trees or buildings and render them on the screen every time the character moves.
So, we create an instance of the tree first. Then we can create as many trees as we want from this instance (prototype) and update their positions. We may also choose to change the color of the trees for a new level in the game.
Solution
The Prototype pattern delegates the cloning process to the actual objects that are being cloned. The pattern declares a common interface for all objects that support cloning. This interface lets you clone an object without coupling your code to the class of that object. Usually, such an interface contains just a single clone method.
The implementation of the clone method is very similar in all classes. The method creates an object of the current class and carries over all of the field values of the old object into the new one. You can even copy private fields because most programming languages let objects access private fields of other objects that belong to the same class.
An object that supports cloning is called a prototype. When your objects have dozens of fields and hundreds of possible configurations, cloning them might serve as an alternative to subclassing.
Here’s how it works: you create a set of objects, configured in various ways. When you need an object like the one you’ve configured, you just clone a prototype instead of constructing a new object from scratch.
Class diagram
Applicability
Use the pattern when you want to reduce the number of subclasses that only differ in the way they initialize their respective objects.
Suppose you have a complex class that requires a laborious configuration before it can be used. There are several common ways to configure this class, and this code is scattered through your app. To reduce the duplication, you create several subclasses and put every common configuration code into their constructors. You solved the duplication problem, but now you have lots of dummy subclasses.
The Prototype pattern lets you use a set of pre-built objects configured in various ways as prototypes. Instead of instantiating a subclass that matches some configuration, the client can simply look for an appropriate prototype and clone it.
How to Implement
- Create the prototype interface and declare the clone method in it (implement the Cloneable interface). Or just add the method to all classes of an existing class hierarchy, if you have one.
- A prototype class must define the alternative constructor that accepts an object of that class as an argument. The constructor must copy the values of all fields defined in the class from the passed object into the newly created instance. If you’re changing a subclass, you must call the parent constructor to let the superclass handle the cloning of its private fields.
- If your programming language doesn’t support method overloading, you won’t be able to create a separate “prototype” constructor. Thus, copying the object’s data into the newly created clone will have to be performed within the clone method. Still, having this code in a regular constructor is safer because the resulting object is returned fully configured right after you call the new operator.
- The cloning method usually consists of just one line: running a new operator with the prototypical version of the constructor. Note, that every class must explicitly override the cloning method and use its own class name along with the new operator. Otherwise, the cloning method may produce an object of a parent class.
Advantages of Prototype Pattern
Let’s see some advantages of using this pattern
- Adding and deleting products in the middle of a game–By registering a prototype instance with the client, you may easily integrate a new concrete product class into a system. Because a client can install and uninstall prototypes during runtime, this pattern is a little more flexible than other creational patterns.
- Creating new objects by changing their values–Object composition, rather than introducing new classes, allows you to design new behavior in highly dynamic systems by specifying values for an object’s variables.
- Creating new objects by changing their structure – Many apps create things out of parts and subparts. Such apps frequently allow you to create sophisticated, user-defined structures to reuse a single sub-circuit.
- Many designs start by using Factory Method (less complicated and more customizable via sub classes) and grow toward Abstract Factory, Prototype, or Builder (more flexible, but more complicated).
Disadvantages
- For a project with few objects and/or no underlying emphasis on the extension of prototype chains, this is overkill.
- It also keeps certain product classes hidden from the client.
- When the classes under consideration already exist, each subclass of Prototype must implement the clone() function, which can be complex. Also, when their internals involve objects that don’t permit copying or have circular references, implementing clone() can be challenging.
When to use Prototype Design Pattern
- During the runtime, when the concrete classes are instantiated.
- When the expense of producing a product is prohibitively high or complex.
- When you wish to keep your applications, class count to a bare minimum.
- When the client application doesn’t need to know about object creation or representation.