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 !

Publié par

Tawfik Nouri

Je suis coach et formateur expert en automatisation de tests web, mobiles et IoT avec une double compétence développements et testing. N'hésitez pas à me contacter via mon linkedin: https://www.linkedin.com/in/tawfik-nouri/

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s