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

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

[p80286]

Zitat von Phoenix:

Dazu ist es am einfachsten, den jeweils entsprechend präparierten Fake-User für den Test reinzugeben.

Irgendwas habe ich da nicht verstanden, genau dafür gibt es die Benutzerverwaltung. Eigentlich sollte der Arbeitsteil nur Rechte kennen, der Benutzer dahinter sollte **egal sein.

Gruß
K-H

[Sir Rufo]

Abhängigkeit und schwer testbar

Delphi-Quellcode:

unit FooUnit;

interface

type
  TFoo = class
    property Value : string;
  end;

function Foo : TFoo;

implementation

var
  _Foo : TFoo;

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

end.

Delphi-Quellcode:

unit BarUnit;

interface

uses
  FooUnit;

type
  TBar = class
    function GetValue : string;
  end;

implementation

function TBar.GetValue : string;
begin
  Result := Foo.Value;
end;  

end.

Das sollte man besser so machen:

Delphi-Quellcode:

unit BarUnit;

interface

uses
  FooUnit;

type
  TBar = class
  private
    FFoo : TFoo;
  public
    constructor Create( AFoo : TFoo );
    function GetValue : string;
  end;

implementation

constructor TBar.Create( AFoo : TFoo );
begin
  inherited;
  FFoo := AFoo;
end;

function TBar.GetValue : string;
begin
  Result := FFoo.Value;
end;  

end.

Jetzt kann TBar auch mit unterschiedlichen TFoo -Instanzen getestet werden.

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