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 *

ISO 25010

Types de tests (ISO 25 010): Les tests de portabilité (8/8)

Aujourd’hui nous abordons une famille que j’affectionne particulièrement car elle fait écho à mes expériences mobiles mais aussi à mon statut de joueur de jeux vidéo. Cette famille qui est aussi la dernière famille définissant la qualité au sens ISO – 25 010 est la famille  des tests de «

Lire la suite »
conférence

Test Bash Home : une réussite internationale

Vous connaissez surement le Ministry of testing, qui regroupe la plus large communauté de testeurs à travers le monde. Et chaque année, plusieurs événements tests, appelés Test Bash, ont lieu un peu partout dans le monde. Comme vous le savez, un certain virus a décidé de faire de cette année

Lire la suite »
Image représentant le test et de nombreux éléments liés
Avenir

Sondage: Quel futur pour le test ? – 2021

Il y a 3 ans je proposais un sondage dans lequel je vous demandais, quels étaient, selon vous les 3 axes principaux de développement du test sur les 10 prochains années. Je vous propose cette année de nouveau ce même sondage afin d’avoir des résultats à jour mais aussi être

Lire la suite »