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

[Dejan Vu]

Hi,

Man liest ja immer wieder, das globale Variablen böse sind. Nun, sie sind ja gar nicht böse, diese unschuldigen Dinger, aber die Verwendung. Warum? Wegen der Abhängigkeiten, die man sich damit einhandelt, d.h. die Methode/Klasse, die globale Variablen verwendet, ist ohne diese Variablen nicht lebensfähig. Bestimmt gibt es noch andere Gründe und man könnte ganze Seiten füllen, aber das mache ich hier nicht.

Also soll man gar keine globalen Variablen verwenden? Blöderweise geht es (nicht immer) ohne sie nicht. Wie also dann? Was sind 'best practice'?

Beispiel (nicht von mir): Businessobjekte müssen prüfen, ob der angemeldete Benutzer über das entsprechende Recht verfügt, die Aktion des BO auszuführen. Also sieht die Aktion vielleicht so aus:

Delphi-Quellcode:

Procedure TMyBusinessObject.Action();
Begin
  If not GlobalStuff.CurrentUser.IsGranted (CanExecuteMyBusinessAction) then
    Raise ERightsException.Create('You are not allowed to do this');
  
  PerformAction();
End;

Hier ist der Fehler der, das ich damit das BusinessObject in seiner Verwendung einschränke. Ich werde es nie mit einem anderen User durchführen können, immer nur mit dem angemeldeten Benutzer. Lösung: Der Benutzer, der die Aktion durchführt, wird per DI zur Verfügung gestellt. Einfach ausgedrückt: Das BO bekommt eine Property 'User', die auch im Konstruktor übergeben wird. Der Anwender des BO übergibt dann vielleicht den 'CurrentUser' (und hat dann die Abhängigkeit an der Backe),
aber vielleicht gibt es auch Szenario, in dem gar kein User angemeldet ist (Test, Batch processing etc.)

Anderes Beispiel: Eine Meldung ausgeben. Eine Methode soll bei Erfolg eine Messagebox anzeigen.

Delphi-Quellcode:

Procedure TMyCommand.Execute();
Begin
  Try
    BusinessObject.Action();
    ShowMessage('Success');
  except
    On e:Exception do
       ShowError(e.Message);
  end
End;

Hier habe ich zwei Abhängigkeiten ('ShowMessage') und 'ShowError'. Nehmen wir an, die sind als Prozeduren so in Vcl.Dialogs deklariert. Schon habe ich mich bei 'TMyCommand' auf die Verwendung der VCL festgelegt. Ich kann das zwar auch abstrahieren, aber hier wird es dann albern, weil ich nicht finde, das man -nur weil Gurus sagen, das globale Abhängigkeiten böse sind- alles nachmachen muss, was angeblich richtig ist. Denn irgendwann wird es unübersichtlich und -jetzt kommts- unnötig kompliziert. Ich fange dann nämlich an, einen Wrapper zu schreiben, der z.B. die Messageboxen kapselt. Gut, wenigstens hätte ich dann nur noch eine Abhängigkeit:

Delphi-Quellcode:

Procedure TMyCommand.Execute();
Begin
  Try
    BusinessObject.Action();
    GlobalStuff.UIWrapper.ShowMessage('Success');
  except
    On e:Exception do
       GlobalStuff.UIWrapper.ShowError(e.Message);
  end
End;

So, und nun könnte ich den UIWrapper wieder als DI/Property angeben und wäre dann irgendwie aus dem Schneider. Nur müsste das Kommando nun zwei Abhängigkeiten haben, denn -logisch- der User wird ja auch von außen übergeben.

Delphi-Quellcode:

Constructor TMyCommand.Create (aUser : IUser; aUIWrapper : IUIWrapper ...)
begin
  BusinessObject := TMyBusinessObject.Create (aUser);
  UIWrapper := aUIWrapper;
End;

Procedure TMyCommand.Execute();
Begin
  Try
    BusinessObject.Action();
    UIWrapper.ShowMessage('Success');
  except
    On e:Exception do
       UIWrapper.ShowError(e.Message);
  end
