Forem: Lucas Caparelli

Meus métodos devem retornar interfaces ou structs em Go?

Lucas Caparelli — Sun, 12 Jul 2020 15:50:20 +0000

Como a maioria das coisas no design de software, depende. E não posso enfatizar isso o suficiente: realmente depende da situação e de que resultado você está tentando alcançar.

Já posso até ouvir alguns de vocês gritando uma regra muito útil (ou até mesmo provérbio, se preferir) "Accept interfaces, return structs" ("Aceite interfaces, retorne structs"). É um conselho muito bom, realmente, mas sempre há exceções. Nenhum padrão é tão flexível que se adapta a todas as situações.

Com isso dito, eu apostaria que essa regra faz sentido a maioria das vezes, então vamos dar uma olhada no raciocínio que nos leva a retornar structs.

Mas primeiro, algumas noções básicas sobre como as interfaces funcionam no Go. Se você já as conhece bem, sinta-se livre para pular para a próxima seção.

Interfaces no Go

É importante ter em mente que as interfaces em Go não estão estritamente vinculadas a tipos. O que quero dizer com isso é que você nunca diz explicitamente que um tipo implementa uma interface específica. Tudo o que você precisa fazer para implementar uma interface no Go é implementar os métodos que satisfazem essa interface.

Pense em uma interface como um conjunto de comportamentos que são esperados de um tipo. Você normalmente não vê patos com um rótulo escrito "Pato", mas sabe que é um porque parece um pato, grasna como um pato, tem penas como um pato, etc. Você deduz o que é a partir de seu comportamento, e é exatamente isso que o Go faz em tempo de compilação.

Caso esteja se perguntando, o Go usa "structural typing", não "Duck Typing", o que significa que tudo isso acontece em tempo de compilação, não em tempo de execução. Lembre-se de que Go é estaticamente tipado.

Exemplo, por favor. Dê uma olhada na seguinte interface Pessoa:

type Person interface {
    Name() string
    Age() int
}

Uma possível implementação dessa interface é:

type Gamer struct {
    name  string
    age   int
}

func NewGamer(name string, age int) *Gamer {
    return &Gamer{
        name: name,
        age:  age,
    }
}

func (g *Gamer) Name() string {
    return g.name
}

func (g *Gamer) Age() int {
    return g.age
}

A Go entende que Gamer é uma Person?

func main() {
    var person Person = NewGamer("Jane Doe", 42)
    fmt.Println(person.Name())
}

A saída deste programa:

╰─ go run example.go
Jane Doe

Sim, o Go entende que o tipo Gamer é umaPerson (ou que implementa a interface Person)!

Quando retornar structs

Tudo bem, agora que compreendemos o funcionamento das interfaces em Go, vamos imaginar que desejamos estender o comportamento do Gamer. Também vamos dizer que tem um slice de jogos (Game):

type Person interface {
    Name() string
    Age() int
}

type Game string
type Gamer struct {
    name  string
    age   int
    games []Game
}

func NewGamer(name string, age int) *Gamer {
    return &Gamer{
        name: name,
        age:  age,
    }
}

func (g *Gamer) Name() string {
    return g.name
}

func (g *Gamer) Age() int {
    return g.age
}

func (g *Gamer) Games() []Game {
    return g.games
}

func (g *Gamer) AddGame(game Game) {
    g.games = append(g.games, game)
}

Observe que o programa ainda funciona neste momento, pois o tipo Gamer ainda implementa Person, apenas adicionamos mais comportamento e estado a ele.

Agora, vamos tentar simplesmente modificar a função main que tínhamos antes para fazer uso dessas novas coisas que adicionamos:

func main() {
    var person Person = NewGamer("Jane Doe", 42)
    fmt.Println(person.Name())
    person.AddGame("Metal Gear Solid 3")
}

Nos damos de cara com:

╰─ go run example.go
# command-line-arguments
./example.go.go:46:8: person.AddGame undefined (type Person has no field or method AddGame)

