I read the Design Patterns book (written by the Gang of Four) and I'm now recapping on the Prototype Design pattern. In the consequence section, of the Prototype design pattern, (explained on page 119 and 120) the following consequences are listed:
The first consequence, specifying new object by varying values, seems to me not really a consequence of the Prototype design pattern. The consequence is elaborated, I quote:
Highly dynamic systems let you define new behavior through object composition - by specifying values for an object's variables, for example - and not by defining new classes. This kind of design lets users define new "classes" without programming. In fact, cloning a prototype is similar to instantiating a class. The Prototype pattern can greatly reduce the number of classes a system needs.
This means we can apply the Prototype design pattern to reduce classes by 'cloning' and 'shaping' an existing class/object. However, this doesn't seem to be a really 'distinctive' consequence of the Prototype design pattern. The Prototype pattern states nothing about the 'shaping' of the cloned object. On top of that, we can reduce classes without cloning, by just 'new-ing' and 'shaping'.
The second consequence, reduced subclassing, seems also not really a consequence of the Prototype design pattern. The consequence is elaborated, I quote:
Factory Method often produces a hierarchy of Creator classes that parallels the product class hierarchy. The Prototype pattern lets you clone a prototype instead of asking a factory method to make a new object. Hence you don't need a Creator class hierarchy at all.
The Prototype pattern might indeed reduce subclassing when applied instead of the Factory Method pattern. However, this seems again not really a 'distinctive' consequence of the Prototype design pattern. An alternative to a Clone function, within the Product, could be a Create function. The Create function instantiates the object from 'scratch' (instead of copying). This would also make the Creator hierarchy redundant and provide the identical consequence.
My question: Why is class and subclass reduction a particular consequence of the Prototype design pattern?
we can reduce classes without cloning, by just 'new-ing' and 'shaping'.
The problem with new is that it violates the Dependency Inversion Principle, which is particularly problematic for frameworks (the use case in the GoF). A framework author doesn't know what to new because those client-specific products don't exist when the framework is written. (Note: this is the exact same argument for the Factory Method Pattern.)
An alternative to a Clone function, within the Product, could be a Create function.
It doesn't matter to a Design Pattern what you name the functions. This is an important point, because a lot of confusion on SO comes from people believing the essence of one pattern or another is in the names of its functions. That is never the case. The names you choose can certainly help to communicate your intent; but a pattern's implementation is not determined by function names.
If you're familiar with Java's popular Lombok plugin, it includes a nice Prototype variant called @With that goes a step beyond cloning... without a "clone" method.
Why is class and subclass reduction a particular consequence of the Prototype design pattern?
This reduction is specifically in contrast to other creational patterns such as factories and builders, which always require classes and/or subclasses in addition to the product classes.