Crash Course on Go Interfaces

This post was originally written for my mailing list. Want to get some awesome Go tutorials like this delivered to your inbox every week or two? You can sign up for my mailing list at the bottom of this page 👇

In this article we are going to do a crash course on Go’s interfaces, then in the rest of this series we will continue exploring how interfaces work, how to use them effectively, and more.

Let’s start by talking a bit about how Go differs from dynamic languages like JavaScript, Ruby, and Python. When creating functions in dynamic languages, you don’t define the type you expect to receive. Instead, anything can be passed in. Below is an example of this using JavaScript.

function Greeting(name) {
  return "Hello, " + name
}

// The following is all valid in JS, even if it doesn't make much sense.
Greeting("Jon")
// Output: "Hello, Jon"

Greeting(123)
// Output: "Hello, 123"

Greeting(document)
// Output: "Hello, [object HTMLDocument]"

In Go you have to explicitly state types, which means when you are creating a function you have to state that you want the name argument to be a string.

func Greeting(name string) string {
  return fmt.Sprintf("Hello, %v!", name)
}

For the most part this is a good thing. It makes it clear to anyone reading your code exactly what you expect, and it prevents other developers from accidentally passing in the wrong thing.

If you have ever used a dynamic language, chances are you have experienced errors because someone passed the wrong thing into a function - like passing in the entire document in the JS example! This type of error is far less likely to occur in Go because of the static type system.

Unfortunately, static typing also limits our code quite a bit. For instance, imagine you had some code that wrote our greeting to a file.

func WriteGreeting(name string, f *os.File) error {
  greeting := Greeting(name)
  _, err := f.Write([]byte(greeting))
  if err != nil {
    return err
  }
  return nil
}

This code works perfectly, but it is limited to writing to files. What if we wanted to instead write the greeting to a strings.Builder?

Without interfaces, we would be forced to rewrite the function to accept a strings.Builder!

func WriteGreeting(name string, sb *strings.Builder) error {
  greeting := Greeting(name)
  _, err := sb.Write([]byte(greeting))
  if err != nil {
    return err
  }
  return nil
}

Sidenote: Yes, I know strings.Builder has a WriteString method. It will make a bit more sense why I am opting to instead use Write in a bit.

Looking at the code for both of these functions, you will notice that they are very similar. Ignoring the variable name change, the only real difference is that in the first code sample we are using File.Write and in the second we are using Builder.Write, but in both of these cases the method we are using has the following definition:

Write(p []byte) (int, error)

It turns out, we don’t really care if we are dealing with a strings.Builder or an os.File. All we really care is that we are given something with the Write method. With that our code would continue to work.

Luckily, Go has something called interfaces that enable us to express exactly this. Below is an example of an interface that would work for this particular case.

type Writer interface {
  Write([]byte) (int, error)
}

With the interface defined, we could rewrite our WriteGreeting function like so:

type Writer interface {
  Write([]byte) (int, error)
}

func WriteGreeting(name string, w Writer) error {
  greeting := Greeting(name)
  _, err := w.Write([]byte(greeting))
  if err != nil {
    return err
  }
  return nil
}

Now any type with the Write method can be passed into WriteGreeting! In fact, this interface is so common that it is defined in the standard library 👉 io.Writer

One of the neatest parts about Go is that it uses duck typing. To quote Mat (and whoever originally coined the term), “If it looks like a duck, and it quacks like a duck, then it is a duck”.

(okay, technically it isn’t duck typing, but “structural typing” doesn’t have a catchy “quacks like a duck” quote! 😂)

Or in the context of Go, if it looks like a Writer interface, has the methods defined by the Writer interface, then it is a Writer interface implementation.

I mention duck typing because it isn’t true in all statically typed languages. For instance, in Java you need to explicitly state that a class implements an interface, otherwise the compiler won’t let you use it as an interface implementation. This has a big impact on how interfaces are used in Go compared to languages like Java, and we will discuss that a bit more in a future email.

Getting into more concrete details, any type that has every method defined by an interface will implement that interface. If a type has more methods than the interface defines that is okay too, but those additional methods will NOT be accessible while inside a function that accepts the interface.

func main() {
  var sb strings.Builder
  WriteGreeting("Jon", &sb)
}

func WriteGreeting(name string, w Writer) error {
  greeting := Greeting(name)
  // We can access Write here because it is defined by the Writer interface,
  // but we CANNOT access the Builder.WriteString method here even if we passed
  // in a strings.Builder because WriteString is not defined as part of the
  // Writer interface.
  _, err := w.Write([]byte(greeting))
  if err != nil {
    return err
  }
  return nil
}

type Writer interface {
  Write([]byte) (int, error)
}

Every method defined by the interface must be implemented for a type to implement an interface. The following example will result in a compiler error because our Demo type doesn’t define all of the methods defined by BigInterface:

type BigInterface interface {
  A()
  B()
  C()
}

type Demo struct {}

func (Demo) A() {}
func (Demo) B() {}

func Test(bi BigInterface) {}

func main() {
  var demo Demo
  Test(demo) // errors because Demo doesn't implement the C() method.
}

Because of this, it is common to limit interfaces to specifically the methods you need rather than a large set of methods, as this makes it easier for other types to implement the interface.

Hopefully this helped shine some light on what interfaces are and why we might want to use them. In the next few articles I will dive into interfaces a bit more exploring topics like:

That is a lot though, so it will be broken into a few posts and will be gradually released. Until then, give what you learned here a try in your code. Explore a bit and see what you discover 😁

Learn Web Development with Go!

Sign up for my mailing list and I'll send you a FREE sample from my course - Web Development with Go. The sample includes the first few chapters from the book, and over 2.5 hours of screencasts.

You will also receive emails from me about upcoming courses (including FREE ones), new blog posts, and course discounts.

Avatar of Jon Calhoun
Written by
Jon Calhoun

Jon Calhoun is a full stack web developer who also teaches about Go, web development, algorithms, and anything programming related. He also consults for other companies who have development needs. (If you need some development work done, get in touch!)

Jon is a co-founder of EasyPost, a shipping API that many fortune 500 companies use to power their shipping infrastructure, and prior to founding EasyPost he worked at google as a software engineer.

Jon's latest progress update: Writing Course Notes

More in this series

This post is part of the series, Interfaces in Go.

Spread the word

Did you find this page helpful? Let others know about it!

Sharing helps me continue to create both free and premium Go resources.

Want to discuss the article?

See something that is wrong, think this article could be improved, or just want to say thanks? I'd love to hear what you have to say!

You can reach me via email or via twitter.

Recent Articles All Articles Mini-Series Progress Updates Tags About Me Go Courses

©2018 Jonathan Calhoun. All rights reserved.