Isso ocorre porque a variável person é do tipoPerson, que não possui o método AddGame(). Se criarmos uma variável gamer do tipo *Gamer, podemos acessar esses novos métodos legais e brilhantes:

func main() {
    var person Person = NewGamer("Jane Doe", 42)
    fmt.Println(person.Name())

    var gamer *Gamer = NewGamer("John Doe", 29)
    gamer.AddGame("Metal Gear Solid 3")
    fmt.Println(gamer.Games())
}

A execução ocorre sem problemas:

╰─ go run example.go  
Jane Doe
[Metal Gear Solid 3]

Agora, e se a função NewGamer() na verdade retornasse a interface Person?

func NewGamer(name string, age int) Person {
    return &Gamer{
        name: name,
        age:  age,
    }
}

Nesse cenário, nunca poderíamos fazer a seguinte atribuição:

var gamer *Gamer = NewGamer("John Doe", 29)

Porque NewGamer retorna Person, não *Gamer. E mesmo se mudarmos o tipo de gamer para Person, ficaríamos presos ao comportamento da interface Person apenas. Perderíamos o acesso aos métodos que somente o tipo Gamer possui.

Essa é a principal motivação por trás do retorno de structs em vez de interfaces: deixa a cargo de quem está invocando a função ou método se quer seu retorno como uma interface ou se quer usá-lo como struct e, no final das contas, isso faz muito sentido.

Quando retornar interfaces?

Vamos expandir um pouco as implementações anteriores do Person. Agora também teremos um tipo Student:

type Student struct {
    name      string
    age       int
    knowledge int
}

func NewStudent(name string, age int) *Student {
    return &Student{
        name: name,
        age: age,
    }
}

func (s *Student) Name() string {
    return s.name
}

func (s *Student) Age() int {
    return s.age
}

func (s *Student) Study(hours int) {
    s.knowledge += hours
}

Tornar-se uma pessoa cheia de conhecimento não é tão simples como o descrito aqui, mas esse modelo atende aos nossos requisitos. Lembre-se do princípio KISS.

E se precisássemos imprimir os nomes de todas as pessoas que conhecemos? Nesse caso, uma função auxiliar retornando um slice de Person faria muito sentido, porque Name() faz parte da interface Person:

func PrintAllNames() {
    for _, person := range getAllPeople() {
        fmt.Printf("Name: %s\n", person.Name())
    }
}

func getAllPeople() []Person {
    var people []Person
    // implementação da lógica
    return people
}

Isso é simples, mas um dos casos em que é realmente aceitável que um método ou função retorne uma interface em vez da própria estrutura.

Sem uma função como essa, você precisaria criar uma função separada para obter todas as instâncias de cada implementação de Person, outra para imprimir os nomes dessas instâncias para cada implementação de Person e uma última que orquestra tudo isso.

func PrintAllNames() {
    printAllGamerNames()
    printAllStudentNames()
}

func printAllGamerNames() {
    for _, gamer := range getAllGamers() {
        fmt.Printf("Name: %s\n", gamer.Name())
    }
}

func getAllGamers() []Gamer {
    var gamers []Gamer
    // implementação da lógica
    return gamers
}

func printAllStudentNames() {
    for _, student := range getAllStudents() {
        fmt.Printf("Name: %s\n", student.Name())
    }
}

func getAllStudents() []Student {
    var students []Student
    // implementação da lógica
    return students
}

Vê aquela repetição desagradável de código? E pior: prepare-se para fazer isso toda vez que adicionar outra implementação do Person. Aposto que não está feliz com isso. E ainda pior: esse tipo de adição manual é suscetível a erros e aumenta a probabilidade de introduzir um bug.

