Import cycle not allowed em Go: como quebrar o ciclo vicioso

Import cycle not allowed: quando Go coloca um bloqueio no caminho do código

Cada desenvolvedor Go, mais cedo ou mais tarde, se depara com esta frase. O compilador interrompe abruptamente a construção, emitindo uma mensagem seca: import cycle not allowed. Parece que o programa é lógico e os pacotes estão conectados "como deveriam". Mas Go pensa diferente.

Este erro não é um capricho da linguagem, mas uma proteção contra o caos. Dependências cíclicas transformam o código em um macarrão, dificultam os testes e tornam a construção imprevisível. Neste artigo, analisaremos por que ocorre o import cycle not allowed e compararemos três abordagens para resolvê-lo: através de interfaces, através de um pacote mediador e através de refatoração. Você descobrirá qual método escolher dependendo da situação.

Por que Go proíbe a importação cíclica?

Ao contrário de linguagens com carregamento dinâmico (Python, JavaScript), Go é compilado estaticamente. O compilador constrói o grafo de dependências dos pacotes uma única vez. Se o pacote A importa o pacote B, e B importa A — surge um ciclo. Go não consegue resolver esta ordem, portanto interrompe a compilação.

Exemplo da vida real: o pacote users trabalha com usuários, o pacote orders trabalha com pedidos. Em orders, precisamos de informações sobre o usuário, e em users, da lista de pedidos. Resultado: import cycle not allowed.

Cenário típico: dois pacotes que "são amigos" próximos demais

Vamos considerar uma situação clássica. Temos dois pacotes: users e notifier.

Pacote users (arquivo users.go):

package users\n\nimport "notifier"\n\ntype User struct {\n    Name  string\n    Email string\n}\n\nfunc (u *User) SendWelcome() {\n    notifier.Notify(u.Email, "Welcome!")\n}\n

Pacote notifier (arquivo notifier.go):

package notifier\n\nimport "users"\n\nfunc Notify(email, msg string) {\n    // enviar notificação\n}\n\nfunc GetUserEmail(user *users.User) string {\n    return user.Email\n}\n

O compilador emitirá: import cycle not allowed: users -> notifier -> users. Ambos os pacotes tentam importar um ao outro. O que fazer?

Abordagem 1: Interfaces — "dividir e conquistar"

A maneira mais elegante é extrair a dependência para o nível de interface. Go adora contratos explícitos.

Criamos o pacote contracts, onde definimos a interface Notifier:

// contracts/contracts.go\npackage contracts\n\ntype Notifier interface {\n    Notify(email, msg string)\n}\n

Agora users não depende diretamente de notifier:

// users/users.go\npackage users\n\nimport "contracts"\n\ntype User struct {\n    Name  string\n    Email string\n}\n\nfunc (u *User) SendWelcome(n contracts.Notifier) {\n    n.Notify(u.Email, "Welcome!")\n}\n

E notifier implementa a interface:

// notifier/notifier.go\npackage notifier\n\ntype EmailNotifier struct{}\n\nfunc (e *EmailNotifier) Notify(email, msg string) {\n    // lógica de envio\n}\n

Vantagens:

\n
• Ausência total de importação cíclica.
\n
• Testes fáceis: é possível substituir a implementação.
\n
• Baixo acoplamento (loose coupling).
\n

Desvantagens:

\n
• Requer um pacote adicional com interfaces.
\n
• Às vezes, interfaces são desnecessárias para projetos simples.
\n

Abordagem 2: Pacote mediador (Mediator)

Se as interfaces parecerem excessivas, pode-se criar um terceiro pacote que servirá como "ponte" entre os dois pacotes conflitantes.

Criamos o pacote bridge:

// bridge/bridge.go\npackage bridge\n\nimport (\n    "notifier"\n    "users"\n)\n\nfunc SendWelcomeToUser(user *users.User) {\n