Boas Práticas e Padrões Idiomáticos em Go e C
Nem sempre boas práticas são consideradas design patterns formais. Porém, quando uma técnica se torna a única forma eficaz de resolver problemas recorrentes, ela deixa de ser apenas "higiene de código" e passa a funcionar como um padrão idiomático da linguagem.
Este documento explora como structs, composição e interfaces em Go (e até em C) podem ser vistos como soluções de design aplicando esses princípios para um bom código. O texto começa explicando o uso em C de ponteiros e faz uma analogia sobre injeção de código de POO. Este documento tem por objetivo de tornar um dia um desgin para GO ou até C, QUE SÃO PROCEDURAIS. É um exemplo onde você não resolve bem uma questão sem esse principio de que se você não usar, você não resolve da melhor maneira. O documento é trabalhado nas fases seguintes com o argumento de porque usar ou não usar para justificar um design.
Este documento explora como structs, composição e interfaces em Go (e até em C) podem ser vistos como soluções de design aplicando esses princípios para um bom código. O texto começa explicando o uso em C de ponteiros e faz uma analogia sobre injeção de código de POO. Este documento tem por objetivo de tornar um dia um desgin para GO ou até C, QUE SÃO PROCEDURAIS. É um exemplo onde você não resolve bem uma questão sem esse principio de que se você não usar, você não resolve da melhor maneira. O documento é trabalhado nas fases seguintes com o argumento de porque usar ou não usar para justificar um design.
Parte 2: EXPLICAÇÃO 1
Essa parte do por que usar ou o erro de não usar, pois um bom design e responder questões onde uma melhor forma ou quase impossível de criar sem uma boa prática nos códigos.
Esse documento tem como objetivo de virar um design e algo novo, não fixo, mais aberto do que já existe e as melhores formas de criar o código.
Algumas coisas vou mostrar com a resposta de algumas IAs sobre o texto, não tudo, pois é muito grande, mas vocês verão e até poderão testar em algumas IAs e tirarem suas conclusões.
Estrutura da explicação (passo a passo)
1. Structs
Por que usar:
- Agrupam dados relacionados em uma entidade lógica.
- Evitam espalhar variáveis soltas pelo código.
- Permitem criar métodos associados, dando mais clareza sem precisar de classes.
Se não usar:
- O código fica fragmentado, difícil de entender.
- Você acaba passando múltiplos parâmetros soltos em funções, aumentando risco de erro.
Analogia com SOLID:
- Relaciona-se ao Single Responsibility Principle (SRP): um struct bem definido deve ter uma responsabilidade clara.
2. Interfaces
Por que usar:
- Permitem abstração de comportamento sem acoplamento rígido.
- Facilitam testes (mockar implementações).
- Tornam o código extensível sem precisar alterar o que já existe.
Se não usar:
- Funções e módulos ficam dependentes de implementações concretas.
- Dificulta substituição ou evolução de código.
Analogia com SOLID:
- Relaciona-se ao Dependency Inversion Principle (DIP) e ao Interface Segregation Principle (ISP): em Go, interfaces pequenas e específicas são preferíveis.
3. Composição
Por que usar:
-
- Promove flexibilidade: você combina comportamentos em vez de criar hierarquias rígidas.
- Evita acoplamento excessivo.
Se não usar:
- Você pode acabar duplicando código.
- Ou tentar simular herança com hacks, o que vai contra o estilo da linguagem.
Analogia com SOLID:
- Relaciona-se ao Open/Closed Principle (OCP): composição permite estender funcionalidades sem modificar código existente.
Figura 1
Resumo da analogia Go <> SOLID
Este documento foi testado em diversas outras inteligências como Gemini, Copilot, Chatgpt e por último Claude.
Aqui está a resposta da inteligência em cima do que está sendo construído, o Copilot.
Copilot:
"Minha sugestão: podemos ir parte por parte como você pediu. Primeiro aprofundamos em structs (com exemplos bons e ruins), depois interfaces, e por fim composição. Assim você terá um guia claro mostrando o motivo de usar e o que dá errado de não usar."
Agora mais algumas partes melhorando a explicação, com o foco de virar um design para
Esse documento tem como objetivo de virar um design e algo novo, não fixo, mais aberto do que já existe e as melhores formas de criar o código.
Algumas coisas vou mostrar com a resposta de algumas IAs sobre o texto, não tudo, pois é muito grande, mas vocês verão e até poderão testar em algumas IAs e tirarem suas conclusões.
Estrutura da explicação (passo a passo)
1. Structs
Por que usar:
- Agrupam dados relacionados em uma entidade lógica.
- Evitam espalhar variáveis soltas pelo código.
- Permitem criar métodos associados, dando mais clareza sem precisar de classes.
Se não usar:
- O código fica fragmentado, difícil de entender.
- Você acaba passando múltiplos parâmetros soltos em funções, aumentando risco de erro.
Analogia com SOLID:
- Relaciona-se ao Single Responsibility Principle (SRP): um struct bem definido deve ter uma responsabilidade clara.
2. Interfaces
Por que usar:
- Permitem abstração de comportamento sem acoplamento rígido.
- Facilitam testes (mockar implementações).
- Tornam o código extensível sem precisar alterar o que já existe.
Se não usar:
- Funções e módulos ficam dependentes de implementações concretas.
- Dificulta substituição ou evolução de código.
Analogia com SOLID:
- Relaciona-se ao Dependency Inversion Principle (DIP) e ao Interface Segregation Principle (ISP): em Go, interfaces pequenas e específicas são preferíveis.
3. Composição
Por que usar:
-
Go não tem herança, mas composição permite reutilizar código.- Promove flexibilidade: você combina comportamentos em vez de criar hierarquias rígidas.
- Evita acoplamento excessivo.
Se não usar:
- Você pode acabar duplicando código.
- Ou tentar simular herança com hacks, o que vai contra o estilo da linguagem.
Analogia com SOLID:
- Relaciona-se ao Open/Closed Principle (OCP): composição permite estender funcionalidades sem modificar código existente.
Figura 1Resumo da analogia Go <> SOLID
Este documento foi testado em diversas outras inteligências como Gemini, Copilot, Chatgpt e por último Claude.
Aqui está a resposta da inteligência em cima do que está sendo construído, o Copilot.
Copilot:
"Minha sugestão: podemos ir parte por parte como você pediu. Primeiro aprofundamos em structs (com exemplos bons e ruins), depois interfaces, e por fim composição. Assim você terá um guia claro mostrando o motivo de usar e o que dá errado de não usar."
Agora mais algumas partes melhorando a explicação, com o foco de virar um design para
Go.