Verstößt dieses Klassendesign gegen das Prinzip der Einzelverantwortung?

63

Heute hatte ich einen Streit mit jemandem.

Ich habe die Vorteile eines Rich-Domain-Modells im Vergleich zu einem anämischen Domain-Modell erläutert. Und ich habe meinen Standpunkt mit einer einfachen Klasse demonstriert, die so aussieht:

public class Employee
{
    public Employee(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastname;
    }

    public string FirstName { get private set; }
    public string LastName { get; private set;}
    public int CountPaidDaysOffGranted { get; private set;}

    public void AddPaidDaysOffGranted(int numberOfdays)
    {
        // Do stuff
    }
}

Als er seinen anämischen Modellansatz verteidigte, lautete eines seiner Argumente: "Ich glaube an SOLID . Sie verletzen das Prinzip der einmaligen Verantwortung ( Single Responsibility Principle, SRP), da Sie sowohl Daten repräsentieren als auch Logik in derselben Klasse ausführen."

Ich fand diese Behauptung wirklich überraschend, da nach dieser Überlegung jede Klasse mit einer Eigenschaft und einer Methode die SRP verletzt und daher OOP im Allgemeinen nicht SOLID ist und funktionale Programmierung der einzige Weg zum Himmel ist.

Ich habe beschlossen, nicht auf seine vielen Argumente zu antworten, aber ich bin gespannt, was die Community zu dieser Frage denkt.

Wenn ich geantwortet hätte, hätte ich zunächst auf das oben erwähnte Paradox hingewiesen und dann darauf hingewiesen, dass die SRP in hohem Maße von der zu berücksichtigenden Granularität abhängt und dass, wenn Sie weit genug gehen, jede Klasse mehr als eine Klasse enthält Eigentum oder eine Methode verstößt dagegen.

Was hättest du gesagt?

Update: Das Beispiel wurde von guntbert großzügig aktualisiert, um die Methode realistischer zu gestalten und uns zu helfen, uns auf die zugrunde liegende Diskussion zu konzentrieren.

tobiak777
quelle
19
diese Klasse gegen SRP nicht , weil es Daten mit Logik mischt, sondern weil es hat eine geringe Kohäsion - Potential Gott Objekt
gnat
1
Welchen Zweck hat das Hinzufügen von Feiertagen zum Mitarbeiter? Es sollte vielleicht eine Kalenderklasse geben oder etwas, das die Feiertage hat. Ich denke dein Freund hat recht.
James Black
9
Hören Sie niemals jemandem zu, der sagt "Ich glaube an X".
Stig Hemmer
29
Es ist nicht so sehr, ob dies eine Verletzung der SRP ist, als vielmehr, ob es überhaupt eine gute Modellierung ist. Angenommen, ich bin ein Angestellter. Wenn ich meinen Manager frage, ob es für ihn in Ordnung ist, wenn ich ein langes Wochenende zum Skifahren nehme, fügt mein Manager mir keine Feiertage hinzu . Der Code hier entspricht nicht der Realität, die modelliert werden soll, und ist daher verdächtig.
Eric Lippert
2
+1 für funktionale Programmierung ist der einzige Weg zum Himmel.
Erip

Antworten:

68

Die Einzelverantwortung ist als Abstraktion logischer Aufgaben in Ihrem System zu verstehen. Eine Klasse sollte die alleinige Verantwortung haben, (alles Notwendige zu tun, um) eine einzige spezifische Aufgabe auszuführen. Dies kann tatsächlich eine Menge in eine gut gestaltete Klasse bringen, abhängig von der Verantwortung. Die Klasse, in der Ihre Skript-Engine ausgeführt wird, kann beispielsweise eine Vielzahl von Methoden und Daten für die Verarbeitung von Skripten enthalten.

Ihr Mitarbeiter konzentriert sich auf das Falsche. Die Frage ist nicht "Welche Mitglieder hat diese Klasse?" aber "welche nützlichen Operationen führt diese Klasse innerhalb des Programms aus?" Sobald dies verstanden ist, sieht Ihr Domain-Modell gut aus.

Mason Wheeler
quelle
Wenn Objektorientierte Programmierung erstellt und sollte die realen Objekte und Klassen (Aktionen + Attribute) modellieren , dann schreiben , warum nicht den Code der Klasse mit mehreren Aufgaben (Aktionen)? Ein Objekt der realen Welt kann mehrere Verantwortlichkeiten haben. Zum Beispiel schreibt ein Journalist Leitartikel in Zeitungen und interviewt Politiker in einer Fernsehshow. Zwei Verantwortlichkeiten für ein reales Objekt! Was ist, wenn ich einen Klassenjournalisten schreibe?
user1451111
41

