Globale Variablen/Abhängigkeiten = Böse... Und nu?

[Dejan Vu]

Zitat von p80286:

genau dafür gibt es die Benutzerverwaltung. Eigentlich sollte der Arbeitsteil nur Rechte kennen, der Benutzer dahinter sollte **egal sein.

Ersetze 'User' durch 'Permissions'. Dann kennt das Businessobjekt nur Permissions. Genaugenommen ist das sogar besser, denn was interessiert es das Businessobjekt was das konkret für ein User ist.

Aber die 'Benutzterverwaltung' ist hier auch viel zu fett. Ich brauch an der Stelle keine Verwaltung, sondern nur den Scope/Kontext, der weiß, mit welchen Rechten gearbeitet wird.

Zitat von Sir Rufo:

Abhängigkeit und schwer testbar...

Sobald Du ein Mockingframework hast, das Dir deine statische Klassen mocken kann, ist das wurscht (Gibt es das für Delphi?).

Da imho jede sauber designte Klasse gut (ohne Mocks) testbar ist, aber nicht jede gut testbare Klasse automatisch sauber designt ist, würde ich das Argument 'lässt sich gut/schlecht testen' etwas nach hinten schieben, aber wirklich nur ein wenig. Wichtiger ist für mich: Ist die Klasse flexibel, erweiterbar, robust und wiederverwendbar?

Halten wir also fest:
1. Globale Abhängigkeiten auch auf Kosten der Tipparbeit durch DI auflösen.
2. Die nun umständlichen Instantiierungen über eine Factory abbilden und damit den Overhead verbergen.
3. Abhängigkeiten nur durch Interfaces abbilden.

So sieht das doch wirklich gut aus.
Im Falle des 'Users/Permission' sieht es in der Praxis ganz einfach so aus:
Das Businessobjekt (oder einfacher: die konkrete Aktion) kann in der Anwendung nur von einem Benutzer mit ausreichenden Rechten ausgeführt werden. Fein.

Aber in einem Batchprozess möchte ich gerne (oder ich muss) auf diese Rechte pfeifen. Ich will mir keinen Batchuser zusammenfriemeln, der bestimmte Rechte hat, wobei meine 'Benutzerverwaltung' vielleicht so gemein ist, aus Sicherheitsgründen zu verbieten, das jemand zwei bestimmte Rechte gleichzeitig innehat und das genau die sind, die ich gerade benötige.

Also baue ich mir in meinem Batchprozess meinen Pseudouser (also eine Klasse, die das IUser/IPermissions-Interface implementiert) nach und habe genau das, was ich wollte: Einerseits ein BO, das im Kontext der Anwendung und Aufgerufen durch ein Kommando genau die Sicherheit bietet, die ich brauche, aber sonst eine extrem flexible Klasse, deren Abhängigkeiten im Konstruktor für jeden sichtbar sind und die ich so flexibel wie möglich verwenden kann.

Wirklich? Fast, denn die Schnittstelle (hier wirklich: das Interface) der Abhängigkeiten sollte nur genau die Properties beinhalten, die für die Durchführung dieser Aufgabe wirklich notwendig ist.

[Stevie]

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.

Zitat von Dejan Vu:

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.

[p80286]

Zitat von Dejan Vu:

Aber in einem Batchprozess möchte ich gerne (oder ich muss) auf diese Rechte pfeifen. Ich will mir keinen Batchuser zusammenfriemeln, der bestimmte Rechte hat, wobei meine 'Benutzerverwaltung' vielleicht so gemein ist, aus Sicherheitsgründen zu verbieten, das jemand zwei bestimmte Rechte gleichzeitig innehat und das genau die sind, die ich gerade benötige.

Warum bitteschön sollten für einen batch"User" andere Regeln gelten wie für einen "normalen Dialog User". Entweder es ist für alle Benutzer bzw. Prozesse ein entsprechendes Regelwerk definierbar oder aber da hat jemand seine Hausaufgaben nicht gemacht/machen können.

Gruß
K-H

[Sir Rufo]

Zitat von p80286:

Zitat von Dejan Vu:

Aber in einem Batchprozess möchte ich gerne (oder ich muss) auf diese Rechte pfeifen. Ich will mir keinen Batchuser zusammenfriemeln, der bestimmte Rechte hat, wobei meine 'Benutzerverwaltung' vielleicht so gemein ist, aus Sicherheitsgründen zu verbieten, das jemand zwei bestimmte Rechte gleichzeitig innehat und das genau die sind, die ich gerade benötige.

Warum bitteschön sollten für einen batch"User" andere Regeln gelten wie für einen "normalen Dialog User". Entweder es ist für alle Benutzer bzw. Prozesse ein entsprechendes Regelwerk definierbar oder aber da hat jemand seine Hausaufgaben nicht gemacht/machen können.

Gruß
K-H

