How does the prototype pattern get rids of subclasses?

[kanmaytacker]

Asked by @faiz.

What?

One of the motivations of prototype pattern was to get rid of usage of subclasses.

Have we gotten rid of subclasses at any place in prototype pattern?

One place is clear where we are still using it -i.e., while creating prototype object.

But from where we got rid of where it was used earlier.?

Without prototype also we were creating object like this only. So with respect to getting rid of usage of subclasses using prototype pattern, I am not seeing any.

Why?

Tightly coupling of any piece of code Ek to implementation classes Do adds a maintenance overhead.
When Do changes, class Ek is open for modification.

Tight coupling of client code and implementation (concrete) classes causes further maintenance nightmares.
A dependency on a frequently changing class could potentially cause errors (read: Backward Incompatible).

Also, if you are using an external library, you might not even know the concrete class.

How?

If you don't know prototype

Parent instance = new Child();

If you know prototype:

Parent prototype = getPrototypeFromUtils();
Parent clone = prototype.clone();

Common utility can be client code or ours.
If client, at least Child is not riddled through out their code base.

If you really know prototype:

Parent prototype = externalPrototypeRegistry.get();
Parent clone = prototype.clone();