Design Patterns — ProtoType

Yonatan Karp-Rudin
Stackademic
Published in
4 min readNov 20, 2023

--

Photo by Hal Gatewood on Unsplash

TL;DR: The Prototype design pattern creates new objects by cloning a prototypical instance, allowing you to modify the copy without creating an object from scratch. This pattern is useful when object creation is expensive or when classes to instantiate are specified at runtime.

Intent

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Explanation

First, it should be noted that the Prototype pattern is not used to gain performance benefits. It’s only used for creating new objects from prototype instances.

Real-world example

Remember Dolly? The sheep that was cloned! Let’s not get into the details but the key point here is that it is all about cloning.

In plain words

Create an object based on an existing object through cloning.

Wikipedia says

The prototype pattern is a creational design pattern in software development. It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

In short, it allows you to create a copy of an existing object and modify it to your needs, instead of going through the trouble of creating an object from scratch and setting it up.

Programmatic Example

In Kotlin, the prototype pattern is recommended to be implemented as follows. First, create an interface with a method for cloning objects. In this example, Prototype interface accomplishes this with its clone method. We will then use the copy() function of data class to create a clone of our class where we can override specific fields of the class if needed.

abstract class Prototype<T> {
abstract fun clone(): T
}

Our example contains a hierarchy of different creatures. For example, let’s look at Beast and OrcBeast classes.

abstract class Beast : Prototype<Beast>()

data class OrcBeast(private val weapon: String) : Beast() {

override fun clone() = copy()

override fun toString() = "Orcish wolf attacks with $weapon"
}

We don’t want to go into too many details, but the full example contains also base classes Mage and Warlord and there are specialized implementations for those for elves in addition to orcs.

To take full advantage of the prototype pattern, we create HeroFactory class to produce different kinds of creatures from prototypes.

class HeroFactory(
private val mage: Mage,
private val warlord: Warlord,
private val beast: Beast,
) {
fun createMage() = mage.clone()

fun createWarlord() = warlord.clone()

fun createBeast() = beast.clone()
}

Now, we are able to show the full prototype pattern in action producing new creatures by cloning existing instances.

var factory = HeroFactory(
ElfMage("cooking"),
ElfWarlord("cleaning"),
ElfBeast("protecting")
)

var mage = factory.createMage()
var warlord = factory.createWarlord()
var beast = factory.createBeast()

logger.info(mage.toString())
logger.info(warlord.toString())
logger.info(beast.toString())

factory = HeroFactory(
OrcMage("axe"),
OrcWarlord("sword"),
OrcBeast("laser")
)

mage = factory.createMage()
warlord = factory.createWarlord()
beast = factory.createBeast()

logger.info(mage.toString())
logger.info(warlord.toString())
logger.info(beast.toString())

Here’s the console output from running the example.

Elven mage helps in cooking
Elven warlord helps in cleaning
Elven eagle helps in protecting
Orcish mage attacks with axe
Orcish warlord attacks with sword
Orcish wolf attacks with laser

Class diagram

Applicability

Use the Prototype pattern when a system should be independent of how its products are created, composed, represented and

  • When the classes to instantiate are specified at run-time, for example, by dynamic loading.
  • To avoid building a class hierarchy of factories that parallels the class hierarchy of products.
  • When instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.
  • When object creation is expensive compared to cloning.

Stay updated with my latest thoughts and ideas by registering for my newsletter. Connect with me on LinkedIn or Twitter. Let’s stay connected and keep the conversation going!

Originally published at https://yonatankarp.com.

Stackademic

Thank you for reading until the end. Before you go:

  • Please consider clapping and following the writer! 👏
  • Follow us on Twitter(X), LinkedIn, and YouTube.
  • Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

--

--

A senior backend engineer focusing on Kotlin for backend. Visit my blog at http://yonatankarp.com or check out my lists for specific series of articles