Konzepte

SOLID ist ein Akronym, das fünf grundlegende Prinzipien der objektorientierten Programmierung darstellt, vorgeschlagen von Robert C. Martin – Onkel Bob. Hier können Sie mehr über seinen Artikel lesen.
Diese Prinzipien zielen darauf ab, die Struktur und Wartung des Codes zu verbessern und ihn flexibler, skalierbarer und verständlicher zu machen.

Diese Prinzipien helfen dem Programmierer, besser organisierte Codes zu erstellen, Verantwortlichkeiten aufzuteilen, Abhängigkeiten zu reduzieren, den Refactoring-Prozess zu vereinfachen und die Wiederverwendung von Code zu fördern.

Das „S“ im Akronym steht für „Single Responsibility Principle“. Der Ausdruck, mit dem Onkel Bob dieses Prinzip definierte, war:

"Eine Klasse muss einen und nur einen Grund haben, sich zu ändern."

Nach diesem Prinzip müssen wir bei der Entwicklung unserer Klassen deren besondere Funktionalität im Auge behalten. Wenn eine Klasse zwei Funktionalitäten behandelt, ist es am besten, sie aufzuteilen.
Beim Erlernen der objektorientierten Programmierung ist es üblich, einer einzelnen Klasse mehrere Verantwortlichkeiten zuzuweisen, wodurch sogenannte Gottklassen erstellt werden. Obwohl dieser Ansatz zunächst effizient erscheint, vermischt er die Verantwortlichkeiten, sodass es schwierig ist, einen zu ändern, ohne Auswirkungen auf die anderen zu haben.

Praktische Anwendung

Um eine praktische Anwendung dieses Problems zu veranschaulichen, werde ich eine Klasse namens UserService erstellen. Es wird verschiedene Benutzeranforderungen erfüllen.

Schauen wir uns zunächst die Anwendung dieser Klasse an, ohne das Prinzip der Einzelverantwortung zu verwenden. Hier macht unsere Klasse mehrere Dinge: Sie manipuliert Benutzerdaten, validiert diese Daten und erstellt Benutzer in der Datenbank.

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());
    }
}

Typoskript

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;
    }
}

Das Hauptproblem, das wir hier finden können, ist die Codewartung. Wenn sich die Validierungslogik oder die Art und Weise der Datenspeicherung ändert, wirkt sich dies direkt auf diese Klasse aus und erschwert deren Wartung.

Wie können wir das nun lösen?
Wir müssen unsere in der Gottesklasse „UserService“ enthaltene Logik in mehrere Klassen mit genau definierten Funktionalitäten aufteilen. Mal sehen:

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();
    }
}

Typoskript

// 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();
    }
}

Die Anwendung des Single-Responsibility-Prinzips ist entscheidend für die Erstellung robuster und skalierbarer Software. Indem wir sicherstellen, dass jede Klasse nur eine Verantwortung hat, reduzieren wir die Codekomplexität, erleichtern Wartung und Refactoring und minimieren das Fehlerrisiko. Dieses Prinzip ist von grundlegender Bedeutung für die Aufrechterhaltung der Qualität und Langlebigkeit des Projekts und fördert ein saubereres und effizienteres Design.