Gut, das ist ja z.B. bei Datenbanken ein bekanntes Szenario: Benutzer X darf die Tabellen nur lesen, aber über eine SP darf er doch etwas hineinschreiben.

Allerdings, wenn für die Aktion TuWas die Berechtigungen egal sind, dann prüft diese Aktion die Berechtigungen einfach nicht.

[Dejan Vu]

[QUOTE=Sir Rufo;1259345]

Zitat von p80286:

Benutzer X darf die Tabellen nur lesen, aber über eine SP darf er doch etwas hineinschreiben.

Und mit meinem bulk load muss ich genau das umgehen.

Zitat von Stevie:

Das Thema entwickelt ja langsam eine echte Dynamik

Mein Hintergedanke war der, das hier endlich mal darüber gesprochen wird, wie man es richtig macht und nicht immer, das man es so nicht macht

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.

Zitat:

Schöne Code Beispiele - da sie auf verschiedenen Ebenen einige Fehler aufzeigen.

Sie sind mit Absicht so.
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.

Zitat:

Zweiter Fall, die Kopplung an die GUI

Daher das 'Command' (in Anlehnung an das ICommand)

Zitat:

Wenn ich nunmal die VCL verwende, dann ist es auch nicht böse

. Also ich würde mich heute nicht mehr darauf festlegen ob VCL oder FMX. Unabhängig davon würde ich das trotzdem kapseln (zumindest die Messageboxen), denn diese Interaktion möchte ich erweiterbar gestalten und vor allen Dingen stringent im Design (Kein Mischmasch aus OK/Cancel Yes/No etc. Vielleicht alle Text aus einer Textrepository, d.h. keine 'echten' Texte wg. Übersetzung usw.) Ach, und falls ich doch Abfragen ("Wollen Sie wirklich die Zentrale in die Luft jagen?") und Meldungen ("The HQ was successfully destroyed") testen will, ist so ein Wrapper wirklich sehr nützlich.

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.

Allerdings: Das Kommando hat nun einmal diese Abhängigkeiten: Es wird geprüft, gespeichert, gedruckt und interagiert. Und mit DI müsste das dann entsprechend ausarten, weil in meinem Fall das Kommando nun einmal die 'oberste Instanz ist', die die logische Aktion 'TuWas, aber mit allem Drum und dran' ausführt.

Zitat:

Zitat von Dejan Vu:

Da imho jede sauber designte Klasse gut (ohne Mocks) testbar ist

Wohl kaum.

Mocks erleichtern nur die Arbeit, sofern ich unter 'Mocking' das gleiche verstehe, wie Du (s.o). Eine saubere (=kleine) Klasse mit DI kommt doch ohne Mocks aus. Ich verwende Mocks bisher nur, weil ich keinen Bock habe, die Abhängigkeiten komplett zu faken. Und da ich in einer Klasse laut Deiner Definition eh nie viele Abhängigkeiten haben kann, ist meine Behauptung auch nicht allzuweit hergeholt. Und die Hintertür ist: Das 'Ohne Mocking' steht in Klammern, weil *festlegen* will ich mich darauf nu auch nich, ne.

[p80286]

Zitat von Sir Rufo:

Gut, das ist ja z.B. bei Datenbanken ein bekanntes Szenario: Benutzer X darf die Tabellen nur lesen, aber über eine SP darf er doch etwas hineinschreiben.

Es könnte sein, daß über die SP die Art der Daten beschränkt wird, was über die gängigen Berechtigungen nicht vernünftig lösbar sein kann.
Aber abgesehen davon, ist das meiner Meinung nach Schusseligkeit beim Design oder aber die allgegenwärtige Nachfrickelei.
(bevor mir jetzt hier der kragen platzt sehe ich mal zu, daß ich meine Arbeit gemacht kriege)

Gruß
K-H

[Sir Rufo]

Das mit dem BULK LOAD ist sauber nur durch eine Mittelschicht abzubilden (so wie auch die gesamte Berechtigungs-Verwaltung wer wie wann wo was machen darf, bis runter auf Datensatz-/Feld-Ebene runter)

Die Anwendung kommt mit dem SQL-Server gar nicht in Berührung, sondern spricht mit der Mittelschicht.
Die Mittelschicht spricht mit dem SQL-Server und darf dort eh alles (ok, fast alles).

Ok, aber das weiter zu vertiefen sprengt wohl den Rahmen globale Abhängigkeiten

[Stevie]

Zitat von Dejan Vu:

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)

Zitat von Dejan Vu:

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.

[Dejan Vu]

Zitat von Stevie:

Zitat:

2. Mock <> Fake

Fakt ist, man ersetzt das richtige Dings durch nen anderes Dings. Und damit man son Dings austauschen kann, muss man sie voneinander entkoppeln.

Alles klar. Kann man so vereinfachen.

Zitat:

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)

