Question about Prototype Pattern

Quote:

Original post by Servant of the Lord I'm reading through the 'Design Patterns' book, and was having trouble understand what the Prototype Pattern does that the Factory Method doesn't do. From the way the authors talked about it, it sounds like it does something important, but I can't figure out what!

The problem with design patterns is that they don't deal with design, but with implementation.

From design perspective, there is no important difference between any of the creational patterns.

The actual design of Factory is:

Instance factory(Arguments);

And that covers all creational patterns, including singleton. Everything else is just implementation details.

Prototype is just implemented in such a way that Arguments are resolved into an instance, and that instance is then cloned.

Prototype differs from Factory in that it assumes object specification happens after object creation. So you can create objects of a class, say CMonster, configure this object to your liking (monster.setModel("critter"); monster.setScript("critter"); ...) and then store that object as a prototype to be cloned. It can also get much more complex than that.

Prototype is basically useful for runtime configurated objects. You can eg. implement a function void call(const string& method, const vector& args) in your prototype class and as the prototype can be configured to support a widely differing range of such calls in runtime, different prototype objects, while technically sharing the same base interface (class), may well be considered as having different classes.

I suggest you have a look into prototype-based languages such as &#106avascript to see how that pattern is put into practice.

Thanks, I think I understand it now. The code snippet that was confusing me, was using the Prototype Pattern inside of a Factory, so I got confused by the almost identical layout of the code. The Factory Method is used to create instances of objects. The Prototype Pattern also creates instances, but those instances can be new types of objects by mixing together old ones.

&#106avascript is one of the languages I intend to learn, but I doubt I'll get around to it anytime soon.<br/><br/>Thank you for the help!

Design Patterns are not implementation; some languages make using a particular pattern easier (or harder).
The DP book provides example implementations to help communicate the pattern.

Factories create a set of objects, bundling them together so that you cannot create mismatched objects.

Prototypes let the run-time configure the default object that is created.

e.g. Suppose you had a part of a game where the user designed a battle droid, selecting its weapons, shields, colors, implants, color scheme, place decals, etc... something with elaborate configuration. The prototype idea is that you let them edit one such "prototypical instance" (where the name comes from) which is kept out of the actual game-play. It is cloned to create objects to inject into the actual game.

A factory of prototypes is a common combination.
e.g. You could have one factory per player that bundles their unit configurations and a prototype for the actual config each one:
{Trooper, Droid, Speeder, ... }
Then from the 'outside world' it just says Player[x].CreateDriod(), Player[y].CreateTrooper() and out pops their unit.

Quote:

Original post by Shannon Barber Factories create a set of objects, bundling them together so that you cannot create mismatched objects. Prototypes let the run-time configure the default object that is created.

I thought the whole point of Factory was to separate the creation of the object from your code, to allow you to swap around what the Factory creates at runtime?

Quote:

Suppose you had a part of a game where the user designed a battle droid, selecting its weapons, shields, colors, implants, color scheme, place decals, etc... something with elaborate configuration.

I don't get why Prototype is needed here where other patterns wouldn't work just as well. Are you saying the configuration of the battle droid isn't know beforehand? One droid might have weapons, shields and color, but no implants, and another droid might have weapons, implants, no shields, decals, and other things, so the combination of objects, and the types of objects, isn't known?

If they are known, why couldn't I just have a droid like this: (C++ code example)

I'd leave them all NULL at construction, and only fill them if a droid has one of whatever.

Are you saying, a droid could have a feature that I am not hardcoding into it, a=so I'd deal with that by doing something like this? (DroidFeature being a interface for features that inherit from it)

A factory generally takes the configuration of the droid as parameters and returns a droid.

What if you had a droid that could build itself though? It's not built in a factory, it makes a clone of itself right there.

And that goes straight to code. The factory pattern is a single object that sits there, takes parameters and spits out new objects. A prototype is an object that sits there and duplicates itself (sometimes with a little variety).

So then, the only differences between Factory and Prototype is these two things?
1) Factory is a separate class used to create the product; Prototype is its own creator.
2) Factory initializes objects to their default values; Prototype initializes them to the Prototype's values.

Is that all there is to it? (I say 'all', but am not implying that those two things aren't significant, I just want to make sure I am getting it straight)

In short, Prototype is a 'factory' that produces more of itself, setting the products it creates to its own values at creation. Is that correct? Is there anything else that differs between the two?

Quote:

Original post by Servant of the Lord In short, Prototype is a 'factory' that produces more of itself, setting the products it creates to its own values at creation. Is that correct? Is there anything else that differs between the two?

Prototype describes the mechanism where new instance is created from existing instance. New instance should be conceptually same as original. Usually, this means deep or shallow copy of original object.

C++ copy constructor is a Prototype pattern.