Concepts

SOLID est un acronyme qui représente cinq principes fondamentaux de la programmation orientée objet, proposés par Robert C. Martin - Oncle Bob. Ici vous pouvez en savoir plus sur son article.
Ces principes visent à améliorer la structure et la maintenance du code, le rendant plus flexible, évolutif et plus facile à comprendre.

Ces principes aident le programmeur à créer des codes plus organisés, en répartissant les responsabilités, en réduisant les dépendances, en simplifiant le processus de refactoring et en favorisant la réutilisation du code.

Le « S » dans l'acronyme signifie « Principe de responsabilité unique ». La phrase utilisée par Oncle Bob pour définir ce principe était :

"Une classe doit avoir une et une seule raison de changer."

Selon ce principe, lorsque nous développons nos classes, nous devons garder à l'esprit leurs fonctionnalités particulières. Si une classe traite deux fonctionnalités, la meilleure chose à faire est de la diviser.
Lors de l'apprentissage de la programmation orientée objet, il est courant d'attribuer plusieurs responsabilités à une seule classe, créant ainsi ce que l'on appelle les classes divines. Même si cette approche semble efficace au premier abord, elle mélange les responsabilités, ce qui rend difficile de changer l'une sans impacter les autres.

Application pratique

Pour illustrer une application pratique de ce problème, je vais créer une classe appelée UserService. Il répondra à divers besoins liés aux utilisateurs.

Tout d'abord, examinons l'application de cette classe sans utiliser le principe de responsabilité unique. Ici, notre classe fait plusieurs choses : manipule les données utilisateur, valide ces données et crée des utilisateurs dans la base de données.

Java

import java.util.ArrayList;
import java.util.List;

class User {
    private int id;
    private String name;
    private String email;

    public User(int id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    @Override
    public String toString() {
        return "User{id="   id   ", name='"   name   "', email='"   email   "'}";
    }
}

class UserService {
    private List users = new ArrayList();

    public void addUser(String name, String email) {
        if (this.validateEmail(email)) {
            User newUser = new User(users.size()   1, name, email);
            users.add(newUser);
            saveToDatabase(newUser);
        } else {
            throw new IllegalArgumentException("E-mail inválido");
        }
    }

    private boolean validateEmail(String email) {
        return email.matches("\\S @\\S \\.\\S ");
    }

    private void saveToDatabase(User user) {
        System.out.println("Salvando usuário no banco de dados "   user);
    }

    public List getUsers() {
        return users;
    }

    public static void main(String[] args) {
        UserService userService = new UserService();
        userService.addUser("John Doe", "[email protected]");
        System.out.println(userService.getUsers());
    }
}

Manuscrit

type User = { id: number, name: string, email: string }

class UserService {
    private users: User[] = [];

    addUser(name: string, email: string) {
        if (this.validateEmail(email)) {
            const newUser = {
                id: this.users.length   1,
                name: name,
                email: email
            };
            this.users.push(newUser);
            this.saveToDatabase(newUser);
        } else {
            throw new Error("E-mail inválido");
        }
    }

    private validateEmail(email: string): boolean {
        const emailRegex = /\S @\S \.\S /;
        return emailRegex.test(email);
    }

    private saveToDatabase(user: User) {
        console.log("Salvando usuário no banco de dados", user);
    }

    getUsers() {
        return this.users;
    }
}

Le principal problème que nous pouvons trouver ici est la maintenance du code. S'il y a un changement dans la logique de validation ou dans la manière dont les données sont enregistrées, cela affectera directement cette classe, ce qui la rendra difficile à maintenir.

Maintenant, comment pouvons-nous résoudre ce problème ?
Nous devons séparer notre logique contenue dans la God Class « UserService » en plusieurs classes aux fonctionnalités bien définies. Voyons:

Java

import java.util.ArrayList;
import java.util.List;

// validador
class EmailValidator {
    public boolean validate(String email) {
        return email.matches("\\S @\\S \\.\\S ");
    }
}

// Repositório que manipula os dados no banco de dados
class UserRepository {
    private List users = new ArrayList();

    public void save(User user) {
        System.out.println("Salvando usuário no banco de dados "   user);
        users.add(user);
    }

    public List getAll() {
        return users;
    }
}

// Aplicamos as regras do domain com injeção de dependências
class UserService {
    private EmailValidator emailValidator;
    private UserRepository userRepository;

    public UserService(EmailValidator emailValidator, UserRepository userRepository) {
        this.emailValidator = emailValidator;
        this.userRepository = userRepository;
    }

    public void addUser(String name, String email) {
        if (emailValidator.validate(email)) {
            User newUser = new User(userRepository.getAll().size()   1, name, email);
            userRepository.save(newUser);
        } else {
            throw new IllegalArgumentException("E-mail inválido");
        }
    }

    public List getUsers() {
        return userRepository.getAll();
    }
}

Manuscrit

// validador
class EmailValidator {
    validate(email: string): boolean {
        const emailRegex = /\S @\S \.\S /;
        return emailRegex.test(email);
    }
}

// Repositório que manipula os dados no banco de dados
class UserRepository {
    private users: { id: number, name: string, email: string }[] = [];

    save(user: { id: number, name: string, email: string }) {
        console.log("Salvando usuário no banco de dados", user);
        this.users.push(user);
    }
    getAll() {
        return this.users;
    }
}

// Aplicamos as regras do domain com injeção de dependências
class UserService {
    constructor(
        private emailValidator: EmailValidator,
        private userRepository: UserRepository
    ) {}

    addUser(name: string, email: string) {
        if (this.emailValidator.validate(email)) {
            const newUser = {
                id: this.userRepository.getAll().length   1,
                name: name,
                email: email
            };
            this.userRepository.save(newUser);
        } else {
            throw new Error("E-mail inválido");
        }
    }

    getUsers() {
        return this.userRepository.getAll();
    }
}

L'application du principe de responsabilité unique est cruciale pour créer un logiciel robuste et évolutif. En garantissant que chaque classe n'a qu'une seule responsabilité, nous réduisons la complexité du code, facilitons la maintenance et la refactorisation et minimisons le risque d'erreurs. Ce principe est fondamental pour maintenir la qualité et la longévité du projet, en favorisant une conception plus propre et plus efficace.