Golang 08 — Interface

Em programas reais, raramente trabalhamos apenas com tipos concretos isolados. À medida que o sistema cresce, torna-se necessário definir comportamentos esperados, independentemente da implementação específica de cada tipo.

Interfaces em Go existem para resolver exatamente esse problema. Em vez de focar na estrutura de um tipo, elas descrevem o que um valor é capaz de fazer.

Uma interface define um conjunto de métodos. Qualquer tipo que implemente esses métodos passa a satisfazer essa interface, sem necessidade de declaração explícita. Esse modelo é conhecido como tipagem estrutural, e representa uma diferença importante em relação a linguagens que exigem relações formais de herança ou implementação.

Essa abordagem tem implicações diretas no design do código. Como não há vínculo explícito entre interface e implementação, o acoplamento entre as partes do sistema tende a ser menor. Tipos podem evoluir de forma independente, desde que continuem atendendo aos contratos esperados.

Em Go, interfaces não são um mecanismo de hierarquia, mas de composição de comportamento. Elas permitem definir limites claros entre partes do sistema, facilitando substituição de implementações, testes e organização do código.

Ao longo desta seção, serão apresentados os conceitos fundamentais das interfaces, seu uso idiomático e os cuidados necessários para evitar abstrações desnecessárias ou mal definidas.

Conceito de interface

Uma interface em Go é um tipo que define um conjunto de métodos. Diferentemente de um tipo concreto, ela não contém dados nem implementação — apenas a descrição do comportamento esperado.

A definição de uma interface é direta:

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

Nesse exemplo, qualquer tipo que implemente o método Write com essa assinatura passa a satisfazer a interface Writer.

Um ponto importante é que interfaces em Go são baseadas em comportamento, não em estrutura de dados. Isso significa que o que importa não é como o tipo é implementado internamente, mas sim quais operações ele expõe.

Considere um tipo simples:

type File struct{}

func (f File) Write(p []byte) (int, error) {
    // implementação
    return len(p), nil
}

O tipo File satisfaz a interface Writer automaticamente, pois possui um método compatível. Não há qualquer declaração explícita indicando essa relação.

Esse modelo permite tratar diferentes tipos de forma uniforme, desde que compartilhem o mesmo comportamento. Por exemplo, uma função pode receber qualquer valor que satisfaça a interface:

func Save(w Writer) {
    w.Write([]byte("dados"))
}

Nesse caso, Save não depende de um tipo específico, apenas do comportamento definido pela interface.

Esse é o papel central das interfaces em Go: permitir que o código seja estruturado em torno de contratos de comportamento, em vez de depender diretamente de implementações concretas.

Implementação implícita

Em Go, a relação entre um tipo concreto e uma interface é estabelecida de forma implícita. Não existe uma palavra-chave como implements para declarar que um tipo satisfaz uma interface. Essa relação é verificada automaticamente pelo compilador com base na compatibilidade dos métodos.

Considere novamente a interface:

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

E um tipo concreto:

type Buffer struct{}

func (b Buffer) Write(p []byte) (int, error) {
    return len(p), nil
}

Mesmo sem qualquer declaração explícita, Buffer satisfaz a interface Writer, pois possui um método com a mesma assinatura.

Essa característica tem implicações importantes:

• não há dependência direta entre interface e implementação;
• tipos podem ser reutilizados em diferentes contextos sem modificações;
• o acoplamento entre partes do sistema é reduzido.

O compilador verifica essa compatibilidade no momento do uso. Por exemplo:

func Save(w Writer) {}

func main() {
    var b Buffer
    Save(b)
}

Se Buffer não implementasse corretamente o método Write, o erro seria detectado em tempo de compilação.

Esse modelo também permite que um mesmo tipo satisfaça múltiplas interfaces, desde que implemente os métodos necessários para cada uma delas.

A implementação implícita é um dos elementos centrais do design de Go. Ela favorece a composição e evita a criação de hierarquias rígidas, tornando o código mais flexível e menos acoplado.

Interfaces como contrato

Interfaces em Go são frequentemente utilizadas como contratos de comportamento entre partes do sistema. Em vez de depender diretamente de tipos concretos, funções e componentes passam a depender de interfaces que descrevem o que é necessário para sua execução.

Considere uma função que precisa persistir dados:

