英文:

Why is class and subclass reduction a particular consequence of the Prototype design pattern?

问题

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?

英文:

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?

答案1

得分: 0

Sure, here are the translated parts:

we can reduce classes without cloning, by just 'new-ing' and 'shaping'.
"我们可以通过仅仅 'new' 和 '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.)
"new 的问题在于它违反了依赖反转原则，这对于框架来说特别棘手（GoF中的使用案例）。框架的作者不知道该使用 new 来创建什么，因为在编写框架时，客户端特定的产品尚不存在。（注：这与工厂方法模式的论点完全相同。）"

An alternative to a Clone function, within the Product, could be a Create function.
在产品内部，一个替代 Clone 函数的选择可以是 Create 函数。

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.
对于设计模式来说，函数的命名并不重要。这是一个重要的观点，因为Stack Overflow上有很多混淆，人们认为一个模式的本质或另一个模式的本质在于函数的命名。事实并非如此。您选择的名称确实可以帮助传达您的意图，但模式的实现并不取决于函数名称。

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.
如果您熟悉Java中流行的Lombok插件，它包括一个很好的原型变体@With，它进一步超越了克隆...而不需要一个 "clone" 方法。

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.
这种减少是特别与其他创建模式对比的，如工厂和建造者模式，它们总是需要类和/或子类，而不仅仅是产品类。

英文:

> 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.