Zitat:
Um es mal vorweg zu schicken,
Genau Begriffe definieren/festklopfen.
1. Testbar = Unittests
2. Mock <> Fake (Mock=nachträgliches Ändern von Verhalten. Fake = Hilfsklasse, um Abhängigkeiten zu kontrollieren)
3. Wartbar = Änderungen ohne Seiteneffekte vornehmen.
4. Robust = Schrotteingaben => wohldefinierte Exceptions. "Keine Überraschungen"
5. Erweiterbar = Erweitern, ohne sich einen Wolf zu tippen.
zu 2. Ja, aber in beiden Fällen dienen diese
test doubles als Arsatz für Abhängigkeiten des
system under test. Da in diesem Zusammenhang immer von
mock objects bzw Mocking gesprochen wird, will ich gar nicht auf die Feinheiten zwischen Mock, Fake und Stub eingehen, die auch für diese Diskussion eher irrelevant sind. Fakt ist, man ersetzt das richtige Dings durch nen anderes Dings. Und damit man son Dings austauschen kann, muss man sie voneinander entkoppeln.
zu 4. robust eher im Sinne von wenn ich am Code an Stelle a etwas ändere krachts nicht an Stelle b, die auf der anderen Seite des Programms ist (geht auch ein bisschen Richtung Punkt 5)
zu 5. es geht nicht nur ums tippen sondern darum, dass man durch Erweiterungen nicht sein halbes System umstricken muss (Stichworte: OCP, LSP, ISP)
1. Soll das BO die Rechte prüfen? Normalerweise nicht, das macht ein Szenario. Aber wenn die Rechteabfrage systemimmanent ist, z.B. in einer Bank integraler Bestandteil der Aktion ist, dann schon (finde ich). Aber mit Sicherheit nicht so banal wie hier. Insofern => richtig, SRP verletzt.
Du hast mich falsch verstanden, ich sprach eher davon, in die Klassen etwas hineinzugeben, was dir für Aktion XY ja oder nein sagt und nicht hardcodiert auf den User zu gehen. Denn dann hast du ruckzuck die Logik, dass Rechte von Usern abhängen gekapselt, was dein BO nicht die Bohne interessiert. Der will nur wissen, ob er XY machen darf oder nich und nicht, wie er das ermitteln.
Zitat:
Die restlichen Abhängigkeiten.. Nun ja, klar. Da ich vielleicht doch einen "IoC-Container" habe, der das globale Gedöns schön verbirgt, sollte man das noch anständig herunterbrechen können. Nur muss ich mir dann meinen IoC-Container mocken/faken, was auch kein Zuckerschlecken ist.
Nein! Ich sag es oft und auch hier an dieser Stelle nochmal: ein IoC-Container ist keine Medizin für nicht optimalen code und er macht auch bei richtigem Einsatz (ja, auch einen IoC-Container kann man wunderbar falsch einsetzen) nichts, was man nicht mit
"poor mans dependency injection" lösen könnte. Denn man sollte grundsätzlich seinen Code so schreiben, dass man ihn auch händisch zusammentackern kann. Der IoC Container nimmt einem am Ende nur diese Arbeit ab und automatisiert einiges. Wenn man ihn falsch einsetzt, hat man sich am Ende nämlich ganz schnell eine Abhängigkeit auf den Container eingehandelt. Das merkt man schnell, wenn man plötzlich für einen Test den container braucht, was
nicht der Fall sein sollte.