End;

Nun soll das Kommando noch loggen und einen Report als Resultat der Business Action ausgeben. Puh, noch zwei globale Abhängigkeiten (Logger und ReportEngine). Gut, das Pattern ist ja bekannt, ergo

Delphi-Quellcode:

Constructor TMyCommand.Create (aUser : IUser; aUIWrapper : IUIWrapper; aLogger : ILogger; aReportEngine : IReportEngine)
begin
  BusinessObject := TMyBusinessObject.Create (aUser);
  UIWrapper := aUIWrapper;
  ...
End;

Ach, das BO persistiert die Daten ja auch noch in eine Datenbank... Kein Problem, dann wird die Datenbankverbindung hinzu, und zwar ein Wrapper, ist ja klar, denn auf einen Provider will man sich ja nicht festlegen. Und auf die globale Connection will man nicht zugreifen, weil ... böse.

Delphi-Quellcode:

Constructor TMyCommand.Create (aUser : IUser; aUIWrapper : IUIWrapper; aLogger : ILogger; aReportEngine : IReportEngine; aDatabaseConnection : IDbConnection)
begin
  BusinessObject := TMyBusinessObject.Create (aUser, aDatabaseConnection);
  UIWrapper := aUIWrapper;
  ...
End;
Procedure TMyCommand.Execute();
Begin
  Try
    BusinessObject.Action();
    ReportEngine.PrintReport(BusinessObject);

    UIWrapper.ShowMessage('Success');
    Logger.Success('Action');
  except
    On e:Exception do
       UIWrapper.ShowError(e.Message);
  end
End;

Ist das wirklich so gewollt?
Und wenn nicht: Wie macht man das denn richtig? Ich z.B. habe bemerkt, das ich eigentlich fast immer etwas falsch designt habe, wenn ich eine globale Abhängigkeit einführe. Aber in diesem Beispiel? Ich könnte alles, was es so an globalem Zeugs gibt, auch in eine einzige Klasse packen. Dann würde ich nur einen Parameter an den Konstruktor übergeben, aber genau genommen ist das genauso bescheuert wie die Verwendung eines globalen Scopes.

Wie macht ihr das? Oder schreibt ihr Anwendungen, bei denen die Klassen eigentlich nicht/selten wiederverwendet werden, weil sie ja doch sehr problemspezifisch sind?

[Sherlock]

Albern ist das richtige Wort. Theorie und Praxis wäre eventuell die sachlichere Zusammenfassung der Problematik.

Also: Globales vermeiden wo möglich, nutzen wo nötig.

Sherlock

[Phoenix]

Ja, das ist wirklich so gewollt.
Du willst das aber - aus guten Gründen - nicht immer alles von Hand zusammenstöpseln.

Ein guter IoC-Container nimmt Dir diese Arbeit ab und löst die Abhängigkeiten selber auf und instanziert Dir diese Klassen mit den Monster-Konstruktoren von alleine.

Du kannst natürlich auch dort, wo es Sinn macht, Argumente zusammenfassen.
z.B. der UIWrapper und den Report (Ein- / Ausgabe für den User) und den CurrentUser, die Connection und das technische Logging (Context).

Die Datenbankverbindung / Transactionhandling und das Logging würde man im übrigen vermutlich eher über Aspekte als über DI lösen, aber prinzipiell passt das sonst so.

[Sir Rufo]

Kann es sein, dass der Titel falsch ist?

Bis jetzt geht es um globale Abhängigkeiten und nicht um globale Variablen wie der Titel vermuten lässt.

[Dejan Vu]

Zitat von Sherlock:

Albern ist das richtige Wort.

Einerseits ja, andererseits nein. Das Dilemma der globalen Abhängigkeiten ist nicht von der Hand zu weisen. Und wenn man den Weg gehen will, seine Anwendungen auch übermorgen noch modern zu halten, führt leider kein Weg daran vorbei.

Zitat von Phoenix:

