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:

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 !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bug

[Programmez!] La chasse aux champignons

Cet article a été écrit pour et publié initialement dans le magazine Programmez! J’entends souvent que le test c’est compliqué, qu’il est difficile d’avoir une vision d’ensemble ou tout simplement de le présenter avec un exemple compréhensible par un enfant de 6 ans. En fait, comprendre les principes des activités

Lire la suite »
Automatisation

Vite Automatisons…

L’automatisation… c’est un beau mot n’est-ce pas? C’est la course à l’automatisation aujourd’hui, les profils et les annonces se déchaînent sur cette nouvelle tendance, les entreprises n’ont que ça en bouche… automatisons, automatisons…Mais attention.. Comme les mots tendances et à la mode dans le passé, tel que Agilité, Digital…il faut

Lire la suite »