Das Prinzip der Einzelverantwortung befasst sich nur mit der Frage, ob ein Teil des Codes (in OOP sprechen wir normalerweise von Klassen) für einen Teil der Funktionalität verantwortlich ist . Ich denke, Ihr Freund, der sagt, dass sich Funktionen und Daten nicht miteinander vermischen können, hat diese Idee nicht wirklich verstanden. Wenn Employeeer auch Informationen über seinen Arbeitsplatz, die Geschwindigkeit seines Autos und die Art des Futters, das sein Hund isst, enthalten würde, hätten wir ein Problem.

Da es in dieser Klasse nur um eine Employeegeht, ist es fair zu sagen, dass die SRP nicht offenkundig verletzt wird, aber die Leute werden immer ihre eigene Meinung haben.

Ein Ort, an dem wir uns verbessern könnten, ist die Trennung von Mitarbeiterinformationen (wie Name, Telefonnummer, E-Mail) von seinem Urlaub. Meiner Meinung nach bedeutet dies nicht, dass Methoden und Daten nicht miteinander vermischt werden können , sondern nur, dass sich die Urlaubsfunktionalität möglicherweise an einem anderen Ort befindet.

Frank Bryce
quelle
20

Meiner Meinung nach könnte diese Klasse möglicherweise SRP verletzen, wenn sie weiterhin sowohl ein Employeeals auch darstellt EmployeeHolidays.

So wie es ist, und wenn es für Peer Review zu mir käme, würde ich es wahrscheinlich durchlassen. Wenn mehr mitarbeiterspezifische Eigenschaften und Methoden hinzugefügt würden und mehr ferienspezifische Eigenschaften hinzugefügt würden, würde ich wahrscheinlich eine Aufteilung unter Berufung auf SRP und ISP empfehlen.

NikolaiDante
quelle
Genau. Wenn der Code so einfach ist wie hier angegeben, würde ich ihn wahrscheinlich verschieben lassen. Meiner Meinung nach sollte ich jedoch nicht in der Verantwortung des Mitarbeiters liegen, seinen Urlaub selbst zu regeln. Es scheint keine große Sache zu sein, wo die Verantwortung liegt, aber sehen Sie es so: Wenn Sie neu in der Codebasis wären und an der urlaubsspezifischen Funktionalität arbeiten müssten - wo würden Sie zuerst suchen? Für die Feiertagslogik würde ich mich zunächst NICHT mit der Entität Employee befassen.
Niklas H
1
@ NiklasH Einverstanden. Ich persönlich würde nicht nach dem Zufallsprinzip schauen und versuchen, die Klasse zu erraten. Ich würde mit dem Studio nach dem Wort "Holiday" suchen und sehen, in welchen Klassen es stattfand. :)
NikolaiDante
4
Wahr. Was aber, wenn es in diesem neuen System nicht "Urlaub" heißt, sondern "Urlaub" oder "Freizeit". Aber ich bin damit einverstanden, dass Sie normalerweise nur danach suchen oder einen Kollegen fragen können. Mein Kommentar war in erster Linie, das OP dazu zu bringen, die Verantwortung mental zu modellieren und wo der naheliegendste Ort für die Logik wäre :-)
Niklas H
Ich stimme Ihrer ersten Aussage zu. Wenn es jedoch zu einem Peer Review kommt, glaube ich nicht, dass dies der Fall ist, da ein Verstoß gegen die SRP ein rutschiger Hang ist und dies die erste von vielen zerbrochenen Fenstern sein könnte. Prost.
Jim Speaker
20

Es gibt bereits gute Antworten, die darauf hinweisen, dass SRP ein abstraktes Konzept für logische Funktionalität ist, aber es gibt subtilere Punkte, die meines Erachtens hinzugefügt werden sollten.

In den ersten beiden Buchstaben in SOLID, SRP und OCP wird beschrieben, wie sich Ihr Code als Reaktion auf eine Änderung der Anforderungen ändert. Meine Lieblingsdefinition der SRP lautet: "Ein Modul / eine Klasse / eine Funktion sollte nur einen Grund haben, sich zu ändern." Über wahrscheinliche Gründe für eine Änderung Ihres Codes zu streiten, ist viel produktiver als darüber zu streiten, ob Ihr Code SOLID ist oder nicht.

