Go Language

Learn Go: Object-Oriented Programming in Golang #33

In this tutorial you'll learn about all the intricacies of object-oriented design in Go

Lets go!!

Published · Feb 19 2020

Previous Tutorial: Introduction to Mutex in Golang #32

  

Go is a strange mix of old and new ideas. It has a very refreshing approach where it isn't afraid to throw away established notions of "how to do things". Many people are not even sure if Go is an object-oriented language. Let me put that to rest right now. It is! 

In this tutorial you'll learn about all the intricacies of object-oriented design in Go, how the pillars of object-oriented programming like encapsulation, inheritance, and polymorphism are expressed in Go, and how Go compares to other languages.

Go is an incredibly powerful programming language, learn everything from writing simple utilities to building scalable, flexible web servers in our full course.
. . .
Is Go Object Oriented?
Go is not a pure object oriented programming language. This excerpt taken from Go's FAQs answers the question of whether Go is Object Oriented.
Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).  

In the upcoming tutorials we will discuss how object oriented programming concepts can be implemented using Go. Some of them are quite different in implementation compared to other object oriented languages such as Java.
. . .
Go Object-Oriented Language Features
Go has no classes, but it has types. In particular, it has structs. Structs are user-defined types. Struct types (with methods) serve similar purposes to classes in other languages.

Structs
A struct defines state. Here is a Creature struct. It has a Name field and a boolean flag called Real, which tells us if it's a real creature or an imaginary creature. Structs hold only state and no behavior.
type Creature struct {
   Name string
   Real bool
}

Methods
Methods are functions that operate on particular types. They have a receiver clause that mandates what type they operate on. Here is a Dump() method that operates on Creature structs and prints their state:
func (c Creature) Dump() {
   fmt.Printf("Name: '%s', Real: %t\n", c.Name, c.Real)
}

This is an unusual syntax, but it is very explicit and clear (unlike the implicit "this" or Python's confusing "self").
Embedding
You can embed anonymous types inside each other. If you embed a nameless struct then the embedded struct provides its state (and methods) to the embedding struct directly. For example, the FlyingCreature has a nameless Creature struct embedded in it, which means a FlyingCreature is a Creature.
type FlyingCreature struct {
   Creature
   WingSpan int
}

Now, if you have an instance of a FlyingCreature, you can access its Name and Real attributes directly.
dragon := &FlyingCreature{
   Creature{"Dragon", false, },
   15,
}
 
fmt.Println(dragon.Name)
fmt.Println(dragon.Real)
fmt.Println(dragon.WingSpan)

Interfaces
Interfaces are the hallmark of Go's object-oriented support. Interfaces are types that declare sets of methods. Similarly to interfaces in other languages, they have no implementation. 

Objects that implement all the interface methods automatically implement the interface. There is no inheritance or subclassing or "implements" keyword. In the following code snippet, type Foo implements the Fooer interface (by convention, Go interface names end with "er").
type Fooer interface {
   Foo1()
   Foo2()
   Foo3()
}
 
type Foo struct {}
 
func (f Foo) Foo1() {
   fmt.Println("Foo1() here")
}
 
func (f Foo) Foo2() {
   fmt.Println("Foo2() here")
}
 
func (f Foo) Foo3() {
   fmt.Println("Foo3() here")
}
. . .
Object-Oriented Design: The Go Way
Let's see how Go measures up against the pillars of object-oriented programming: encapsulation, inheritance, and polymorphism. Those are features of class-based programming languages, which are the most popular object-oriented programming languages.

At the core, objects are language constructs that have state and behavior that operates on the state and selectively exposes it to other parts of the program. 

Encapsulation
Go encapsulates things at the package level. Names that start with a lowercase letter are only visible within that package. You can hide anything in a private package and just expose specific types, interfaces, and factory functions. 

For example, here to hide the Foo type above and expose just the interface you could rename it to lower case foo and provide a NewFoo() function that returns the public Fooer interface:
type foo struct {}
 
func (f foo) Foo1() {
   fmt.Println("Foo1() here")
}
 
func (f foo) Foo2() {
   fmt.Println("Foo2() here")
}
 
func (f foo) Foo3() {
   fmt.Println("Foo3() here")
}
 
func NewFoo() Fooer {
   return &foo{}
}

Then code from another package can use NewFoo() and get access to a Fooer interface implemented by the internal foo type:
package main

import (
	"fmt"
)

type foo struct{}

type Fooer interface {
	Foo1()
	Foo2()
	Foo3()
}

func (f foo) Foo1() {
	fmt.Println("Foo1() here")
}

func (f foo) Foo2() {
	fmt.Println("Foo2() here")
}

func (f foo) Foo3() {
	fmt.Println("Foo3() here")
}

func NewFoo() Fooer {
	return &foo{}
}

func main() {
	f := NewFoo()

	f.Foo1()
	f.Foo2()
	f.Foo3()
}

https://play.golang.org/p/P8AFnsDghyj

Inheritance
Inheritance or subclassing was always a controversial issue. There are many problems with implementation inheritance (as opposed to interface inheritance). Multiple inheritance as implemented by C++ and Python and other languages suffers from the deadly diamond of death problem, but even single inheritance is no picnic with the fragile base-class problem. 

Here SuperFoo embeds the Fooer interface, but doesn't implement its methods. The Go compiler will happily let you create a new SuperFoo and call the Fooer methods, but will obviously fail at runtime. This compiles:
package main

type Fooer interface {
	Foo1()
	Foo2()
	Foo3()
}

type SuperFooer struct {
	Fooer
}

func main() {
	s := SuperFooer{}
	s.Foo2()
}

https://play.golang.org/p/Agn_9jb_XMx

Running this program results in a panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x28 pc=0x2a78]
 