Ein guter IoC-Container nimmt Dir diese Arbeit ab und löst die Abhängigkeiten selber auf und instanziiert Dir diese Klassen mit den Monster-Konstruktoren von alleine.

D.h. eine Factory, die mir das gewünschte Objekt -wie auch immer- zusammenbastelt. Ob nun über DI, oder morgen über Delegates, oder Zusammenfassen von Abhängigkeiten ist dann wieder Schnurz.

D.h. (Hab kein aktuelles Delphi mit Generics, d.h. vielleicht Syntaxfehler)

Delphi-Quellcode:

Function TMyIocContainer.CreateCommand<TCommand : ICommand> : TCommand;
Begin
  result := TCommand.Create(CurrentUser, VCL_UIWrapper, TextFileLogger, FastReportReportingEngine, AnyDACConnection);
End;

Dann ist der Anwender des Containers wieder auf eine Globale Instanz des IocContainers angewiesen. Außer, ich gebe ihm das wieder per DI mit, oder wie?

Zitat von Sir Rufo:

Kann es sein, dass der Titel falsch ist?

Die globale Instanz einer Klasse ist ja eine globale Variable. Aber ich ändere den Titel.

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von Sir Rufo:

Kann es sein, dass der Titel falsch ist?

Die globale Instanz einer Klasse ist ja eine globale Variable. Aber ich ändere den Titel.

Nein muss sie nicht zwangsläufig sein, denn dafür gibt es Möglichkeiten, diese bösen Nebeneffekte (unkontrolliertes und ungeschütztes Überschreiben) von globalen Variablen zu vermeiden:

Delphi-Quellcode:

unit FooUnit;

interface

type
  TFoo = class
  end;

//var
//  Foo : TFoo;

function Foo : TFoo;

implementation

var
  _Foo : TFoo;

function Foo : TFoo;
begin
  if not Assigned( _Foo ) then
    _Foo := TFoo.Create;
  Result := _Foo;
end;

finalization

_TFoo.Free;

end.

oder bei neueren Delphi Versionen

Delphi-Quellcode:

unit FooUnit;

interface

type
  TFoo = class
  private
    class var _Foo : TFoo;
    class destructor Destroy;
  public
    class function Default : TFoo;
  end;

implementation

class function TFoo.Default : TFoo;
begin
  if not Assigned( _Foo ) then
    _Foo := TFoo.Create;
  Result := _Foo;
end;

class destructor TFoo.Destroy;
begin
  _Foo.Free;
end;

Trotz allem bleibt aber immer noch die Abhängigkeit bestehen.

[p80286]

Entschuldigt, aber insbesonders das Problem mit dem "User" kann ich nicht nachvollziehen.
Der Benutzer sitzt vor der Tastatur und ein Anwendungsprogramm hat mit ihm selten etwas zu tun.
Es sei denn es gibt eine Benutzerverwaltung. Und diese sollte den Benutzer "global" bevorraten, und auf Anfrage des "Arbeitsteils" die gewünschten Informationen liefern.

Nicht mehr und nicht weniger.

Gruß
K-H

[Phoenix]

Zitat von p80286:

Und diese sollte den Benutzer "global" bevorraten, und auf Anfrage des "Arbeitsteils" die gewünschten Informationen liefern.

Damit hast Du wieder eine Abhängigkeit darauf.
Was ist nun, wenn Du den Code automatisch testen willst? Du hast dann keinen User der sich eingeloggt hat, der hier global bereitstehen könnte.

Du willst den Test ggf. mit mehreren gemockten Usern und entsprechenden mehreren Rechte-Kombinationen testen um sicher zu gehen, dass der Code in allen Fällen mit allen notwendigen oder mit fehlenden Rechten wie entsprechend erwartet funktioniert.

Dazu ist es am einfachsten, den jeweils entsprechend präparierten Fake-User für den Test reinzugeben.
Bei einer globalen Abhängigkeit ist es schwierig bis unmöglich das so zu instrumentieren dass für jeden Test der korrekte User geliefert wird.

[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.

[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.