Principes SOLID simplifiés (1/5): Responsabilité unique

Les principes S.O.L.I.D dans un contexte d’automatisation des tests

L’acronyme S.O.L.I.D a été inventé par Michael Feathers à partir des principes de programmation orientée objet identifiés par Robert Cecil Martin, Ces principes visent à rendre le code plus lisible, facile à maintenir, extensible, réutilisable et sans répétition.

L’automatisation des tests c’est un vrai projet de développement et lorsque les principes S.O.L.I.D ne sont pas appliqués le code devient difficile à maintenir ou à faire évoluer.

Dans cet article, je vous propose une explication du principe Responsabilité unique (Single Responsibility)

N’hésitez pas a découvrir les autres principes SOLID dans cette série d’articles:

• OCP: Ouvert-Fermé
• LSP: Substitution de Liskov
• ISP: Ségrégation d’interface
• DIP: Inversion De Dépendance

Le principe de responsabilité unique stipule qu’une classe ne devrait avoir qu’une seule raison de changer et une seule responsabilité.

On comprend toujours mieux avec un exemple!

Un mauvais exemple:

public sealed class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public bool Active { get; set; }

    public void ActivateCustomer()
    {
        Active = true;
    }

    public void InactivateCustomer()
    {
        Active = false;
    }

    public void AddCustomer()
    {
        // Some implementation here (database) ...
    }

    public void DeleteCustomer()
    {
        // Some implementation here (database) ...
    }
}

Le code de l’exemple est incorrect car il a deux responsabilités, les règles de gestion et la persistance de la base de données.

Un bon exemple:

public sealed class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public bool Active { get; set; }

    public void ActivateCustomer()
    {
        Active = true;
    }
    public void InactivateCustomer()
    {
        Active = false;
    }
}

public sealed class CustomerRepository
{
    public void AddCustomer(Customer customer)
    {
        // Some implementation here (database) ...
    }

    public void DeleteCustomer(Customer customer)
    {
        // Some implementation here (database) ...
    }
}

Le code est correct car les responsabilités ont été réparties et chaque classe n’a qu’une seule raison de changer.

Si vous avez aimé cet article, n’hésitez pas à le partager !