Principes SOLID en Go : guide avancé avec exemples

Principes SOLID en Go : niveau avancé

SOLID est un ensemble de cinq principes fondamentaux de conception orientée objet qui aident à créer un code flexible, maintenable et évolutif. Dans le contexte de Go, un langage avec une philosophie unique de composition plutôt que d'héritage, l'application de SOLID nécessite une approche particulière. Dans cet article, nous analyserons chaque principe à un niveau avancé, avec des exemples concrets et des anti-patrons caractéristiques de la communauté Go.

1. Single Responsibility Principle (SRP) en Go

Le principe de responsabilité unique stipule : une classe (structure) ne doit avoir qu'une seule raison de changer. En Go, cela est souvent violé dans les packages utilitaires et les "objets divins".

Anti-patron : structure avec de multiples responsabilités

type UserService struct {\n    db *sql.DB\n    cache *redis.Client\n    logger *log.Logger\n}\n\nfunc (s *UserService) CreateUser(ctx context.Context, u User) error {\n    // 1. Validation\n    // 2. Hachage du mot de passe\n    // 3. Sauvegarde en base de données\n    // 4. Envoi d'email\n    // 5. Journalisation\n    return nil\n}

Solution : divisez les responsabilités en services séparés et utilisez la composition.

type UserValidator interface {\n    Validate(u User) error\n}\n\ntype PasswordHasher interface {\n    Hash(password string) (string, error)\n}\n\ntype UserRepository interface {\n    Save(ctx context.Context, u User) error\n}\n\ntype EmailSender interface {\n    SendWelcomeEmail(ctx context.Context, email string) error\n}\n\ntype UserService struct {\n    validator   UserValidator\n    hasher      PasswordHasher\n    repo        UserRepository\n    emailSender EmailSender\n    logger      Logger\n}

Chaque composant a désormais une seule raison de changer, ce qui simplifie les tests et la maintenance.

2. Open-Closed Principle (OCP) via les interfaces

Le principe d'ouverture/fermeture : les entités doivent être ouvertes à l'extension, mais fermées à la modification. En Go, cela est réalisé via les interfaces et l'injection de dépendances.

Mauvais exemple : couplage fort

type PaymentProcessor struct {\n    paypalAPI *PayPalAPI\n}\n\nfunc (p *PaymentProcessor) Process(amount float64) error {\n    return p.paypalAPI.Charge(amount)\n}

Si vous devez ajouter Stripe, vous devrez modifier le code.

Approche correcte : interface + stratégie

type PaymentGateway interface {\n    Charge(amount float64) error\n    Refund(transactionID string) error\n}\n\ntype PayPalGateway struct{ /* ... */ }\ntype StripeGateway struct{ /* ... */ }\n\nfunc (p *PayPalGateway) Charge(amount float64) error { /* ... */ }\nfunc (s *StripeGateway) Charge(amount float64) error { /* ... */ }\n\ntype PaymentService struct {\n    gateway PaymentGateway\n}\n\nfunc NewPaymentService(gw PaymentGateway) *PaymentService {\n    return &PaymentService{gateway: gw}\n}

Vous pouvez désormais ajouter de nouvelles passerelles de paiement sans modifier PaymentService.

3. Liskov Substitution Principle (LSP) dans le contexte de Go

Le principe de substitution de Barbara Liskov : les objets d'un programme doivent être remplaçables par des instances de leurs sous-types sans altérer la correction du programme. En Go, où il n'y a pas d'héritage classique, le LSP se manifeste à travers les contrats d'interface.

Violation typique : interface avec des méthodes redondantes

type Bird interface {\n    Fly() error\n    Swim() error\n}\n\ntype Penguin struct{}\n\nfunc (p *Penguin) Fly() error {\n    return errors.New("penguins can't fly")\n}\n\nfunc (p *Penguin) Swim() error {\n    return nil\n}

Ici, Penguin ne peut pas implémenter correctement Fly(), ce qui viole le LSP.

Solution : séparation des interfaces

type Flyer interface {\n    Fly() error\n}\n\ntype Swimmer interface {\n    S