Helfen Sie, das Prinzip der einfachen Verantwortlichkeit zu verstehen

Question

Ich versuche zu verstehen, was eine Verantwortlichkeit eigentlich ist, also möchte ich ein Beispiel für etwas verwenden, an dem ich gerade arbeite. Ich habe eine App, die Produktinformationen von einem System in ein anderes System importiert. Der Benutzer der Apps kann verschiedene Einstellungen für die Produktfelder in einem System auswählen, die im anderen System verwendet werden sollen.

Also habe ich eine Klasse, sagen ProductImporter und es ist Aufgabe, Produkte zu importieren. Diese Klasse ist groß, wahrscheinlich zu groß.

Die Methoden in dieser Klasse sind komplex und würden zum Beispiel getDescription sein. Bei dieser Methode wird nicht einfach eine Beschreibung vom anderen System abgerufen, sondern eine Produktbeschreibung basierend auf verschiedenen vom Benutzer festgelegten Einstellungen erstellt. Wenn ich eine Einstellung und eine neue Möglichkeit hinzufügen würde, um eine Beschreibung zu erhalten, könnte sich diese Klasse ändern.

Also, sind das zwei Verantwortlichkeiten? Gibt es eines, das Produkte importiert und eines, das eine Beschreibung erhält? Es scheint so, fast jede Methode, die ich habe, wäre in einer eigenen Klasse und das scheint übertrieben zu sein.

Ich brauche wirklich eine gute Beschreibung dieses Prinzips, denn es ist schwer für mich, es komplett zu verstehen. Ich will keine unnötige Komplexität.

Answer 1

Die "Verantwortung" ist in diesem Grundsatz als ein Grund zur Veränderung definiert. In diesem Fall wäre die einzige Verantwortung Ihrer Klasse, Produkte zu importieren. Wenn sich die Art des Produktimports ändert, sollte sich die Klasse ändern.

Die Absicht ist zu vermeiden, dass verschiedene Dinge die gleiche Klasse zur gleichen Zeit ändern. Wenn Ihre Produktimporteurs-Klasse beispielsweise auch das Ausgabeformat definiert, hat sie zwei Verantwortlichkeiten. Das Ausgabeformat ist wahrscheinlich völlig unabhängig vom Mechanismus des Datenimports.

Nun, dass die Klasse riesig ist und dass getDescription() auch eine Beschreibung setzt, ist keine direkte Verletzung der SRP, sondern von verschiedenen Prinzipien. Nämlich, dass Sie große Klassen vermeiden sollten (zeigt einen Mangel an Design) und jede Methode sollte eine einzige Sache tun (was eine konkretere Version der SRP wäre.)