In der Welt der Softwareentwicklung sagen uns die SOLID-Prinzipien, wie wir Funktionen und Daten so organisieren, dass unsere Codes:

• Änderungen tolerieren
• Leicht verständlich sein
• Seien Sie die Basis von Komponenten, die in vielen Softwaresystemen verwendet werden können

Der Begriff SOLID ist ein Akronym für fünf Designpostulate, die im Folgenden beschrieben werden:

(S) Prinzip der Einzelverantwortung: „Ein Modul darf nur einen Grund zur Änderung haben“
(O) Offen/Geschlossen-Prinzip: „Ein Softwareartefakt muss zur Erweiterung offen, aber zur Änderung geschlossen sein“
(L) Liskov-Substitutionsprinzip: „Eine abgeleitete Klasse muss durch ihre Basisklasse ersetzbar sein“
(I) Prinzip der Schnittstellentrennung: „Eine Klasse sollte nicht gezwungen werden, Schnittstellen und Methoden zu implementieren, die sie nicht verwenden wird“
(D) Abhängigkeitsinversionsprinzip: „Abhängig von Abstraktionen und nicht von Implementierungen“

SOLID und GoLang

SOLID ist für die objektorientierte Programmierung konzipiert, und es ist bekannt, dass GoLang keine Sprache ist, die dieses Paradigma übernimmt. Wir können jedoch die bereitgestellten Ressourcen nutzen, um die OOP-Methodik zu erfüllen. Go bietet beispielsweise keine Vererbungsunterstützung, aber die Idee kann durch die Kompositionsunterstützung kompensiert werden. Ebenso kann eine Art Polymorphismus mithilfe von Schnittstellen erstellt werden.

In diesem Artikel, dem ersten einer Reihe von 5, möchte ich das erste Prinzip anhand von Beispielen näher erläutern, die Situationen ähneln, denen wir täglich begegnen.

Prinzip der Einzelverantwortung (SRP)

Wir wissen bereits, was der Begriff bedeutet, jetzt ist es an der Zeit zu lernen, wie man ihn in GoLang implementiert.
In dieser Sprache könnten wir dieses Prinzip als „Eine Funktion oder ein Typ darf nur eine Aufgabe und nur eine Verantwortung haben“ definieren. Sehen wir uns den folgenden Code an:

Oben haben wir eine Struktur, die wir userService nennen. Es verfügt über zwei Eigenschaften: db, das für die Kommunikation mit einer relationalen Datenbank verantwortlich ist, und amqpChannel, das die Kommunikation mit dem RabbitMQ-Nachrichtendienst ermöglicht.

UserService implementiert eine Methode namens Create. Bei dieser Methode speichern wir die erhaltenen Benutzerinformationen in der Datenbank und veröffentlichen die Daten dann in RabbitMQ.
Es ist ersichtlich, dass die Create-Methode im userService nicht nur eine, sondern zwei Aufgaben hat: das Speichern von Informationen in der Datenbank und das Veröffentlichen einer Nachricht in einer RabbitMQ-Warteschlange.

Dies kann zu mehreren Problemen führen, wie zum Beispiel:

• Schwer zu warten: Wenn sich eine der Anforderungen ändert, z. B. die Art und Weise, wie Benutzerdaten serialisiert werden, müssen Sie die Logik der Create-Methode ändern, auch wenn dies nichts mit Ihrer Hauptverantwortung zu tun hat Speichern Sie die Daten in der Datenbank.
• Testschwierigkeit: Da die Create-Methode zwei verschiedene Verantwortlichkeiten hat, müssen Sie für jede davon Tests erstellen, was schwierig und mühsam sein kann.
• Unnötige Kopplung: Die Logik zum Veröffentlichen von Benutzerdaten in einer RabbitMQ-Warteschlange ist völlig unabhängig von der Logik zum Speichern dieser Daten in einer Datenbank. Die Vermischung dieser beiden Verantwortlichkeiten auf die gleiche Weise führt zu unnötiger Kopplung.

Im folgenden Code ändern wir die Struktur, um das SRP zu berücksichtigen. Hör zu:

Beachten Sie, dass wir die Verantwortlichkeiten in drei verschiedene Teile unterteilt haben: das Repository UserRepository, um den Benutzer in der Datenbank beizubehalten, den Herausgeber UserPublisher, um eine Nachricht an RabbitMQ zu senden, und das Dienst UserService, der diese beiden Vorgänge orchestriert.

Auf diese Weise ist jede Komponente für eine spezifische und unabhängige Aufgabe verantwortlich, was die Wartung und Weiterentwicklung des Codes erleichtert und darüber hinaus ermöglicht, dass jeder dieser Teile ersetzt oder verbessert wird, ohne die anderen zu beeinträchtigen. Sollte es beispielsweise notwendig sein, die verwendete Datenbank zu ändern, tauschen Sie einfach das Repository aus. Sollte eine Änderung der Kommunikationsform erforderlich sein, wechseln Sie einfach den Herausgeber.

Es ist erwähnenswert, dass es einen subtilen Unterschied zwischen der Ausführung zweier unterschiedlicher Aufgaben und der Delegierung ihrer Ausführung gibt. Im ursprünglichen Beispiel von userService.Create wurden zwei Vorgänge an einem Ort ausgeführt, was gegen das Prinzip der Einzelverantwortung verstößt. Nach dem Refactoring haben wir Ausführungen an verschiedene Strukturen delegiert und die Create-Methode war nur für die Koordinierung dieses Ablaufs verantwortlich.

Um SRP in diesem Beispiel anzuwenden, haben wir letztendlich auch einige der anderen SOLID-Prinzipien implementiert:

• Das Interface Segregation Principle (ISP): Jede Schnittstelle repräsentiert eine einzelne Verantwortung. Sowohl UserRepository als auch UserPublisher sind Schnittstellen, die nur eine Methode haben, die jeweils eine einzelne Verantwortung darstellen.
• Das Abhängigkeitsinversionsprinzip (DIP): Die userService-Struktur hängt von Abstraktionen (Schnittstellen) und nicht von konkreten Implementierungen ab, das heißt, sie kennt nicht die spezifische Implementierung von UserRepository und UserPublisher, sondern nur die Schnittstellen, die sie implementieren.
• Das Open/Closed-Prinzip (OCP): Der Code ist offen für Erweiterungen, da neue Repositories oder Herausgeber einfach hinzugefügt werden können, ohne den userService zu ändern.

In den nächsten Artikeln dieser Reihe werde ich jeden von ihnen ausführlicher erklären, mit konkreten Beispielen.

Bis später, Leute!

Verweise:
SOLID: Die ersten 5 Prinzipien des objektorientierten Designs
Clean Coder Blog – Das Single-Responsibility-Prinzip