func Save(w Writer) {
    w.Write([]byte("dados"))
}

Nesse caso, a função Save não depende de um tipo específico, apenas de algo que satisfaça o comportamento definido pela interface Writer. Isso permite que diferentes implementações sejam utilizadas sem alterar o código da função.

Essa abordagem é especialmente útil na definição de limites entre camadas de um sistema. Por exemplo:

• a camada de aplicação pode depender de uma interface de repositório;
• a camada de infraestrutura fornece a implementação concreta;
• testes podem utilizar implementações alternativas, como mocks ou fakes.

Esse desacoplamento facilita a substituição de implementações e torna o código mais flexível. Uma função pode operar sobre qualquer tipo que satisfaça a interface, sem conhecer detalhes da implementação.

Em testes, isso se traduz na possibilidade de isolar comportamentos:

type FakeWriter struct{}

func (f FakeWriter) Write(p []byte) (int, error) {
    return len(p), nil
}

Nesse cenário, FakeWriter pode ser utilizado para validar o comportamento de Save sem depender de recursos externos, como arquivos ou rede.

Interfaces, portanto, atuam como pontos de separação no sistema. Elas definem o que é esperado, enquanto as implementações concretas definem como esse comportamento é realizado.

Essa separação é fundamental para a organização do código, permitindo evoluir partes do sistema de forma independente, desde que os contratos definidos pelas interfaces sejam mantidos.

Uso idiomático

Em Go, interfaces são usadas de forma intencionalmente simples. Diferentemente de outras linguagens, não há incentivo para criar hierarquias complexas ou abstrações genéricas extensas. O uso idiomático privilegia interfaces pequenas, específicas e orientadas ao comportamento.

Um exemplo clássico da biblioteca padrão é:

type Reader interface {
    Read(p []byte) (n int, err error)
}

E também:

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

Cada interface define um único comportamento claro. Isso permite que tipos implementem apenas o que faz sentido, sem a necessidade de atender a contratos maiores do que o necessário.

Interfaces maiores podem ser formadas por composição:

type ReadWriter interface {
    Reader
    Writer
}

Nesse caso, ReadWriter representa qualquer tipo que implemente ambos os comportamentos.

Uma prática comum é evitar a criação de interfaces genéricas ou abrangentes demais. Interfaces devem ser definidas com base no uso real, e não como uma tentativa antecipada de abstração. Em muitos casos, o uso direto de tipos concretos é mais simples e adequado.

Outro princípio importante é que interfaces costumam ser definidas no local onde são utilizadas, e não onde são implementadas. Isso reduz acoplamento e evita a criação de contratos desnecessários.

Em termos práticos:

• prefira interfaces pequenas e focadas;
• use composição para formar comportamentos mais complexos;
• evite abstrações prematuras;
• utilize tipos concretos quando não há necessidade clara de abstração.

Esse estilo reflete a filosofia da linguagem: simplicidade, clareza e foco no uso real, em vez de generalização excessiva.

Interface vazia (any)

A interface vazia, representada por interface{} — e, nas versões mais recentes da linguagem, pelo alias any — é um tipo que não define nenhum método:

var v any

Como não há métodos a serem satisfeitos, qualquer tipo em Go implementa a interface vazia. Isso significa que valores de qualquer tipo podem ser atribuídos a uma variável do tipo any.

Esse comportamento torna a interface vazia útil em situações onde o tipo exato não é conhecido previamente, como em estruturas genéricas, APIs dinâmicas ou manipulação de dados heterogêneos.

Por exemplo:

func Print(v any) {
    fmt.Println(v)
}

No entanto, essa flexibilidade tem um custo. Ao utilizar any, perde-se a informação de tipo em tempo de compilação, e o código passa a depender de verificações em tempo de execução para recuperar o tipo concreto.

Isso pode levar a:

• perda de segurança de tipo;
• necessidade de type assertion ou type switch;
• aumento da complexidade do código.

Por esse motivo, o uso de any deve ser criterioso. Em muitos casos, é preferível definir interfaces específicas que representem o comportamento esperado, mantendo o código mais claro e seguro.

Em termos idiomáticos, any é útil quando há uma necessidade real de lidar com múltiplos tipos sem um comportamento comum definido. Fora desses cenários, o uso de interfaces mais específicas tende a produzir código mais robusto e expressivo.

