Bei der Softwareentwicklung sind Codepflege, Erweiterung und Flexibilität wichtig für den langfristigen Erfolg eines Projekts. Die SOLID-Prinzipien wurden formuliert, um Entwicklern dabei zu helfen, Code zu erstellen, der leichter zu verstehen, zu ändern und zu erweitern ist. In diesem Artikel werden wir über jedes der fünf SOLID-Prinzipien und deren Verwendung anhand praktischer Beispiele in Java sprechen.

1. Prinzip der Einzelverantwortung

Das Single-Responsibility-Prinzip (SRP) legt fest, dass eine Klasse nur einen Grund zur Änderung haben darf, das heißt, sie muss eine einzige Verantwortung innerhalb des Systems haben.

// Antes de aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }

    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

// Após aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }
}

class EmailService {
    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

Im Beispiel trennen wir die Verantwortung für das Speichern eines Produkts in der Datenbank von der Verantwortung für den Versand von E-Mails über das Produkt. Dies erleichtert zukünftige Änderungen, da Änderungen beim E-Mail-Versand keinen Einfluss mehr auf die Produktspeicherlogik haben.

2. Offen/Geschlossen-Prinzip

Das Open/Closed-Prinzip (OCP) schlägt vor, dass Softwareeinheiten (Klassen, Module, Funktionen usw.) für Erweiterungen offen, für Änderungen jedoch geschlossen sein sollten. Dies wird durch die Verwendung von Abstraktionen und Vererbung erreicht.

// Exemplo inicial violando o OCP
class AreaCalculator {
    public double calculateArea(Rectangle[] rectangles) {
        double area = 0;
        for (Rectangle rectangle : rectangles) {
            area  = rectangle.width * rectangle.height;
        }
        return area;
    }
}

// Exemplo após aplicar o OCP
interface Forma {
    double calculateArea();
}
class Rectangle implements Forma {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    @Override
    public double calculateArea() {
        return width * height;
    }
}

class AreaCalculator {
    public double calculateArea(Forma [] formas) {
        double area = 0;
        for (Forma formas: formas) {
            area  = forma.calculateArea();
        }
        return area;
    }
}

In diesem zweiten Beispiel war die AreaCalculator-Klasse zunächst direkt von der Rechteck-Klasse abhängig. Das bedeutet, dass Sie, wenn Sie einen anderen Formtyp hinzufügen möchten, beispielsweise einen Kreis oder ein Dreieck, die Klasse „AreaCalculator“ ändern müssten, was einen Verstoß gegen OCP darstellt. Mit der Erstellung der Shape-Schnittstelle ist die AreaCalculator-Klasse in der Lage, neue geometrische Formen zu empfangen, ohne den vorhandenen Code zu ändern.

3. Liskov-Substitutionsprinzip

Das Liskov-Substitutionsprinzip (LSP) besagt, dass Objekte einer Oberklasse durch Objekte ihrer Unterklassen ersetzbar sein müssen, ohne die Integrität des Systems zu beeinträchtigen. Mit anderen Worten, das Verhalten von Unterklassen muss mit dem Verhalten von Oberklassen konsistent sein.

// Classe base
class Bird {
    public void fly() {
        // Método padrão que imprime "Flying"
        System.out.println("Flying");
    }
}

// Classe derivada que viola o LSP
class Duck extends Bird {
    @Override
    public void fly() {
        // Sobrescrita que imprime "Ducks cannot fly"
        System.out.println("Ducks cannot fly");
    }
}

Problem: Die Duck-Klasse überschreibt die Methode fly(), um „Enten können nicht fliegen“ auszugeben, und ändert damit das in der Bird-Basisklasse definierte Standardverhalten, das besagt, dass alle Vögel fliegen („Fliegen“). Dies verstößt gegen LSP, da jeder Code, der erwartet, dass ein Bird-Objekt oder seine Unterklassen fliegen, nicht ordnungsgemäß mit einem Duck funktioniert, von dem wir bereits wissen, dass er nicht fliegt.

// Classe derivada que respeita o LSP
interface Bird {
    void fly();
}
class Eagle implements Bird {
    @Override
    public void fly() {
        System.out.println("Flying like an Eagle");
    }
}
class Duck implements Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ducks cannot fly");
    }
}

Mit diesem Ansatz können Eagle und Duck dort austauschbar sein, wo ein Bird erwartet wird, ohne die von der Bird-Schnittstelle gesetzten Erwartungen zu verletzen. Die von Duck ausgelöste Ausnahme teilt explizit mit, dass Enten nicht fliegen, ohne das Verhalten der Superklasse auf eine Weise zu ändern, die zu unerwarteten Problemen im Code führen könnte.

4. Prinzip der Schnittstellentrennung

Das Interface Segregation Principle (ISP) legt nahe, dass die Schnittstellen einer Klasse spezifisch für die Clients sein sollten, die sie verwenden. Dadurch werden „fette“ Schnittstellen vermieden, die Implementierungen von Methoden erfordern, die nicht von Clients verwendet werden.

// Exemplo antes de aplicar o ISP
interface Worker {
    void work();
    void eat();
    void sleep();
}

class Programmer implements Worker {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

// Exemplo após aplicar o ISP
interface Worker {
    void work();
}
interface Eater {
    void eat();
}
interface Sleeper {
    void sleep();
}
class Programmer implements Worker, Eater, Sleeper {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

Im Beispiel haben wir die Worker-Schnittstelle in kleinere Schnittstellen (Work, Eat, Sleep) aufgeteilt, um sicherzustellen, dass die Klassen, die sie implementieren, nur über die Methoden verfügen, die sie benötigen. Dadurch wird verhindert, dass Klassen Methoden implementieren müssen, die für sie nicht relevant sind, was die Klarheit und Kohäsion des Codes verbessert.

5. Abhängigkeitsinversionsprinzip

Das Dependency Inversion Principle (DIP) schlägt vor, dass High-Level-Module (z. B. Geschäfts- oder Anwendungsklassen, die die wichtigsten Geschäftsregeln implementieren) nicht von Low-Level-Modulen (Infrastrukturklassen, z. B. Zugriff auf externe Daten usw.) abhängen sollten Dienste, die Operationen auf hoher Ebene unterstützen). Beide müssen von Abstraktionen abhängen.

// Exemplo antes de aplicar o DIP
class BackendDeveloper {
    public void writeJava() {
        // Lógica para escrever em Java
    }
}
class Project {
    private BackendDeveloper developer;

    public Project() {
        this.developer = new BackendDeveloper();
    }
    public void implement() {
        developer.writeJava();
    }
}

// Exemplo após aplicar o DIP
interface Developer {
    void develop();
}
class BackendDeveloper implements Developer {
    @Override
    public void develop() {
        // Lógica para escrever em Java
    }
}
class Project {
    private Developer developer;

    public Project(Developer developer) {
        this.developer = developer;
    }
    public void implement() {
        developer.develop();
    }
}

Die Project-Klasse hängt jetzt von einer Abstraktion (Developer) statt einer konkreten Implementierung (BackendDeveloper) ab. Dadurch können verschiedene Arten von Entwicklern (z. B. FrontendDeveloper, MobileDeveloper) problemlos in die Project-Klasse eingefügt werden, ohne deren Code zu ändern.

Abschluss

Die Übernahme der SOLID-Prinzipien steigert nicht nur die Qualität Ihres Codes, sondern stärkt auch Ihre technischen Fähigkeiten, erhöht Ihre Arbeitseffizienz und fördert Ihren Karriereweg als Softwareentwickler.