[C# Design Patterns] The Prototype Pattern

This post will demonstrate the Prototype design pattern – another pattern for creating instances of objects.

This pattern creates new objects, by “cloning” them from a single (prototype) object.




If we were writing a role-playing game, we might want to create multiple instances of monsters for the player to fight.


Non-Pattern Version

In the non-prototype version, is we want a new Monster object, we need to call the constructor. If we don’t, and just set a new Monster variable equal to the first Monster object, both variables will be pointing to (referencing) the same object.






In the first test (Test_ReferenceProblem), we create “standardGiantSpider” – the “base” giant spider object.

When we create a new spider variable, and set it to standardGiantSpider, it will not be a separate object. Instead, it will “reference” the original standardGiantSpider object.

Anything change done to one spider object, appears on all spider objects, because they are all pointing to a single object.

To prevent this problem, without using the Prototype design pattern, we would need to call the constructor for every Monster object we create – as in the second test (Test_ReferenceProblemSolution).



Pattern Version – Simple



The constructor is called the first time, to create a prototype giant spider object. To create more giant spider objects, we will call a “Clone()” method on the prototype giant spider object. This will create completely new objects, because the Clone method calls the Monster constructor.



In the second test (Test_PrototypePattern), we call the Clone method on the initial standardGiantSpider object. Because the Clone method return a “new Monster”, the additional spider variables are referencing individual, unique objects. Anything done to one spider variable will not affect the other spider variables.


Pattern Version – More Complex

Here is a more practical scenario for using the Prototype design pattern.

In this version of the Monster class, the constructor loads a LootTable list. These are items the Monster could have in its inventory, with the percentage of it having that item.

In a real program, we would probably load this from the database – although, for this example, I manually populate the LootTable with LootTableEntry values.

If we called the constructor every time we created a Monster object, it would need to re-run the database call. So, in this example, the Clone method calls a private constructor that populates the LootTable property with the values from the prototype’s LootTable property.






In both these scenarios, we could have created the Monster objects using the Factory design pattern. The Prototype design pattern is just another “tool in your toolbox” – to use when it seems appropriate.



Where I’ve found it useful

I usually do not need to use this in my business applications. However, I have used it in a game – just like in the “Better Example” version.

This pattern is most useful when you’ll need to create multiple instances of an objects, and the constructor has a lot of initialization to perform. With a prototype, you only need to do that initialization once.


All my design pattern lessons

Source code for my design pattern lessons


Leave a Reply

Your email address will not be published. Required fields are marked *