Type assertion e type switch

Quando um valor é armazenado em uma interface, seu tipo concreto não é conhecido diretamente. Para recuperar esse tipo, Go fornece dois mecanismos: type assertion e type switch.

A type assertion permite extrair o valor concreto de uma interface:

var v any = "texto"

s := v.(string)

Nesse caso, assume-se que v contém um valor do tipo string. Se essa suposição estiver incorreta, ocorre um erro em tempo de execução.

Para evitar esse problema, é possível utilizar a forma segura:

s, ok := v.(string)
if ok {
    fmt.Println(s)
}

Aqui, ok indica se a conversão foi bem-sucedida. Caso contrário, o programa continua sem erro.

Quando há necessidade de tratar múltiplos tipos possíveis, o uso de type switch é mais adequado:

switch v := v.(type) {
case string:
    fmt.Println("string:", v)
case int:
    fmt.Println("int:", v)
default:
    fmt.Println("tipo desconhecido")
}

O type switch permite executar diferentes blocos de código com base no tipo concreto armazenado na interface.

Embora esses mecanismos sejam úteis, seu uso frequente pode indicar que a abstração não está bem definida. Em muitos casos, é preferível modelar o comportamento com interfaces mais específicas, evitando a necessidade de inspeção de tipo em tempo de execução.

Em termos práticos, type assertion e type switch são ferramentas de suporte, não o centro do modelo. O uso idiomático de interfaces em Go privilegia a definição de contratos de comportamento, reduzindo a dependência de verificações dinâmicas.

Nil e interfaces

O comportamento de nil em interfaces é uma das fontes mais comuns de confusão em Go. Isso ocorre porque uma interface é composta internamente por dois elementos: o tipo concreto e o valor associado.

Uma interface é considerada nil apenas quando ambos são nil.

Considere o exemplo:

var w Writer
fmt.Println(w == nil) // true

Nesse caso, a interface não possui tipo nem valor, portanto é nil.

Agora, observe:

var f *File = nil
var w Writer = f

fmt.Println(w == nil) // false

Aqui, w contém um tipo (*File), mas o valor é nil. Como a interface possui um tipo associado, ela não é considerada nil.

Esse comportamento pode levar a erros sutis, especialmente quando se espera que uma interface represente ausência de valor.

Um caso comum ocorre com retornos de função:

func NewWriter() Writer {
    var f *File = nil
    return f
}

Nesse cenário, a função retorna uma interface não nula, mesmo que o valor interno seja nil.

Para evitar esse tipo de problema, é importante garantir que:

• funções retornem nil de forma consistente quando não há valor;
• interfaces não sejam utilizadas para encapsular valores nulos sem necessidade;
• verificações de nil considerem o comportamento da interface, e não apenas do valor interno.

Esse detalhe reforça a importância de compreender como interfaces são representadas em Go. Embora o modelo seja simples, suas implicações práticas podem afetar diretamente a corretude do programa.

Verificação explícita de implementação

Embora a implementação de interfaces em Go seja implícita, é comum utilizar uma forma de verificação em tempo de compilação para garantir que um tipo satisfaz uma interface.

Esse padrão é escrito da seguinte forma:

var _ domain.AccountRepository = (*Repository)(nil)

Essa linha não tem efeito em tempo de execução, mas força o compilador a verificar se *Repository implementa a interface domain.AccountRepository.

Se algum método estiver faltando ou com assinatura incorreta, o erro será detectado durante a compilação.

Por que isso é útil

Como a implementação é implícita, erros só aparecem quando o tipo é usado como interface. Em sistemas maiores, isso pode ocorrer longe da definição do tipo, dificultando a identificação do problema.

Essa verificação antecipa esse erro, tornando explícito o contrato esperado.

Uso típico

Esse padrão é comum em cenários como:

• implementação de repositórios em camadas de infraestrutura;
• adaptação de interfaces externas;
• garantia de conformidade com contratos de domínio.

Por exemplo:

type Repository struct {
    // dependências
}

var _ domain.AccountRepository = (*Repository)(nil)

Nesse caso, fica claro que Repository deve satisfazer o contrato definido no domínio.

Ponteiro vs valor

Outro detalhe importante é o uso de (*Repository)(nil) em vez de Repository{}.

