Software Design - The Prototype Pattern

Our tour of the creational patterns takes us to one of the fastest ways to create a new instance.  The prototype pattern provides an option to clone an instance rather than create and then set values.  This approach has a variety of uses that can reduce coding and execution time.

It helps to start with the "Gang of Four" definition and then we will dig into that.

The benefit of this pattern is that we replace the constructor with a clone method.  This approach can include parameters for the clone to limit/specify the values to clone.  On the other hand, it can do an exact clone.  Thus, we have a path to creating instances quickly at runtime based on the source instance.

There is a wide range of uses for this pattern.  We have already mentioned the reduced code to instantiate and initialize an instance.  This pattern also makes transactions easy.  We can clone an object, make changes, and then eventually go back to save those changes.  Serial processes can get a boost as we can clone from a source object rather than a hard-coded initialization routine.  Therefore, the runtime values can be used to define that source instance. A typical use of this pattern is when you have a portion of class properties that remain the same across multiple instances.  Think of a family.  Each member has the same address.  You could create an instance for each member and set the address for each case.  However, the prototype pattern can be used to set the values once and then clone that base instance before setting member-specific data.  When this approach is taken, you have instances with identical values, yet each one is entirely self-contained.  This can be excellent for reducing the costs of high repetition processes like recursion.

A prototype pattern is not much more than an interface.  You define the clone method and then the classes that use the interface implement a clone method.  There are even built-in clone methods for some of the modern languages to assist.  Of course, those do a full-instance clone, and you may not want to go to that level.  Properties like creation stamps, modified dates, and identifiers (among others) would be an annoyance to clone and then have to reset them.  There could also be a danger in cloning those values as they might not get correctly set after a clone and essentially duplicate data.  This is an error I have seen caught a lot of times when attempting to save data to a database.  Primary key errors get raised and improper cloning is the culprit. This pattern is one that is worth utilizing often.  There is a lot that can be done through cloning instead of constructors that eases development effort and makes instantiation much easier at runtime.  You might even find some ways to use cloning as a mechanism for lazy loading or just-in-time initialization of values.