'einen Wolf tippen' ist die Quintessenz und der eigentliche Grund (einer davon), weshalb diverse Designregeln, OCP, LSP, ISP... eingeführt wurden. Ich mache etwas, weil ich nicht ewig tippen will, und 100 Jahre entwanzen, weil diese ich diese dämlichen Seiteneffekte nicht vermeiden kann und nicht, weil es gegen Gesetze verstößt. Kommt zwar aufs Gleiche heraus, aber ich habe hier ein paar sehr kluge Programmierer, die nur den Regeln folgen und dabei gar nicht merken, wie verworren, komplex und total überkandidelt das Ganze mittlerweile ist. Aber sie reiten auf den von Dir immer wieder zitierten Regeln herum und finden es total geil, sich 3 Tage über SRP den Kopf zu zerbrechen, anstatt es einfach 'einfach' zu gestalten. Ein sehr schönes Thema für einen anderen Thread.

Zitat:

Der will nur wissen, ob er XY machen darf oder nich und nicht, wie er das ermitteln.

Das war der korrekte Einwand von p80286, woraufhin ich meinte, man sollte 'IUser' durch 'IPermissions' ersetzen. Natürlich kann man das abstrahieren , aber die konkreten Rechte sind Bestandteil der Spezifikation und insofern nicht abstraktionswürdig. Kann man machen, wird man aber nicht. Wir haben Szenarioklassen à la 'Execute<BusinessObject>' die eine 'CanExecute' Methode haben, in der die Rechteabfrage umtergebracht ist.

Zitat:

Ich sag es oft

mir hast Du das noch nicht gesagt.

Aber dann verstehe ich deinen Einwand auch nicht: Ich habe ein Kommando als oberste Instanz. Dies führt eine Aktion und alle damit verbundenen weiteren Aktionen aus (Speichern, loggen, drucken, validieren etc.) Dem muss ich doch alle Abhängigkeiten übergeben, oder wie geht das sonst?

[Stevie]

Zitat von Dejan Vu:

ich habe hier ein paar sehr kluge Programmierer, die nur den Regeln folgen und dabei gar nicht merken, wie verworren, komplex und total überkandidelt das Ganze mittlerweile ist. Aber sie reiten auf den von Dir immer wieder zitierten Regeln herum und finden es total geil, sich 3 Tage über SRP den Kopf zu zerbrechen, anstatt es einfach 'einfach' zu gestalten. Ein sehr schönes Thema für einen anderen Thread.

Genau aus diesem Grund hab ich vorhin geschrieben, dass das ganze Clean Code, Principles und Patterns Gedöns kein Selbstzweck ist. Aber jeder, der sich mit der ganzen Thematik wenigstens ein bisschen auseinander gesetzt hat und etwas davon in die Tat umgesetzt hat, hat bestätigt, dass das positiv war. Was raus kommt, wenn mans übertreibt kann man sehr schön an dieser Fizzbuzz Implementierung sehen.

Zitat:

mir hast Du das noch nicht gesagt.

Prima, dann hab ich ja doch noch jemanden erreicht, dem ich das noch nicht gesagt habe
Ich hab mir das ja auch nicht selber ausgedacht, man kann das auch oft in Artikeln zu dem Thema lesen.
Erstmal die Prinzipien und vor allem das DIP verstehen und manuell anwenden, bevor man sich einem IoC Container zuwendet. Ansonsten wird man nämlich ganz schnell ziemlich böse davon überfahren und benutzt nen IoC Container am Ende als Service Locator.

Zitat:

Aber dann verstehe ich deinen Einwand auch nicht: Ich habe ein Kommando als oberste Instanz. Dies führt eine Aktion und alle damit verbundenen weiteren Aktionen aus (Speichern, loggen, drucken, validieren etc.) Dem muss ich doch alle Abhängigkeiten übergeben, oder wie geht das sonst?

Wenn man das betrachtet, als ob dein Kommando das alles selbst macht. Macht es aber eventuell gar nicht. Möglich ist an dieser Stelle zum Beispiel, das Chain- of-responsibility Pattern zu verwenden, so dass ebend nicht alles direkt innerhalb des einen Kommandos ausgeführt wird, sondern eins das nächste ausführt. Auch hier wieder beachten: wie flexibel und austauschbar möchte ich die Kommandos haben. Die Aktionen Speichern, Loggen, Drucken, Validieren operieren ja normalerweise auf einem anderen Objekt. Und je nachdem, wie man die geschrieben hat (Speichern ist ja immer eins der Paradebeispiele für "Wat kann ich eijentlich mit dieser RTTI und Attributen so machen?") hat man mehr oder weniger wiederverwendbare Bausteine, die man in verschiedenen Reihenfolgen aneinander ketten kann.

Eins steht aber auf jeden Fall fest - und das mag für manche befremdlich sein: man muss recht viel stumpfen Code für die Erstellung und Zusammentackerei schreiben. Und das ist am Ende das, was der IoC Container einem abnehmen kann.