Wie viele Gründe muss Ihre Mitarbeiterklasse ändern? Ich weiß es nicht, weil ich den Kontext nicht kenne, in dem Sie es verwenden, und ich kann auch die Zukunft nicht sehen. Was ich tun kann, ist ein Brainstorming möglicher Änderungen basierend auf dem, was ich in der Vergangenheit gesehen habe, und Sie können subjektiv bewerten, wie wahrscheinlich sie sind. Wenn mehr als ein Punkt zwischen "einigermaßen wahrscheinlich" und "Mein Code hat sich genau aus diesem Grund bereits geändert" liegt, verstoßen Sie gegen die SRP gegen diese Art von Änderung. Hier ist eines: Jemand mit mehr als zwei Namen tritt Ihrem Unternehmen bei (oder ein Architekt liest diesen ausgezeichneten W3C-Artikel ). Und noch etwas: Ihr Unternehmen ändert die Zuordnung von Feiertagen.

Beachten Sie, dass diese Gründe auch dann gültig sind, wenn Sie die AddHolidays-Methode entfernen. Viele anämische Domänenmodelle verletzen die SRP. Viele von ihnen sind nur Datenbanktabellen im Code, und es kommt häufig vor, dass Datenbanktabellen mehr als 20 Änderungsgründe haben.

Hier ist etwas zu kauen: Würde sich Ihre Mitarbeiterklasse ändern, wenn Ihr System die Gehälter der Mitarbeiter nachverfolgen müsste? Adressen? Notfall-Kontaktinformationen? Wenn Sie zwei davon mit "Ja" (und "wahrscheinlich") bestätigen würden, würde Ihre Klasse die SRP verletzen, selbst wenn sie noch keinen Code enthält! Bei SOLID geht es sowohl um Prozesse und Architektur als auch um Code.

Carl Leth
quelle
9

Dass die Klasse Daten darstellt, liegt nicht in der Verantwortung der Klasse, sondern in einem privaten Implementierungsdetail.

Die Klasse hat eine Verantwortung, einen Arbeitnehmer zu vertreten. In diesem Zusammenhang bedeutet dies, dass eine öffentliche API bereitgestellt wird, die Ihnen Funktionen bietet, die Sie für den Umgang mit Mitarbeitern benötigen (ob AddHolidays ein gutes Beispiel ist, ist umstritten).

Die Implementierung ist intern; es kommt also vor, dass dies einige private Variablen und eine Logik benötigt. Das bedeutet nicht, dass die Klasse jetzt mehrere Verantwortlichkeiten hat.

RemcoGerlich
quelle
Interessante Linie des Denkens, vielen Dank für das Teilen
tobiak777
Nizza - Gute Möglichkeit, die beabsichtigten Ziele von OOP auszudrücken.
user949300
5

Die Idee, dass das Mischen von Logik und Daten in irgendeiner Weise immer falsch ist, ist so lächerlich, dass es nicht einmal einer Diskussion wert ist. In diesem Beispiel liegt zwar eine eindeutige Verletzung der Einzelverantwortung vor, aber nicht daran, dass es eine Eigenschaft DaysOfHolidaysund eine Funktion gibt AddHolidays(int).

Das liegt daran, dass sich die Identität des Mitarbeiters mit dem Urlaubsmanagement vermischt, was schlecht ist. Die Identität des Mitarbeiters ist eine komplexe Sache, die erforderlich ist, um Urlaub, Gehalt, Überstunden nachzuverfolgen, um darzustellen, wer zu welchem ​​Team gehört, um sich mit Leistungsberichten zu verknüpfen usw. Ein Mitarbeiter kann auch den Vor- und Nachnamen oder beides ändern und dabei gleich bleiben Mitarbeiter. Mitarbeiter können sogar mehrere Schreibweisen ihres Namens haben, z. B. eine ASCII- und eine Unicode-Schreibweise. Personen können 0 bis n Vor- und / oder Nachnamen haben. Sie können in verschiedenen Gerichtsbarkeiten unterschiedliche Namen haben. Das Nachverfolgen der Identität eines Mitarbeiters ist eine ausreichende Verantwortung, sodass das Ferien- oder Urlaubsmanagement nicht hinzugefügt werden kann, ohne es als zweite Verantwortung zu bezeichnen.

