In der Softwareentwicklung Objektorientiertes Design spielt eine entscheidende Rolle, wenn es darum geht, flexiblen, skalierbaren, wartbaren und wiederverwendbaren Code zu schreiben. Die Verwendung von OOD bietet viele Vorteile, aber jeder Entwickler sollte auch das SOLID-Prinzip für gutes objektorientiertes Design in der Programmierung kennen. Das SOLID-Prinzip wurde von Robert C. Martin, auch bekannt als Uncle Bob, eingeführt und ist ein Codierungsstandard in der Programmierung. Dieses Prinzip ist ein Akronym der fünf unten aufgeführten Prinzipien:

• Prinzip der Einzelverantwortung (SRP)
• Offen/Geschlossen-Prinzip
• Liskovs Substitutionsprinzip (LSP)
• Prinzip der Schnittstellentrennung (ISP)
• Abhängigkeitsinversionsprinzip (DIP)

Das SOLID-Prinzip hilft bei der Reduzierung der engen Kopplung. Enge Kopplung bedeutet, dass eine Gruppe von Klassen stark voneinander abhängig ist, was Sie in Ihrem Code vermeiden sollten.

• Das Gegenteil der engen Kopplung ist die lose Kopplung, und Ihr Code gilt als guter Code, wenn er über lose gekoppelte Klassen verfügt.
• Lose gekoppelte Klassen minimieren Änderungen in Ihrem Code und tragen dazu bei, den Code wiederverwendbar, wartbar, flexibler und stabiler zu machen. Lassen Sie uns nun diese Prinzipien einzeln besprechen …

1. Prinzip der Einzelverantwortung

Dieses Prinzip besagt das Eine Klasse sollte nur einen Grund haben, sich zu ändern Das bedeutet, dass jede Klasse eine einzige Verantwortung, eine einzige Aufgabe oder einen einzigen Zweck haben sollte. Mit anderen Worten: Eine Klasse sollte innerhalb des Softwaresystems nur eine Aufgabe oder einen einzigen Zweck haben.

obj in Java

Lassen Sie uns das Prinzip der Einzelverantwortung anhand eines Beispiels verstehen:

Stellen Sie sich einen Bäcker vor, der für das Brotbacken verantwortlich ist. Die Rolle des Bäckers besteht darin, sich auf die Aufgabe des Brotbackens zu konzentrieren und sicherzustellen, dass das Brot von hoher Qualität ist, richtig gebacken ist und den Standards der Bäckerei entspricht.

• Wenn der Bäcker jedoch auch für die Verwaltung des Inventars, die Bestellung von Vorräten, die Bedienung der Kunden und die Reinigung der Bäckerei verantwortlich ist, würde dies gegen die SRP verstoßen.
• Jede dieser Aufgaben stellt eine eigene Verantwortung dar, und durch deren Kombination könnte die Konzentration und Effektivität des Bäckers beim Brotbacken beeinträchtigt werden.
• Um die SRP einzuhalten, könnte die Bäckerei verschiedenen Personen oder Teams unterschiedliche Rollen zuweisen. Beispielsweise könnte es eine separate Person oder ein separates Team geben, die für die Verwaltung des Inventars verantwortlich sind, eine andere für die Bestellung von Vorräten, eine andere für die Bedienung der Kunden und eine weitere für die Reinigung der Bäckerei.

2. Offen/Geschlossen-Prinzip

Dieses Prinzip besagt das Softwareeinheiten (Klassen, Module, Funktionen usw.) sollten für Erweiterungen offen, für Änderungen jedoch geschlossen sein Das heißt, Sie sollten in der Lage sein, ein Klassenverhalten zu erweitern, ohne es zu ändern.

Lassen Sie uns das Offen/Geschlossen-Prinzip anhand eines Beispiels verstehen:

svm

Stellen Sie sich vor, Sie haben eine Klasse namensPaymentProcessor>das Zahlungen für einen Online-Shop abwickelt. Zunächst diePaymentProcessor>Die Klasse unterstützt nur die Verarbeitung von Zahlungen mit Kreditkarten. Sie möchten die Funktionalität jedoch erweitern, um auch die Abwicklung von Zahlungen über PayPal zu unterstützen.

Anstatt das Bestehende zu verändernPaymentProcessor>Um die PayPal-Unterstützung hinzuzufügen, können Sie eine neue Klasse mit dem Namen erstellenPayPalPaymentProcessor>das erweitert diePaymentProcessor>Klasse. Auf diese Weise wird diePaymentProcessor>Die Klasse bleibt für Änderungen geschlossen, aber für Erweiterungen offen, wobei das Open-Closed-Prinzip eingehalten wird

