Wenn ein Objekt seine eigene Eingabe analysiert, wird es als Verletzung von SRP angesehen?

Question

Wenn ein Objekt seine eigene Eingabe parst, wird es als Verletzung von SRP angesehen?

Zum Beispiel

class A 
{ 
    int x; 
    string y; 
    float f; 
    A(string x, string y, string f) 
    { 
     this.x = int.Parse(x); 
     if (this.x < 0 || this.x > 10) 
     { 
      throw new ArgumentOutOfRangeException(); 
     } 
     this.y = y; 
     this.f = float.Parse(f); 
    } 
} 

oder einen privaten Konstruktor und eine öffentliche statische Methode verwenden, und prüft den Eingang analysiert und Rück A.

Anstatt eine int, string und float übergeben und analysieren und prüfen, ob sie woanders gültig sind.

Answer 1

Ist das Prinzip der Einzelverantwortung gebrochen? Nein, in dem Beispiel, das Sie primitive Typen analysieren, um ein grundlegendes Objekt zu konstruieren, fühle ich in dem Beispielcode, den Sie gegeben haben, nicht, dass es eine eigene Verantwortung ist. SRP ist einfacher zu erklären, wenn eine Geschäftsdomäne innerhalb von ...

Um zu erarbeiten, arbeitet Parsing, wie oben verwendet, an primitiven Datentypen, das eingebaute Parsing auf primitiven Typen dient dazu, die Umwandlung eines primitiven Typs in einen anderen zu erleichtern . Der Zweck von SRP besteht nicht darin, diese Kernfunktionalität zu abstrahieren, sondern sicherzustellen, dass das Design Ihres Codes eine einzige Verantwortung trägt. Wenn Sie zum Beispiel einen Datensatz in der Datenbank speichern, könnten Sie eine Funktion schreiben, die die Rohdaten aufnimmt, sie den verschiedenen Tabellen zuordnet und eine E-Mail sendet, um den Eintrag zu bestätigen, was SRP bricht. Wie vermeiden wir das in einem solchen Beispiel? Verwenden Sie Dinge wie das Repository-Muster, um die Datenbank zu abstrahieren, indem Sie eine separate Klasse für die Verwaltung der E-Mail-Kommunikation haben, vielleicht mithilfe der Abhängigkeitsinjektion, um sicherzustellen, dass diese Komponenten in Ihrer Lösung problemlos austauschbar sind. Würde ich ernsthaft versuchen, das grundlegende Parsing von primitiven Typen zu abstrahieren?

Absolut nicht.

Untermauert das ganze Konzept ist der "Grund zu ändern", wenn Ihr Code-Design hat mehr als einen Grund, es würde ändern müssen, bricht es SRP. Im Beispiel, wenn die E-Mail geändert wurde, oder die Rohdaten oder die Zuordnung zu verschiedenen Tabellen, müssten wir den Code ändern, aus 3 verschiedenen Gründen.

Der Konstruktor oder die Funktionen sollten idealerweise den richtigen Typ akzeptieren. Es gibt möglicherweise Gründe dafür, warum Sie dies nicht tun können. Sie sollten jedoch das Parsen vermeiden, wenn Sie die Werte im richtigen Typ angeben können.

Eine letzte Sache hinzuzufügen: Ich habe gesehen, dass viele Entwickler auf Probleme wie diese in Bezug auf primitive Typen, Parsing und Konstruieren von Objekten hängen und versuchen, sicherzustellen, dass keine Designprinzipien gebrochen werden, wie SRP. Sie haben Stunden damit verbracht, akribisch auf Probleme zu achten, und haben dadurch viel größere Domain-Design-Probleme verpasst. Stellen Sie sicher, dass Sie das Gesamtbild sehen und Ihre Anwendungsarchitektur nicht aus den Augen verlieren. Ich schlage nicht vor, dass Sie sich über solche Dinge nie Sorgen machen, fallen Sie einfach nicht in die Falle, die größeren Probleme beim Entwerfen Ihrer Anwendungen zu verpassen.

Answer 2

Wenn wir zustimmen, dass das Parsen eine Verantwortung ist (weil es eine Änderungsachse für das Datenformat einführt), dann ist die einzige Frage, ob class A eine andere Verantwortung hat. Wenn class A über zusätzliche Logik verfügt, die nichts mit dem Parsen zu tun hat, würde dies auf eine andere Verantwortung hinweisen.

Es ist interessant zu beachten, dass class A bereits seine Eingabe analysiert und validiert. Die Validierung kann eine zweite Änderungsachse sein, die sich auf die Geschäftsanforderungen bezieht. Verstößt dies gegen SRP? Das hängt davon ab, wie wahrscheinlich es ist, dass diese beiden Achsen unabhängig voneinander variieren.