Você poderia dizer "bem, mas mesmo que você retornasse um slice de Person, você ainda precisaria escrever a lógica necessária para obter todas as instâncias de uma nova implementação de Person" e você estaria correta/correto. Mas observe como você não precisa escrever uma lógica específica para imprimir os nomes, isso é feito apenas uma vez na versão anterior da função PrintAllNames():

func PrintAllNames() {
    for _, person := range getAllPeople() {
        fmt.Printf("Name: %s\n", person.Name())
    }
}

Resumindo: retornar structs é uma boa ideia na maioria das vezes, porque você deixa o usuário livre para escolher como usar seu retorno, mas há casos em que o uso de uma interface faz mais sentido e pode evitar a escrita de código desnecessária.

Obrigado por ler o meu artigo! Deixe-me saber sua opinião sobre os pontos que levantei e se você tiver uma visão diferente, diga qual é! Estou sempre disponível para uma discussão produtiva. :-)

Should my methods return structs or interfaces in Go?

Lucas Caparelli — Sat, 11 Jul 2020 14:44:34 +0000

Versão em Português

Like most things in software design, it depends. And I cannot stress this enough, it really depends on the situation and what you wish to achieve.

Now, I hear some of you already screaming at the top of your lungs a very useful rule of thumb (or even proverb, if you will): "Accept interfaces, return structs". That's very good advice, really, but there always are exceptions. No pattern is so flexible that it fits every situation.

With that said, I'd wager this rule does make sense more often than not, so let's have a look at the reasoning behind returning structs.

But first, some basics about how interfaces work in Go. If you're already familiar with them, feel free to skip ahead to the next section.

Interfaces in Go

It's important to keep in mind that Go interfaces are not strictly bound to types. What I mean by this is that you never explicitly say that a type implements a particular interface. All that you need to do in order to implement an interface in Go is to implement the methods that satisfy the interface itself.

Think of an interface as a set of behaviors that are expected from a type. You don't usually see ducks with a label written "Duck", but you know it is one because it looks like a duck, it quacks like a duck, it has feathers like a duck, etc. You infer what it is from its behavior, and that is exactly what Go does in compile time.

If you're wondering, Go uses "structural typing", not "duck typing", meaning this all happens in compile time, not run time. Remember that Go is statically typed.

Example, please. Take a look at the following Person interface:

type Person interface {
    Name() string
    Age() int
}

A possible implementation of that interface is:

type Gamer struct {
    name  string
    age   int
}

func NewGamer(name string, age int) *Gamer {
    return &Gamer{
        name: name,
        age:  age,
    }
}

func (g *Gamer) Name() string {
    return g.name
}

func (g *Gamer) Age() int {
    return g.age
}

Does Go understand that Gamer is a Person?

func main() {
    var person Person = NewGamer("Jane Doe", 42)
    fmt.Println(person.Name())
}

The output from this program:

╰─ go run example.go
Jane Doe

Yes, Go understands that the Gamer type is a Person (or that it implements the Person interface)!

When to return structs

Alright, now that we've refreshed our understanding of interfaces in Go, let's imagine that we wish to extend the Gamer behavior. We'll also say it has a slice of games:

type Person interface {
    Name() string
    Age() int
}

type Game string
type Gamer struct {
    name  string
    age   int
    games []Game
}

func NewGamer(name string, age int) *Gamer {
    return &Gamer{
        name: name,
        age:  age,
    }
}

func (g *Gamer) Name() string {
    return g.name
}

func (g *Gamer) Age() int {
    return g.age
}

func (g *Gamer) Games() []Game {
    return g.games
}

func (g *Gamer) AddGame(game Game) {
    g.games = append(g.games, game)
}

Note that the program still works at this point as Gamer still implements Person, we just added more behavior and state to it.

Now, let's try simply modifying the main function we had before to make use of this new stuff we added:

func main() {
    var person Person = NewGamer("Jane Doe", 42)
    fmt.Println(person.Name())
    person.AddGame("Metal Gear Solid 3")
}

We'll run into:

╰─ go run example.go
# command-line-arguments
./example.go.go:46:8: person.AddGame undefined (type Person has no field or method AddGame)

This is because the person variable is of type Person, which does not have the AddGame() method. If we create a variable gamer of type *Gamer we can access those new cool and shiny methods:

func main() {
    var person Person = NewGamer("Jane Doe", 42)
    fmt.Println(person.Name())

    var gamer *Gamer = NewGamer("John Doe", 29)
    gamer.AddGame("Metal Gear Solid 3")
    fmt.Println(gamer.Games())
}

It runs fine:

╰─ go run example.go  
Jane Doe
[Metal Gear Solid 3]

Now, what if the NewGamer() function actually returned the Person interface?

func NewGamer(name string, age int) Person {
    return &Gamer{
        name: name,
        age:  age,
    }
}

In this scenario we'd never be able to make the following assignment:

var gamer *Gamer = NewGamer("John Doe", 29)

Because NewGamer returns Person, not *Gamer. And even if we change gamer's type to Person we'd be stuck with the behavior from the Person interface only. We'd lose access to the nice methods only the Gamer type has.

This is the main motivation behind returning structs instead of interfaces: it leaves it up to the caller if they want to use it as the interface or if they want to use it as the struct, and in the end that makes a lot of sense.

When to return interfaces?

Let's expand a bit on our previous Person implementations. Now we'll also have a Student:

type Student struct {
    name      string
    age       int
    knowledge int
}

func NewStudent(name string, age int) *Student {
    return &Student{
        name: name,
        age: age,
    }
}

func (s *Student) Name() string {
    return s.name
}

func (s *Student) Age() int {
    return s.age
}

func (s *Student) Study(hours int) {
    s.knowledge += hours
}

Becoming a person filled with knowledge isn't as simple as depicted here, but this model meets our requirements. Remember to KISS.

What if we needed to print the names of every people we know? In this case, an auxiliary function returning a slice of Person would make a lot of sense, because Name() is part of the Person interface:

func PrintAllNames() {
    for _, person := range getAllPeople() {
        fmt.Printf("Name: %s\n", person.Name())
    }
}

func getAllPeople() []Person {
    var people []Person
    // logic implementation
    return people
}

This is simple, but one of the cases on which it's actually ok for a method or function to return an interface instead of the struct itself.

Without a function like this, you would need to create a separate function to get all instances of each implementation of Person, another for printing the names of these instances for each implementation of Person and a final one that orchestrates all of these.

func PrintAllNames() {
    printAllGamerNames()
    printAllStudentNames()
}

func printAllGamerNames() {
    for _, gamer := range getAllGamers() {
        fmt.Printf("Name: %s\n", gamer.Name())
    }
}

func getAllGamers() []Gamer {
    var gamers []Gamer
    // logic implementation
    return gamers
}

func printAllStudentNames() {
    for _, student := range getAllStudents() {
        fmt.Printf("Name: %s\n", student.Name())
    }
}

func getAllStudents() []Student {
    var students []Student
    // logic implementation
    return students
}

See that nasty repetition of code? And worse: get ready to do this every time you add another implementation of Person. Not looking forward to it, I assume. And even worse: this sort of manual addition is error-prone and is likely to lead to bugs.

You could say "well, even if you returned a slice of Person you would still need to write the necessary logic to get all the instances of a new implementation of Person" and you would be correct. But notice how you do not need to write specific logic for printing the names, you only do that once in the previous version of the PrintAllNames() function:

func PrintAllNames() {
    for _, person := range getAllPeople() {
        fmt.Printf("Name: %s\n", person.Name())
    }
}

Summarizing: returning structures is good most of the time because you leave it up to the caller to decide how to make the assignment and how to use it, but there are cases on which using an interface just makes more sense and can save you a lot of unnecessary writing.

Thank you for reading my article! Let me know your thoughts on the points I tried to make and if you have a different view, please let me know! I'm always up for productive discussion. :-)