Peter
quelle
"Die Verfolgung der Identität eines Mitarbeiters reicht aus, um Ferien- oder Urlaubsmanagement zu ergänzen, ohne es als zweite Verantwortung zu bezeichnen." + Der Mitarbeiter kann mehrere Namen usw. haben. Der Sinn eines Modells besteht darin, sich auf die relevanten Fakten der realen Welt für das jeweilige Problem zu konzentrieren. Es gibt Anforderungen, für die dieses Modell optimal ist. Unter diesen Bedingungen sind Mitarbeiter nur insoweit interessant, als wir ihre Urlaubstage ändern können, und wir sind nicht allzu sehr daran interessiert, andere Aspekte ihrer tatsächlichen Besonderheiten zu berücksichtigen.
tobiak777
@reddy "Mitarbeiter sind nur insofern interessant, als wir ihren Urlaub ändern können" - das heißt, Sie müssen sie korrekt identifizieren. Sobald Sie einen Mitarbeiter haben, kann dieser seinen Nachnamen aufgrund von Eheschließung oder Scheidung jederzeit ändern. Sie können auch ihren Namen und ihr Geschlecht ändern. Werden Sie Mitarbeiter entlassen, wenn sich ihr Nachname so ändert, dass ihr Name mit dem eines anderen Mitarbeiters übereinstimmt? Sie werden im Moment nicht alle Funktionen hinzufügen. Stattdessen werden Sie es hinzufügen, wenn Sie es brauchen, was gut ist. Unabhängig davon, wie viel implementiert wird, bleibt die Verantwortung für die Identifizierung gleich.
Peter
3

"Ich glaube an SOLID. Sie verletzen das Prinzip der einmaligen Verantwortung (Single Responsibility Principle, SRP), da Sie beide Daten repräsentieren und Logik in derselben Klasse ausführen."

Wie die anderen stimme ich dem nicht zu.

Ich würde sagen, dass die SRP verletzt wird, wenn Sie mehr als eine Logik in der Klasse ausführen . Wie viele Daten in der Klasse gespeichert werden müssen, um diese einzelne Logik zu erreichen, ist irrelevant.

Leichtigkeit Rennen mit Monica
quelle
Nein! SRP wird nicht durch mehrere Logikelemente, mehrere Datenelemente oder eine Kombination aus beiden verletzt. Die einzige Voraussetzung ist, dass das Objekt seinen Zweck erfüllt. Sein Zweck kann möglicherweise viele Operationen mit sich bringen.
Martin Maat
@MartinMaat: Viele Operationen, ja. Ein Stück Logik als Ergebnis. Ich denke, wir sagen dasselbe, aber mit unterschiedlichen Begriffen (und ich bin froh anzunehmen, dass Ihre die richtigen sind, da ich diese Dinge nicht oft studiere)
Lightness Races mit Monica
2

Ich finde es heutzutage nicht sinnvoll, darüber zu diskutieren, was eine einzige Verantwortung oder einen einzigen Grund für eine Änderung darstellt oder nicht. Ich würde an seiner Stelle ein Minimum-Trauer-Prinzip vorschlagen:

Prinzip der minimalen Trauer: Code sollte entweder versuchen, die Wahrscheinlichkeit zu minimieren, dass Änderungen erforderlich sind, oder den Änderungskomfort maximieren.

Wie ist das? Ein Raketenwissenschaftler sollte nicht herausfinden, warum dies zur Senkung der Wartungskosten beitragen kann, und hoffentlich sollte es kein endloser Streitpunkt sein, aber wie bei SOLID im Allgemeinen ist es nicht überall blind anzuwenden. Es ist etwas zu beachten, während Kompromisse ausgeglichen werden.

Die Wahrscheinlichkeit, dass Änderungen erforderlich sind, hängt mit folgenden Faktoren zusammen:

  1. Gute Prüfung (verbesserte Zuverlässigkeit).
  2. Bezieht sich nur auf das Nötigste, um etwas Bestimmtes zu tun (dies kann das Reduzieren afferenter Kopplungen einschließen).
  3. Machen Sie den Code einfach zu dem, was er tut (siehe Make Badass Principle).

Die Schwierigkeit, Änderungen vorzunehmen, geht mit efferenten Kupplungen einher. Das Testen führt zu efferenten Kupplungen, verbessert jedoch die Zuverlässigkeit. Gut gemacht, tut es im Allgemeinen mehr gut als schaden und ist absolut akzeptabel und wird durch das Minimum Grief-Prinzip gefördert.

