Simple Pattern Question

[Jeffrey Pony]

why should I use the prototype pattern to clone rather than
just creating an object directly? Kindly elaborate the explanation .

Thanks in advance.

[Snigdha Solanki]

Prototype pattern is used when creating an object is either very time consuming or complex or both.So rather than creating more instances you can make copies of original instance and modify them as needed.
I would appreciate if anyone could provide a practical example regarding usage of this pattern.
[ July 12, 2002: Message edited by: Snigdha Solanki ]

[Jeffrey Pony]

when creating an object is either very time consuming or complex or both.

I would appreciate if you/someone could elaborate the same.

Thanks.

[Karthik Guru]

Am not an xpert in applying patterns. But let me try..
I think Java's clone() method does it.
But then there might be somethign more to the protoype pattern which am not aware of.
An example could be:
Say you are constructing a heavy weight object through a remote call to a remote server which takes a lot of time to construct.
Say the remote server in turn talks to a
proprietry system and fetches the data.
There are 2 classes A & B which work on the *same* data but manipulate it in different ways.
If Class B and Class A share the same reference, changes made by one might reflect in the other.
You might not want that.

Class A{
 //this is the heavy object i was referring to
 SomeRef ref;
 manipulateRef(){
  //manipulates ref
 }
 Object getRefClone(){
  return a copy of ref
 }
}
class B{
 SomeRef ref;
 B(A a1){
  this.ref = a1.getRefClone();
 }
 mainpulateRefInADifferentWay(){
 }
}
A a = new A();
B b = new B(a.getRefClone())

So
1. you did'nt initialise ref again in class B
2. @ the same time by clonign you also have your own copy of ref.
Hope someone w'd correct me if am wrong.

[Frank Carver]

That's not entirely where I see the use of the Prototype pattern. I tend to use it more where the default case for something might change as the application is used.
Imagine something as simple as the "font" choice in your Wordprocessor. Many wordprocessors have a similar way of working: a font chooser of some sort which does double duty - as a way of setting the default font for future typing, and as a way of chaging the font of a selected area. To change the font of a selected area, highlight it and update the "default" font style. The new "default" style is then applied to the selected area.
Let's consider a way of modelling this. Our very simple word processor has an array of chracters, and some FontStyle objects each of which applies to a range of characters (c.f. Flyweight pattern).
It also has a "special" FontStyle object which represents the current default style for new typing (It's the same class, but it might have a null text range, for example). Let's assume the default starts at "Arial, 10pt, regular".
So I type some characters. They have to have some style, so a new FontStyle object is created as a copy of the current default style. After a few words, I pop up the Font dialog and hit the "italic" button. Now the default FontStyle object contains "Arial, 10pt, italic". The first FontStyle object which had been extending as I typed, is now closed, and a new one created and opened. Just as before, the new one is a copy of the current default FontStyle, but it's different from the first one.
This is an example of using the prototype pattern (copying the default FontStyle object each time the font changes) rather than other approaches which might involve tracking the Font selections in other objects, and calling a complex multi-argument constructor or a sequence of "setters" each time a new FontStyle object is needed.
Did that make any sense ?

[Jayadev Pulaparty]

The following is what i understood by reading the GoF book on design patterns.
He tries to compare the AbstractFactory pattern with Prototype (in the context of AbstractFactory pattern) and explains how the Prototype avoids the need of creating a separate ConcreteFactory class for every new family of objects to be created. This also avoids the need for the parallel hierarchy of factory classes.
The ConcreteFactory creation will be supplied with instances of the prototypes (which can be cloned) and the clones are our new objects created from their respective prototypes. Suppose we want to create Widgets for a GUI like ScrollBars, Buttons....
class ConcreteFactory{
ConcreteFactory(ScrollBar sBar, Button bton)
{
prototypeScrollBar = sBar;
prototypeButton = bton;
}
ScrollBar createScrollBar()
{
return (ScrollBar)prototypeScrollBar.Clone();}
Button createButton()
{
return (Button)prototypeButton.Clone();
}
}
The client can decide which kind of look and feel of the graphics he wants to have like MotifScrollBar and MotifButton (related family of products) or PresentationManager look and feel, at runtime as shown below
ScrollBar and Button are abstract classes and MotifScrollBar and MotifButton are the corresponding concrete classes.
{
ScrollBar clientScrollBar;
Button clientButton;
// the wanted look and feel can be obtained at
// runtime in the client this way
ConcreteFactory cFactory = new ConcreteFactory(new MotifScrollBar(), new MotifButton());
clientScrollBar = cFactory.createScrollBar();
clientButton = cFactory.createButton();
......
......
}
This way it is also easy to add another look and feel in the future, say a differently looking ScrollBar and Button as long as they simply support the ScrollBar and Button interfaces. Also this is avoiding the need to create a new class of related family of products for the new look and feel. The client can simply load the library having the new ScrollBar and Button classes and he is all set to go.