Learn About The Essence Of Go Interfaces & Quacking

When we think of interfaces, as traditional object-oriented programmers, the words ‘abstract’ or ‘implements’ come to mind and the example of  the Shape Interface with the Rectangle and Triangle classes materialises before us; or the Animal interface with a Dog and Cat class mulling around. Go thinks differently and hence I take a different (and probably debatable) approach to explain the essence of Interfaces in Go.

The Traditional Approach

Lets design an office with tables and chairs. “But first…” we say, we need to have some abstraction hierarchy around this which will make our design extensible and flexible. Lets say we design the class hierarchy (and I am using Ruby because it’s the easiest for me currently)

class Furniture

class Chair extends Furniture

class Table extends Furniture

“Hmm.. not good” we say again, it’s not extensible, we should use modules instead because  the Chair and Furniture could also be sold — yes, lets create the modules Salable and Furniture!

module Furniture

module Salable

class Chair
include Furniture

class Table
include Furniture
include Salable

We look back, relax, take a break and say – “Dude – we rock – we have designed an office. Who sells Chairs anyway? ;)”

The Go approach

Let’s design and office with tables and chairs. “Sir, yes Sir!” we say and put on our programmer hat and get down to it!

type Chair struct {
Weight float32
Height float32
Color string
Material string

func (c Chair) Rotate(degree int) bool {
// write some code to rotate the chair
// return true if chair has rotated.

func (c Chair) Move(distance int) int {
// write some code.
// return the distance it moved

Just like we have a Chair, we can design the Table and its functionality and I am not getting into those details but the ideology behind this.

  • We got down to designing the “object” in mind i.e. chairs and tables.
  • We did not have to think about any abstraction.
  • We are living in the present and not thinking about future use-cases.

Now, suppose, we need to treat chairs and tables as furniture and have put on our Analyst / Architect / Manager hat. We can now implement the Furniture interface

type Furniture interface {
Move(distance int) int

Hey! Chair is Furniture already because it can move. We did not have to “declare” or “implement” it. Suppose we also want to sell furniture.

type Furniture interface {
Move(distance int) int
Sell(price int) int

func (c Chair) Sell(price int) int {
// Beche do! Sell it!

Hey, Chair is Furniture still – no questions asked. But wait, there’s more -we haven’t quacked yet 😉

“If it quacks, it’s a duck”.

Well, in a galaxy far away, some astronomer defines an interface for the Earth and it’s rotation.

type Rotater interface {
Rotate(degree int) bool

type Earth struct {
Equator int
Continents int

func (e Earth) Rotate(degree int) bool {
// the earths rotation!

Lo and behold, our Chair is also a Rotater along with the Earth because we have implemented the Rotate method for the chair earlier!

If it rotates, it’s a Rotater

I found this pretty intriguing and particularly simple concept as a programmer. We infer the interfaces from the methods and implementation and not from the abstraction and declaration. While traditionally we would have been stuck on debating Salable and Furniture interface, in Go we concentrated on our core object and quickly and easily implemented  Chair and extended its functionality. This makes the ideology behind Go interfaces quacking … I mean rocking!

One thought on “Learn About The Essence Of Go Interfaces & Quacking

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.