Prinzipien von SOLID in GoLang – Single Responsability Principle (SRP)

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

• Änderungen tolerieren
• Seien Sie leicht verständlich
• 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) Single-Responsibility-Prinzip: „Ein Modul darf nur einen Grund haben, sich zu ändern“
(Das) 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 im Alltag 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 verschiedenen Problemen führen, wie zum Beispiel:

• Schwierig 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 Hauptaufgabe zu tun hat, die darin besteht, die zu speichern Daten in der Datenbank.
• Schwierigkeit beim Testen: 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 der Veröffentlichung von Benutzerdaten in einer RabbitMQ-Warteschlange ist völlig unabhängig von der Logik der Speicherung dieser Daten in einer Datenbank. Die Vermischung dieser beiden Verantwortlichkeiten auf die gleiche Weise führt zu unnötiger Kopplung.

Im folgenden Code haben wir die Struktur geändert, um die SRP zu berücksichtigen. Schau es dir an:

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 den 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 außerdem 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 es notwendig sein, die Kommunikationsform zu ändern, wechseln Sie einfach den Herausgeber.

Es ist erwähnenswert, dass es einen subtilen Unterschied zwischen der Ausführung zweier verschiedener Aufgaben und der Delegierung ihrer Ausführung gibt. Im ursprünglichen userService.Create-Beispiel wurden zwei Vorgänge an einem Ort ausgeführt, was einen Verstoß gegen das Prinzip der Einzelverantwortung darstellt. 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 Dependency Inversion Principle (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 einzelnen davon ausführlicher erklären, mit konkreten Beispielen.

Bis später, Leute!

Referenzen:
SOLID: Die ersten 5 Prinzipien des objektorientierten Designs
Clean Coder Blog – Das Prinzip der Einzelverantwortung

Das obige ist der detaillierte Inhalt vonPrinzipien von SOLID in GoLang – Single Responsability Principle (SRP). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!