Princípios SOLID em Go: teoria e prática do A ao Z

Princípios SOLID em Go: teoria e prática do A ao Z

SOLID é a sigla de cinco princípios fundamentais da programação orientada a objetos que ajudam a criar código flexível, sustentável e escalável. Embora Go não seja uma linguagem OOP clássica (não possui classes e herança no sentido tradicional), esses princípios são aplicáveis e extremamente úteis no desenvolvimento com Go. Neste artigo, analisaremos cada princípio com exemplos concretos, mostraremos como aplicá-los em Go e explicaremos por que isso é importante.

1. Single Responsibility Principle (SRP) — Princípio da Responsabilidade Única

Essência: Cada módulo, classe ou função deve ter apenas um motivo para ser alterado. Em outras palavras, uma entidade deve ser responsável por uma única parte da funcionalidade.

Em Go, isso é frequentemente violado quando uma struct realiza muitas tarefas: trabalha com banco de dados, envia e-mail, gera relatórios.

Exemplo ruim (violação do SRP):

type User struct {\n    Name  string\n    Email string\n}\n\nfunc (u *User) Save() error {\n    // lógica de salvar no BD\n    return nil\n}\n\nfunc (u *User) SendWelcomeEmail() error {\n    // lógica de envio de e-mail\n    return nil\n}\n\nfunc (u *User) GenerateReport() string {\n    // lógica de geração de relatório\n    return "report"\n}\n

Exemplo bom (respeitando o SRP):

type User struct {\n    Name  string\n    Email string\n}\n\ntype UserRepository struct{}\n\nfunc (r *UserRepository) Save(u *User) error {\n    // apenas salvar\n    return nil\n}\n\ntype EmailService struct{}\n\nfunc (s *EmailService) SendWelcome(u *User) error {\n    // apenas enviar e-mail\n    return nil\n}\n\ntype ReportGenerator struct{}\n\nfunc (g *ReportGenerator) Generate(u *User) string {\n    // apenas gerar relatório\n    return "report"\n}\n

Conclusão: Cada struct é responsável por sua tarefa. Alterar a lógica de salvamento não afetará o envio de e-mails.

2. Open-Closed Principle (OCP) — Princípio do Aberto/Fechado

Essência: Entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação. Ou seja, você deve ser capaz de adicionar novas funcionalidades sem alterar o código existente.

Em Go, isso é perfeitamente implementado por meio de interfaces.

Exemplo ruim (violação do OCP):

type PaymentProcessor struct{}\n\nfunc (p *PaymentProcessor) Process(paymentType string, amount float64) {\n    if paymentType == "credit_card" {\n        // lógica para cartão de crédito\n    } else if paymentType == "paypal" {\n        // lógica para PayPal\n    }\n    // ao adicionar um novo tipo, será necessário alterar este método\n}\n

Exemplo bom (respeitando o OCP):

type PaymentMethod interface {\n    Pay(amount float64) error\n}\n\ntype CreditCard struct{}\n\nfunc (c *CreditCard) Pay(amount float64) error {\n    // lógica para cartão de crédito\n    return nil\n}\n\ntype PayPal struct{}\n\nfunc (p *PayPal) Pay(amount float64) error {\n    // lógica para PayPal\n    return nil\n}\n\nfunc ProcessPayment(method PaymentMethod, amount float64) error {\n    return method.Pay(amount)\n}\n

Conclusão: Agora, para adicionar um novo método de pagamento (por exemplo, ApplePay), basta criar uma nova struct com o método Pay(), sem tocar no código existente.

3. Liskov Substitution Principle (LSP) — Princípio da Substituição de Barbara Liskov

Essência: Os objetos em um programa devem ser substituíveis por instâncias de seus subtipos sem alterar a correção da execução do programa. Em Go, isso significa que, se uma função aceita uma interface, qualquer implementação dessa interface deve funcionar corretamente, sem quebrar as expectativas.

Exemplo ruim (violação do LSP):

type Bird interface {\n    Fly() error\n}\n\nt