goroutine 1 [running]:
panic(0xde180, 0xc82000a0d0)
 /usr/local/Cellar/go/1.6/libexec/src/runtime/panic.go:464 +0x3e6
main.main()
 /Users/gigi/Documents/dev/go/src/github.com/oop_test/main.go:104 +0x48
exit status 2
 
Process finished with exit code 1

Polymorphism
Polymorphism is the essence of object-oriented programming: the ability to treat objects of different types uniformly as long as they adhere to the same interface. Go interfaces provide this capability in a very direct and intuitive way. 

Here is an elaborate example where multiple creatures (and a door!) that implement the Dumper interface are created and stored in a slice and then the Dump() method is called for each one. You'll notice different styles of instantiating the objects too.
package main

import "fmt"

type Creature struct {
	Name string
	Real bool
}

func Dump(c *Creature) {
	fmt.Printf("Name: '%s', Real: %t\n", c.Name, c.Real)
}

func (c Creature) Dump() {
	fmt.Printf("Name: '%s', Real: %t\n", c.Name, c.Real)
}

type FlyingCreature struct {
	Creature
	WingSpan int
}

func (fc FlyingCreature) Dump() {
	fmt.Printf("Name: '%s', Real: %t, WingSpan: %d\n",
		fc.Name,
		fc.Real,
		fc.WingSpan)
}

type Unicorn struct {
	Creature
}

type Dragon struct {
	FlyingCreature
}

type Pterodactyl struct {
	FlyingCreature
}

func NewPterodactyl(wingSpan int) *Pterodactyl {
	pet := &Pterodactyl{
		FlyingCreature{
			Creature{
				"Pterodactyl",
				true,
			},
			wingSpan,
		},
	}
	return pet
}

type Dumper interface {
	Dump()
}

type Door struct {
	Thickness int
	Color     string
}

func (d Door) Dump() {
	fmt.Printf("Door => Thickness: %d, Color: %s", d.Thickness, d.Color)
}

func main() {
	creature := &Creature{
		"some creature",
		false,
	}

	uni := Unicorn{
		Creature{
			"Unicorn",
			false,
		},
	}

	pet1 := &Pterodactyl{
		FlyingCreature{
			Creature{
				"Pterodactyl",
				true,
			},
			5,
		},
	}

	pet2 := NewPterodactyl(8)

	door := &Door{3, "red"}

	Dump(creature)
	creature.Dump()
	uni.Dump()
	pet1.Dump()
	pet2.Dump()

	creatures := []Creature{
		*creature,
		uni.Creature,
		pet1.Creature,
		pet2.Creature}
	fmt.Println("Dump() through Creature embedded type")
	for _, creature := range creatures {
		creature.Dump()
	}

	dumpers := []Dumper{creature, uni, pet1, pet2, door}
	fmt.Println("Dump() through Dumper interface")
	for _, dumper := range dumpers {
		dumper.Dump()
	}
}

https://play.golang.org/p/LM6wxg8Wf5l
. . .
Conclusion
Go is a bona fide object-oriented programming language. It enables object-based modeling and promotes the best practice of using interfaces instead of concrete type hierarchies. 

Go made some unusual syntactic choices, but overall working with types, methods, and interfaces feels simple, lightweight, and natural. 

Embedding is not very pure, but apparently pragmatism was at work, and embedding was provided instead of only composition by name.
. . .
Next Tutorial:  Handling Errors in Golang #34

Golang Tutorial Series:  Learn Go: Beginners Guide to Learn Golang from Scratch!
. . .

References: 
[ 1 ] Object-Oriented Programming in Golang