Das Thema entwickelt ja langsam eine echte Dynamik
Um es mal vorweg zu schicken, da ich das immer in Verbindung mit diesem Thema (Test- und wartbarer Code) sage:
Es geht nicht um den Selbstzweck, sondern da steckt immer hinter, dass man etwas am Code ändert oder ihn in einer gewissen Form schreibt,
damit er test- und wartbar bleibt. Mit testbar ist hier nicht gemeint, dass ich hinterher 10 Minuten durch die Anwendung klicke bis ich an der Stelle bin, die mich eigentlich interessiert und eventuell noch nen Server und Datenbank aufsetzen muss dafür mit speziellen Daten. Sondern es geht um Unitests. Bei diesen teste ich isoliert ein bestimmtes Modul (meist eine Klasse) ohne externe Abhängigkeiten. Und wenn dann an meiner Klasse noch wie ein riesiges Wurzelwerk noch meine halbe Anwendung dran hängt, ist das große Sch....
Schöne Code Beispiele - da sie auf verschiedenen Ebenen einige Fehler aufzeigen.
Erster Fall. Die Aktion soll überprüfen, ob sie ausgeführt werden darf oder nicht.
Was hat damit ein Benutzer zu tun? Also neben der globalen Abhängigkeit noch eine LoD Verletzung, die es noch schlimmer macht.
Um das Teil zu testen muss ich nicht nur irgendwie den globalen User bei einem Test austauschen sondern dem Benutzer auch noch entsprechende Berechtigungen verpassen oder die IsGranted Funktion ausmocken, damit sie mir das erwartete Ergebnis mitteilt.
Übrigens wurde auch noch das SRP verletzt, denn die Aufgabe meiner Klasse ist nicht die Rechteüberprüfung sondern höchstwahrscheinlich irgendwas anders.
Zweiter Fall, die Kopplung an die
GUI - hier sollte man sich überlegen, was genau von meinem Code benötigt
GUI Interaktion. Wahrscheinlich habe ich irgendetwas, was durch
GUI ausgelöst wird und was Meldungen zurück liefert. Aber auch in diesem Fall ist das die eine Aufgabe dieser Einheit: das Zwischenspiel von
GUI und Programmlogik. Wenn ich nunmal die
VCL verwende, dann ist es auch nicht böse, in einer solchen Klasse,
VCL Elemente zu benutzen. Aber bitte nicht in der Programmlogik, die erstmal nix mit
GUI am Hut hat.
D.h. der dritte Fall ergibt sich oft gar nicht, da man für diese
GUI-Interaktionsklasse an die entsprechende
GUI anpasst. Hier gibt es so viele Möglichkeiten, dass ich nur einfach mal die Begriffe MVP, MVC oder MVVM in den Raum werfe (die zu diskutieren wäre wohl eher ein eigener Thread).
Wenn dann die Anforderungen so implementiert werden, wie du es mit dem Logging, Reporting und Speichern in der Datenbank skizzierst, würde ich mir ernsthaft erneut Gedanken über die Verletzung des SRP machen. Zumindest Persistenz lässt sich prima in eine eigene Klasse zum Speichern auslagern. Logging schreit meist nach AOP, was wir in Delphi aber nicht so nativ haben, wie andere Sprachen. Hier handelt es sich eher um eine optionale Abhängigkeit, die man durchaus per Property Injection angeben kann. Und auch die ReportEngine muss hier wohl kaum mit angegeben werden, wohlmöglich kann man ein irgendwie geartetes Ergebnis der Aktion an das Dingen weitergeben. Deshalb braucht aber die Klasse an sich noch keine Abhängigkeit auf das Teil.
Oft resultieren also augenscheinlich Probleme, denen man sich konfrontiert sieht, und denen man mit Verletzungen von irgendwelchen Prinzipien entgegnen "muss" aus vorrausgehenden Verletzungen dieser oder anderer Prinzipien. Aber wie schon eingangs gesagt, man muss immer abwägen, was erreicht man und welchen Aufwand hat man.
Da
imho jede sauber designte Klasse gut (ohne Mocks) testbar ist
Wohl kaum. Denn Mocks werden für die Abhängigkeiten dieser Klasse benutzt. D.h. wenn du keine Mocks brauchst, hast du entweder eine Klasse, die autarg ist, also keine Interaktion jedweder Art mit dem umliegenden Programm durchführt, oder du hast ein Riesenproblem, weil sie das über irgendwelche "
spooky actions at a distance" im Hintergrund macht.