Arquivos orientação a objetos

Dando continuidade na série sobre SOLID, nesse post vamos falar um pouco sobre Interface Segregation. Esse princípio talvez seja o mais utilizado na linguagem. Digo isso pois ele é fortemente utilizado nos packages core do Go, como por exemplo o package io.

Antes de continuar, se você chegou por aqui agora e ainda não viu os outros posts da série, convido-o a dar uma olhada.

Voltando à esse post, vamos relembrar o que diz o conceito de Interface Segregation.

💡 Uma classe não deve ser obrigada a implementar interfaces e métodos que não utilizará. Em outras palavras, é melhor ter 6 interfaces bem específicas, do que 2 mais genéricas.

Embora Go não implemente orientação a objetos, Interface Segregation pode ser aplicado na linguagem sem problemas. Isso devido a forma como structs e interfaces funcionam na linguagem.

Single Responsability

Uma classe ou, como é no caso do Go, uma struct deve ter uma única responsabilidade. Ou seja, cada struct deve ser projetada para executar uma determinada ação.

Pensando em um CRUD, é claro que você não terá uma struct para cada uma das ações (Create, Read, Update e Delete). Mas também não terá somente uma struct para lidar com todas as responsabilidades do package.

O ideal é ter pelo menos uma struct que represente a entidade do package. Uma para lidar com as transações com banco de dados, comumente chamada de repository. E outra para tratar as requests, independente se forem via API ou em algum modelo MVC.

Aprenda Golang

Tudo sobre o mundo GO

Categoria: orientação a objetos

O que é e como Interface Segregation é aplicada no Go

O que é SOLID?

Single Responsability