OK, setzt IComparable und andere Schnittstellen (Like IDisposable) auf einer einzigen Klasse eine Verletzung des SRP Prinzip.SOLID, SRP, IComparable
SRP besagt, dass jede Klasse eine signle responsability und Methoden implementieren sollten sollten in hohem Maße miteinander verbunden werdenzusammenhängende Klassen zu erreichen.
Ist ein Vergleich keine andere Verantwortung?
Einige Erläuterungen würden geschätzt.
Wenn ich Sie wäre, würde ich versuchen, SRP einzuhalten, aber nicht so streng, wie die Anstrengung schließlich kontraproduktiv wird. So, jetzt mit dem gesagt, was sollten Sie tun? Entweder implementieren Sie IComparable und haben den Vergleich vollständig im Objekt gekapselt, oder Sie haben einen separaten Vergleicher und implementieren die Vergleichslogik darin. Zum Vergleich: Wenn der Vergleich relativ einfach ist und keinen Änderungen unterworfen sein sollte, würde ich IComparable implementieren und damit fertig sein. Wenn Sie einige Änderungen in der Zukunft vernünftigerweise vorhersehen können, oder wenn der Vergleich anwendungsfallabhängig ist, würde ich die Vergleichsroute gehen. Das ultimative Ziel ist es, geschlossene Komponenten zu entwickeln und sie durch Zusammensetzen zu kooperieren. Wenn sich der Vergleich also kaum ändert, kann die Komponente geschlossen werden und Sie werden nicht mehr davon hören. Sie könnten auch die Verwendung von IComparable in Ihrem Code kommentieren, und wenn sich in der Zukunft etwas ändert, wechseln Sie zum Composing mit einem Komparator, da die Änderung, die angeblich nicht stattgefunden hat, tatsächlich stattgefunden hat.
Vielen Dank, also sollte die Einhaltung dieser Prinzipien nicht so streng sein. Es hängt von der Situation ab . Was ist mit Vergleich für Entitäten? –
SOLID ist ein Werkzeug, kein Mittel zum Zweck. Außerdem haben Sie oft die Wahl zwischen Strenge und Nachsicht. Sie können nicht alle Änderungen vorhersehen und Sie sollten es auch einfach halten. Meiner bescheidenen Meinung nach würde eine strikte SRP dazu führen, dass du die Dinge überproduzierst. Was die Entitäten betrifft, wenn du unter Entitäten persistente Objekte verstehst, gilt das, was ich zuvor geschrieben habe. Es hängt von der Ähnlichkeit der Änderung und der Abhängigkeit von einigen Anwendungsfällen ab - und Sie werden in der Zukunft verschiedene Anwendungsfälle mit unterschiedlichen Vergleichen für dieselbe Entität haben. –
Ich würde argumentieren, dass die Implementationen von IComparable und IDisposable nicht Verantwortlichkeiten überhaupt sind, und daher SRP nicht verletzen würde.
Im Zusammenhang mit SRP liegt die Verantwortung für einen Interaktor Ihres Systems (d. H. Einen Benutzer, eine Rolle oder ein externes System). Wenn Ihr System über ein Geschäftsanforderungsdokument verfügt, sollten alle Verantwortlichkeiten zumindest innerhalb der funktionalen oder nicht funktionalen Anforderungen abgeleitet werden. Wenn nicht, fragen Sie sich, welcher Geschäftsinhaber Sie bitten wird, zu ändern, wie sich ein Objekt verhält.
Beim ersten Projekt, an dem ich nach dem Lernen über SRC arbeitete, interpretierten wir es als "eine öffentliche Methode pro Klasse" und wendeten es als harte Regel an. Während das es leicht machte, in "Compliance" zu bleiben, hatten wir am Ende Code, der viel komplizierter war, als er sein musste.
Wenn Ihre IComparable/IDisposable-Implementierungen geändert werden müssen, wird diese Änderung durch den funktionalen (geschäftlichen) Teil Ihrer Klasse gesteuert, der ebenfalls geändert werden muss (zur gleichen Zeit und für denselben Grund).
Wie wäre es dann mit ISP? Sowohl SRP als auch ISP sind Teil von SOLID und sollten daher nicht in Konflikt stehen. –