Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I'm learning about design patterns in school. Many of them are silly little ideas, but nevertheless solve some recurring problems(singleton, adapters, asynchronous polling, ect). But today I was told about the so called 'Prototype' design pattern.

I must be missing something, because I don't see any benefits from it. I've seen people online say it's faster than using "new"' but this is doesn't make any sense, since at some point, regardless how the new object is created, memory needs to be allocated for it ect.

Furthermore, doesn't this pattern run in the same circles as the 'chicken or egg' problem? By this I mean, since the prototype pattern essentially is just cloning objects, at some point the original object must be created itself (ie, not cloned). So this would mean, that I would need to have an existing copy of every object that I would ever want to clone already ready to clone? Seems stupid to me.

Can anyone explain what the use of this pattern is?

Original post:

share|improve this question
What can we tell you that the original post (on which you already accepted an answer) doesn't already provide? – Robert Harvey Dec 15 '12 at 0:04

Allocating memory might not be the slow part of creating your object. If the object is data driven or otherwise the result of a calculation, it is sometimes prudent to cache the result so that that result can be cloned rather than re-done. Thus, the Prototype pattern.

share|improve this answer

There are lots of uses for Prototype, small and large...JavaScript and Io are both prototype based languages for instance. In one sense it is object based inheritance (vs class based), which is a pretty cool concept, IMO.

From a nuts and bolts design pattern perspective, Prototype works well if you have some specific case where the "cost" of creating an object is high, does not consist of only memory allocation, and you need more than one instance of that object...the higher the count the more useful the pattern.

Because of its general utility for solving this specific case, Prototype combos well with other design patterns; its frequently listed as complementary to other patterns in the GoF book.


You can also do some fun little tricks w/ Prototype. For instance I recall a custom snippets based code generator utility I wrote a number of years ago that had a CodeScripter prototype that had a few instance specific things like target path, filename, some metadata options, and a mechanism to specify which snippets to use in what pulled in a bunch of different templates from files on disk on creation, and then specific output scenarios would clone the CodeScripter thus avoiding the initialization cost, push in the appropriate info for the instance, and configure the appropriate selection of ordered snippets.

Of course, I could have solved that problem a lot of ways, but though it had its downside* the volume of outputs that needed to be generated and the fact that most of the scenarios were very similar and there was a high overlap in the snippets made Prototype a neat option.

* The downside was that the CodeScripter prototype was unabashedly a god object...but in the case of that utility I found it to be an acceptable tradeoff.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.