Make Badass-Prinzip: Klassen, die an vielen Orten verwendet werden, sollten fantastisch sein. Sie sollten zuverlässig und effizient sein, wenn dies mit ihrer Qualität zusammenhängt usw.

Und das Make-Badass-Prinzip ist an das Minimum-Grief-Prinzip gebunden, da Badass-Dinge mit geringerer Wahrscheinlichkeit Änderungen erfordern als Dinge, die an dem scheißen, was sie tun.

Ich hätte zunächst auf das oben erwähnte Paradox hingewiesen und dann darauf hingewiesen, dass die SRP in hohem Maße von der zu berücksichtigenden Granularität abhängt und dass eine Klasse, die mehr als eine Eigenschaft oder eine Methode enthält, einen Verstoß darstellt, wenn Sie weit genug gehen es.

Aus SRP-Sicht hätte eine Klasse, die kaum etwas tut, sicherlich nur einen (manchmal null) Änderungsgrund:

class Float
{
public:
    explicit Float(float val);
    float get() const;
    void set(float new_val);
};

Das hat praktisch keinen Grund, sich zu ändern! Es ist besser als SRP. Es ist ZRP!

Außer ich würde vorschlagen, dass es eine offensichtliche Verletzung des Make Badass Prinzips ist. Es ist auch absolut wertlos. Etwas, das so wenig bewirkt, kann nicht hoffentlich schlecht sein. Es hat zu wenig Informationen (TLI). Und natürlich, wenn Sie etwas haben, das TLI ist, kann es nichts wirklich Bedeutendes bewirken, auch nicht mit den darin enthaltenen Informationen, und es muss nach außen geleitet werden, in der Hoffnung, dass jemand anderes tatsächlich etwas Bedeutendes und Böses tut. Und diese Undichtigkeit ist in Ordnung für etwas, das nur dazu gedacht ist, Daten und nichts weiter zu aggregieren, aber diese Schwelle ist der Unterschied, den ich zwischen "Daten" und "Objekten" sehe.

Natürlich ist etwas, was TMI ist, auch schlecht. Wir könnten unsere gesamte Software in eine Klasse einteilen. Es kann sogar nur eine runMethode geben. Und jemand könnte sogar argumentieren, dass es jetzt einen sehr allgemeinen Grund für eine Änderung gibt: "Diese Klasse muss nur geändert werden, wenn die Software verbessert werden muss." Ich bin dumm, aber natürlich können wir uns alle Wartungsprobleme damit vorstellen.

Es gibt also einen Spagat in Bezug auf die Granularität oder Grobheit der von Ihnen entworfenen Objekte. Ich beurteile es oft daran, wie viele Informationen Sie an die Außenwelt weitergeben müssen und wie viele sinnvolle Funktionen sie ausführen können. Ich finde das Make-Badass-Prinzip oft hilfreich, um das Gleichgewicht zu finden und es mit dem Minimum-Grief-Prinzip zu kombinieren.


quelle
1

Im Gegenteil, für mich bricht das anämische Domänenmodell einige OOP-Hauptkonzepte (die Attribute und Verhalten miteinander verbinden), kann jedoch aufgrund der Architekturentscheidungen unvermeidlich sein. Anämische Domänen sind einfacher zu denken, weniger organisch und sequentieller.

Viele Systeme tendieren dazu, dies zu tun, wenn mehrere Ebenen mit denselben Daten spielen müssen (Service-Ebene, Web-Ebene, Client-Ebene, Agenten ...).

Es ist einfacher, die Datenstruktur an einer Stelle und das Verhalten in anderen Serviceklassen zu definieren. Wenn dieselbe Klasse auf mehreren Ebenen verwendet wurde, wird diese möglicherweise größer und es stellt sich die Frage, welche Ebene für die Definition des erforderlichen Verhaltens verantwortlich ist und wer die Methoden aufrufen kann.

Dies ist möglicherweise keine gute Idee, als dass ein Agent-Prozess, der Statistiken aller Ihrer Mitarbeiter erstellt, eine Berechnung für bezahlte Tage aufruft. Und die GUI für die Mitarbeiterliste benötigt sicherlich überhaupt nicht die neue aggregierte ID-Berechnung, die in diesem Statistikagenten verwendet wird (und die technischen Daten, die damit einhergehen). Wenn Sie die Methoden auf diese Weise trennen, enden Sie im Allgemeinen mit einer Klasse, die nur Datenstrukturen enthält.