3. Liskovs Substitutionsprinzip

Das Prinzip wurde 1987 von Barbara Liskov eingeführt und basiert auf diesem Prinzip Abgeleitete oder untergeordnete Klassen müssen ihre Basis- oder übergeordneten Klassen ersetzen können . Dieses Prinzip stellt sicher, dass jede Klasse, die das Kind einer Elternklasse ist, anstelle ihrer Elternklasse verwendet werden kann, ohne dass es zu unerwartetem Verhalten kommt.

Lassen Sie uns das Substitutionsprinzip von Liskov anhand eines Beispiels verstehen:

if-else Java

Ein klassisches Beispiel für dieses Prinzip ist ein Rechteck mit vier Seiten. Die Höhe eines Rechtecks ​​kann einen beliebigen Wert und die Breite einen beliebigen Wert haben. Ein Quadrat ist ein Rechteck mit gleicher Breite und Höhe. Wir können also sagen, dass wir die Eigenschaften der Rechteckklasse auf die Quadratklasse erweitern können.

Dazu müssen Sie die untergeordnete Klasse (Quadrat) mit der übergeordneten Klasse (Rechteck) austauschen, um der Definition eines Quadrats mit vier gleichen Seiten zu entsprechen. Eine abgeleitete Klasse hat jedoch keinen Einfluss auf das Verhalten der übergeordneten Klasse, wenn Sie dies also tun dass es gegen das Liskov-Substitutionsprinzip verstößt.

4. Prinzip der Schnittstellentrennung

Dieses Prinzip ist das erste Prinzip, das in SOLID für Schnittstellen anstelle von Klassen gilt, und ähnelt dem Prinzip der Einzelverantwortung. Es sagt, dass Zwingen Sie keinen Client dazu, eine Schnittstelle zu implementieren, die für ihn irrelevant ist . Hier besteht Ihr Hauptziel darin, sich auf die Vermeidung fetter Schnittstellen zu konzentrieren und vielen kleinen kundenspezifischen Schnittstellen den Vorzug zu geben. Sie sollten viele Clientschnittstellen einer allgemeinen Schnittstelle vorziehen und jede Schnittstelle sollte eine bestimmte Verantwortung haben.

Lassen Sie uns das Prinzip der Schnittstellentrennung anhand eines Beispiels verstehen:

Angenommen, Sie betreten ein Restaurant und sind reiner Vegetarier. Der Kellner in diesem Restaurant gab Ihnen die Menükarte mit vegetarischen, nicht-vegetarischen Speisen, Getränken und Süßigkeiten.

Arten von Tests

• In diesem Fall sollten Sie als Kunde eine Speisekarte haben, die nur vegetarische Gerichte enthält und nicht alles, was Sie nicht in Ihrem Essen essen. Hier sollte das Menü für verschiedene Kundentypen unterschiedlich sein.
• Die gemeinsame oder allgemeine Menükarte für alle kann statt nur einer in mehrere Karten aufgeteilt werden. Die Verwendung dieses Prinzips trägt dazu bei, die Nebenwirkungen und die Häufigkeit erforderlicher Änderungen zu reduzieren.

5. Abhängigkeitsinversionsprinzip

Das Dependency Inversion Principle (DIP) ist ein Prinzip im objektorientierten Design, das dies besagt High-Level-Module sollten nicht von Low-Level-Modulen abhängig sein. Beide sollten auf Abstraktionen beruhen . Darüber hinaus sollten Abstraktionen nicht von Details abhängen. Details sollten von Abstraktionen abhängen.

• Einfacher ausgedrückt schlägt das DIP vor, dass Klassen auf Abstraktionen (z. B. Schnittstellen oder abstrakte Klassen) und nicht auf konkreten Implementierungen basieren sollten.
• Dies ermöglicht einen flexibleren und entkoppelten Code, wodurch es einfacher wird, Implementierungen zu ändern, ohne andere Teile der Codebasis zu beeinträchtigen.

Lassen Sie uns das Prinzip der Abhängigkeitsumkehr anhand eines Beispiels verstehen:

In einem Softwareentwicklungsteam sind Entwickler auf ein abstraktes Versionskontrollsystem (z. B. Git) angewiesen, um Änderungen an der Codebasis zu verwalten und zu verfolgen. Sie hängen nicht von spezifischen Details der internen Funktionsweise von Git ab.

Dadurch können sich Entwickler auf das Schreiben von Code konzentrieren, ohne die Feinheiten der Versionskontrollimplementierung verstehen zu müssen.