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

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

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