I’ve recently started learning the programming language Go in order to support my current client. It reminds me a bit of my days writing C code, though it has some interesting features such as goroutines, a lightweight, easy-to-use tasking model. It’s not a full object-oriented language, but it has interfaces which allows it to support polymorphism. What it doesn’t have are classes; thus, there are no subclasses which means there is no inheritance.
If you do a web search for inheritance in Go, you’ll see some pages, articles and posts telling you that while Go doesn’t support inheritance, you can effectively achieve the same thing through composition. I’m not going spend this post weighing in on the claim that one should always favor composition over inheritance, though one should view such a position with skepticism. Inheritance is quite useful and powerful when used properly. What I’m going to talk about here is how we might try to achieve inheritance through composition. The short answer is you can’t, but you can create something that exhibits a similar semantics to inheritance when viewed from the outside. The key to doing this is something called delegation.
In inheritance, the behavior encapsulated by objects is derived through compile-time semantics. In delegation, they are derived at run-time. Each object has a prototype, and when it receives a message calling upon it to execute a behavior or access the value of a property, it will do so if the behavior or property is defined locally. Otherwise, it will delegate the message to its prototype. The prototype may also delegate the message to its prototype, and this can continue recursively until a prototype is found that can respond to the message.
Let’s take a look at an example of delegation that involves an abstract shape and multiple concrete shapes. There is a Shape interface that defines three methods for a Shape: Location, which returns the location associated with a Shape which could be the center or a vertex; Move, which translates a Shape by a given x and y offset; and Resize, which multiplies the area of a Shape by a given ratio. The AbstractShape type stores a Shape’s location and implements the Move method, which is common to all Shapes. It does not implement the Resize method since area calculations depend on the particular Shape under consideration. AbstractShape would be an abstract class in a language such as Java or C#. In Go, an AbstractShape is not assignable to a Shape because it doesn’t fully implement the Shape interface. You can create an instance of an AbstractShape, and we’ll do that when building our delegation model, but that instance won’t fulfill the Shape contract and therefore will not stand on its own as a concrete Shape, which makes it roughly analogous to an abstract class.
Two concrete Shape types are included in this example: Rectangle and Circle. In both of the type definitions, a reference is made to an AbstractShape prototype. Here’s the type definition for a Circle:
type Circle struct {
*AbstractShape
radius float64
}
The AbstractShape prototype is unnamed, and Go handles the delegation of methods to this unnamed prototype automatically. In the shapes demo application, we see an example of how delegation can provide the appearance of inheritance. The Shapes are instantiated as follows:
var shapes = make([]Shape, 4)
shapes[0] = NewCircle(NewPoint(3, 4), 5)
shapes[1] = NewRectangle(NewPoint(7, 2), 3, 6)
shapes[2] = NewCircle(NewPoint(10, 8), 6)
shapes[3] = NewRectangle(NewPoint(15, 12), 5, 5)
The first line of code above creates an array of four Shapes. The next four lines of code create the concrete Shape instances. Circles are constructed with a center point and a radius. Rectangles are constructed with the upper left vertex point, a width and a height. In Go, if a type implements all of the methods defined in an interface, it is assumed to implement the interface without you having to explicitly indicate that. Thus, instances of Circle and Rectangle are assignable to Shape.
The Resize method can be called on a Shape and it will be dynamically dispatched to a subtype:
for _, shape := range shapes {
shape.Resize(2)
}This shows that Go supports polymorphism when multiple types implement the same interface. Delegation is not required for this to work.
Delegation shows up when we call a method implemented by AbstractShape that is not implemented by a Shape subtype. We can move the Shapes as follows:
shapes[0].Move(3, 2)
shapes[1].Move(-1.5, 3.5)
shapes[2].Move(-3, 2.5)
shapes[3].Move(-3, -2.5)
Calling Move on a concrete shape results in the method call being delegated to the AbstractShape prototype. (Remember that Go handles the method delegation automatically.) This provides the illusion that the method has been inherited by Circle and Rectangle from AbstractShape, even though the language does not support inheritance.
So now we can see how delegation exhibits a semantics that, when viewed from the outside, looks like inheritance. To this point, we have only examined the case in which each object has its own personal prototype. That’s probably the most common pattern when delegation is used, but it’s not the only option. Another delegation pattern we can use is having multiple objects share the same prototype.
Understanding why we may want to use this pattern requires us to take a step back to look at how inheritance and delegation differ when it comes to representing the acquisition of knowledge. An inheritance hierarchy is the result of deductive reasoning. For example, if a Dog is defined as a Mammal having a snout, a tail and four legs, and an object named Rover is an instance of Dog, I can deduce that Rover also has a snout, a tail and four legs. There is power in this, as it provides us the ability to reason about the semantics of a program before it runs. The shared prototypes delegation pattern gives us another way to model the acquisition of knowledge. It allows us to dynamically build and modify a taxonomy from the bottom up, at run-time as new facts become available, through inductive reasoning. We will examine this in detail in the next article in this series.
The code supporting the example shown in this post is hosted on GitHub.