The prototype pattern in Go

This is a continuation of the common design patterns I found in my old code series, which I started in a previous post.

While going through some of the code I found a couple of instances where I was making copies of some structs, but I wasn’t using the built in copy() method. I was, instead, using some custom copy logic.

The reason for that was that the struct had some properties that were slices of other structs and if I were to use copy(), it would get me in trouble as there was a possibility that the source struct could be mutated.

And this is actually what the prototype design pattern is about. It’s a design pattern that simply involves making copies of objects instead of creating new instances.

This sort of pattern can be useful when:

• creating instances of an object is time consuming or resource intensive (slow database queries, etc)
• making copies of an object is complex (deep copies, private members, etc - the same scenario as I described above)
• the object is exposed as an interface

To get an idea of what it looks like in practice, consider the following example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

obj := NewObj(1)
copy := obj.Clone()

func NewObj(prop int) MyObj {
    return &myObj{PubProp: prop}
}

type MyObj interface {
    Clone() MyObj
}

type myObj struct {
    PubProp int
    privProp int
}

func (o *myObj) Clone() *MyObj {
    return &myObj{
        PubProp: o.Prop,
        privProp: o.privProp,
    }
}

The above example has 2 main reasons for applying the prototype design pattern:

1. Our object is an interface
2. There’s a private property

That’s more or less all there is to this pattern.

For more design pattern examples, please checkout rolandjitsu/go-design-patterns.