Isso garante que a verificação seja feita sobre o tipo com receptor de ponteiro, o que é comum quando os métodos da interface modificam estado ou evitam cópias desnecessárias.

Se a interface for implementada por valor, a verificação também pode ser feita dessa forma:

var _ SomeInterface = (MyType{})

Avaliação técnica

Esse padrão não é obrigatório, mas é amplamente utilizado em código idiomático mais estruturado.

Ele não altera o comportamento do programa, mas melhora:

• a clareza das intenções;
• a segurança em refatorações;
• a proximidade entre contrato e implementação.

Em projetos maiores, especialmente com separação entre domínio e infraestrutura, esse tipo de verificação deixa de ser opcional e passa a ser uma prática recomendada.

Boas práticas

O uso de interfaces em Go deve ser orientado pela necessidade real de abstração, e não por padrão. Interfaces são uma ferramenta poderosa, mas seu uso indiscriminado pode introduzir complexidade desnecessária.

Uma prática comum é definir interfaces no ponto de uso, e não no ponto de implementação. Isso permite que o código consumidor determine exatamente quais comportamentos são necessários, evitando contratos excessivos.

Por exemplo, em vez de definir uma interface genérica no pacote de implementação, é preferível que a camada que consome esse comportamento declare a interface mínima necessária.

Outro princípio importante é manter interfaces pequenas e focadas. Interfaces com muitos métodos tendem a ser difíceis de implementar e reduzem a flexibilidade do sistema. Em Go, é comum encontrar interfaces com apenas um ou dois métodos.

Também é recomendável evitar abstrações prematuras. Nem todo tipo precisa de uma interface. Em muitos casos, o uso direto de tipos concretos é mais simples, mais claro e mais eficiente. Interfaces devem surgir quando há múltiplas implementações ou quando há necessidade explícita de desacoplamento.

Em sistemas mais estruturados, é comum adicionar uma verificação explícita de conformidade entre tipo e interface:

var _ domain.AccountRepository = (*Repository)(nil)

Esse padrão força o compilador a validar que o tipo implementa corretamente a interface, antecipando erros que, de outra forma, só apareceriam no ponto de uso.

Em termos práticos:

• defina interfaces onde são utilizadas;
• mantenha interfaces pequenas e específicas;
• prefira tipos concretos quando não há necessidade de abstração;
• evite generalizações desnecessárias;
• utilize verificação explícita quando o contrato for relevante;
• use interfaces para representar comportamento, não estrutura.

Por fim, é importante lembrar que interfaces não substituem o entendimento do domínio do problema. Elas são uma ferramenta para organizar o código, e seu valor depende diretamente da qualidade dos contratos que representam.

Considerações finais

Interfaces em Go são uma ferramenta para definir comportamento, não para estruturar hierarquias. Seu principal papel é permitir que diferentes partes do sistema interajam por meio de contratos simples, reduzindo o acoplamento e facilitando a evolução do código.

Ao longo desta seção, alguns princípios se destacam:

• interfaces descrevem o que um tipo faz, não o que ele é;
• a implementação é implícita e baseada em compatibilidade de métodos;
• o uso idiomático privilegia interfaces pequenas e específicas;
• abstrações devem surgir do uso, e não de antecipação.

Esse modelo incentiva um estilo de programação baseado em composição. Em vez de construir relações rígidas entre tipos, o código passa a ser organizado em torno de comportamentos que podem ser combinados de diferentes formas.

Por outro lado, o uso inadequado de interfaces pode introduzir complexidade desnecessária. Interfaces muito amplas, uso excessivo de any ou dependência frequente de type assertions são sinais de que a abstração pode não estar bem definida.

Em sistemas maiores, especialmente com separação clara entre domínio e infraestrutura, torna-se importante tornar explícitos os contratos adotados. O uso de verificações em tempo de compilação ajuda a garantir que implementações concretas permaneçam alinhadas com as interfaces definidas, mesmo ao longo de refatorações.

Em termos práticos, a principal mudança de perspectiva é sair de um modelo centrado em tipos concretos para um modelo centrado em contratos de comportamento. Essa abordagem torna o código mais flexível, mais testável e mais fácil de manter.

Como em outros aspectos da linguagem, a simplicidade continua sendo o critério mais importante. Interfaces devem ser utilizadas quando agregam clareza e flexibilidade — e evitadas quando não trazem benefícios concretos.