1

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:

  • Specifying new object by varying values
  • Reduced subclassing

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?

Niek Beijloos
  • 39
  • 7

1 Answers1

0

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.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
  • Hi Jaco, first of all I want to thank you for always answering my design patterns related questions. Secondly, about this post, what I conduct from the first part of your answer is that the Prototype design pattern should be applied when we want to reduce classes AND comply to the Dependency Inversion Principle. In case 'the reduction of classes' is only true, then the pattern might not be the most suitable. Is this correct? – Niek Beijloos May 07 '23 at 11:35
  • Regarding the second part of your answer, I'm not referring to the function name 'Clone' and 'Create', I'm more referring to the functionality behind it, in the 'Clone' case we copy the instance in the 'Create' case we create the product from scratch. To elaborate more on my point, in case we move the 'Create' function from the Creator hierarchy (in the Factory Method design pattern) to the Product itself, the reduction in subclasses is also realized (no copy behavior needed). To me the reduction in subclasses does not seem a specific consequence for the Prototype pattern. What do you think? – Niek Beijloos May 07 '23 at 11:41
  • 1
    1.) Building a framework in the way the GoF describe requires the DIP: it's necessary for their stated use case. The GoF does tend to focus on [library](https://stackoverflow.com/questions/1270729) code; I think it's fair to say a number of their patterns don't apply equally to applications; and I believe Java developers are unlikely to need any of the [creational patterns](https://stackoverflow.com/questions/69004073) at all. 2.) Prototype also uses object state to replace classes, so without copying state, classes cannot be reduced to the extent described in, "highly dynamic systems". – jaco0646 May 07 '23 at 16:17
  • Jaco, I still don't fully understand point 2. In case we **create**, from 'scratch', an object and re-shape it according to the client's need, we could accomplish the same class reduction. The argument: 'use object state to replace classes', can be counter 'argumented' by initializing an object with default values, from 'scratch', without introduction of **clone** functionality whatsoever. Could you shed some more light on this? – Niek Beijloos May 08 '23 at 19:10
  • 1
    Initializing objects from one set of default values would be the opposite of "highly dynamic." Initializing objects from an unlimited set of starting points would be dynamic, and could potentially eliminate a set of classes representing those starting points. – jaco0646 May 09 '23 at 00:25