Sie können die "Objekt" -Daten oder nur einige von ihnen oder ein anderes Format (json) zu einfach serialisieren / deserialisieren, ohne sich um ein Objektkonzept / eine Objektverantwortung sorgen zu müssen. Es geht aber nur um Datenübermittlung. Sie können jederzeit Daten zwischen zwei Klassen zuordnen (Employee, EmployeeVO, EmployeeStatistic…), aber was bedeutet Employee hier wirklich?

Also ja, es trennt Daten in Domänenklassen und Datenbehandlung in Serviceklassen vollständig, aber es wird hier benötigt. Ein solches System ist gleichzeitig ein funktionales System, um geschäftlichen Wert zu schaffen, und ein technisches System, um die Daten überall dort zu verbreiten, wo sie benötigt werden, wobei ein angemessener Verantwortungsbereich eingehalten wird (und das verteilte Objekt löst dies auch nicht).

Wenn Sie keine separaten Verhaltensbereiche benötigen, können Sie die Methoden in Abhängigkeit davon, wie Sie Ihr Objekt sehen, in Dienstklassen oder in Domänenklassen einordnen. Ich neige dazu, ein Objekt als das "echte" Konzept zu sehen, dies hilft natürlich, SRP zu halten. In Ihrem Beispiel ist dies realistischer, als wenn der Chef des Mitarbeiters seinem PayDayAccount einen freien Zahltag hinzufügt. Ein Mitarbeiter ist von einer Firma eingestellt worden, Works kann krank sein oder um Rat gefragt werden, und er hat ein Zahltagkonto (der Chef kann es direkt bei ihm oder in einem PayDayAccount-Register abrufen ...). Sie können jedoch eine aggregierte Verknüpfung erstellen Hier der Einfachheit halber, wenn Sie für eine einfache Software nicht zu viel Komplexität benötigen.

Vince
quelle
Vielen Dank für Ihre Eingabe Vince. Der Punkt ist, dass Sie keine Service-Schicht benötigen, wenn Sie eine reiche Domain haben. Es gibt nur eine Klasse, die für das Verhalten verantwortlich ist, und es ist Ihre Domänenentität. Die anderen Ebenen (Webebene, Benutzeroberfläche usw.) befassen sich normalerweise mit DTOs und ViewModels, und dies ist in Ordnung. Das Domänenmodell dient zum Modellieren der Domäne, nicht zum Ausführen von UI-Funktionen oder zum Senden von Nachrichten über das Internet. Ihre Nachricht spiegelt dieses verbreitete Missverständnis wider, das darauf zurückzuführen ist, dass die Leute einfach nicht wissen, wie sie OOP in ihr Design einpassen sollen. Und ich finde das sehr traurig - für sie.
tobiak777
Ich glaube nicht, dass ich ein falsches Verständnis von Rich Domain OOP habe. Ich habe viele Sotwares auf diese Weise entworfen und es ist wahr, dass es wirklich gut für Wartung / Evolution ist. Aber ich muss Ihnen leider sagen, dass dies keine Wunderwaffe ist.
Vince
Ich sage es nicht. Für das Schreiben eines Compilers ist dies wahrscheinlich nicht der Fall, aber für die meisten Branchen- / SaaS-Anwendungen ist es meiner Meinung nach viel weniger Kunst / Wissenschaft als von Ihnen vorgeschlagen. Die Notwendigkeit eines Domain-Modells kann mathematisch bewiesen werden. Ihre Beispiele lassen mich eher an
fragwürdige
0

Sie verstoßen gegen das Prinzip der einmaligen Verantwortung (SRP), da Sie sowohl Daten darstellen als auch Logik in derselben Klasse ausführen.

Das klingt für mich sehr vernünftig. Das Modell verfügt möglicherweise nicht über öffentliche Eigenschaften, wenn Aktionen verfügbar gemacht werden. Grundsätzlich handelt es sich um eine Idee zur Trennung von Befehlen und Abfragen. Bitte beachten Sie, dass Command mit Sicherheit einen privaten Status hat.

Dmitry Nogin
quelle
0

Sie können das Prinzip der Einzelverantwortung nicht verletzen, weil es nur ein ästhetisches Kriterium und keine Naturregel ist. Lassen Sie sich nicht durch den wissenschaftlich klingenden Namen und die Großbuchstaben irreführen.

ZunTzu
quelle
1
Dies ist kaum eine echte Antwort, aber als Kommentar zur Frage wäre es großartig gewesen.
Jay Elston