Verschachtelte Records

[Blup]

Die einzelnen Anwendungsfälle (bzw. deren Kern) sollten niemals direkt auf irgendwelche Sachen außerhalb zugreifen.
Erst recht nicht auf globale Variablen oder ähnliches. Sonst ist der Anwendungfall nicht mehr unabhängig testbar.

Anwendungskern <-> Repository <-> globale Variable

Das Repository könnte eine Klasse sein, die eine Kopie der für den Anwendungsfall wichigen globalen Einstellungen erhält.
Alternativ wäre auch ein Interface denbar, das eine Klasse verbirgt, die Zugriffe auf globale Variablen weiter leitet.
Im Testfall könnte der Testfall selbst dieses Interface bereitstellen.

So kann man für globale Einstellungen einfach TSettings verwenden, aber auch die für den jeweiligen Anwendungsfall wichtigen Einstellungen über das Repository per Property direkt ansprechen.

[Shadowwalker]

Versteh mich nicht falsch, aber könntest du das auch für jemanden erklären der nicht in dieser Materie drinsteckt?

[Benedikt Magnus]

Um die Ursprungsfrage zu beantworten und Redeemers Antwort etwas auszuführen, man kann Records problemlos verschachteln, nur findet die Deklaration der Typen getrennt von der verschachtelten Struktur statt.
Also so:

Delphi-Quellcode:

type
  TAllgemein = record
    var Bla...
  end;

  TDateien = record
    var Bla...
  end;

 TProgrammEinstellungen = record
   Allgemein: TAllgemein;
   Dateien: TDateien;
 end;

var
  ProgrammEinstellungen: TProgrammEinstellungen;

[Blup]

Die stark vereinfachte Skizze einer Beispiel-Anwendung:
Berechne die Summe von zwei Zahlen.
Das gerundete Ergebnis wird ausgegeben.
Wie das Ergebnis gerundet wird, legt eine globale Einstellung fest.
Die Globalen Einstellungen werden vom Anwendungsfall nicht verändert.

Delphi-Quellcode:

TAnwendungsfallSummeConfig = class()
puplic
  property Rundungstyp: Integer;
end;

TAnwendungsfallSumme = class()
  constructor Create(AConfig: TAnwendungsfallSummeConfig);
  destructor Destroy; override;
  {...}
protected
  property Config: TAnwendungsfallSummeConfig;
puplic
  property Wert1: Float;
  property Wert2: Float;
  property Ergebnis: Float;
end;

implementation

constructor TAnwendungsfallSumme.Create(AConfig: TAnwendungsfallSummeConfig);
begin
  inherited;

  FConfig := AConfig;
end;

destructor TAnwendungsfallSumme.Destroy;
begin
  FConfig.Free;  

  inherited;
end;

TAnwendungsfallSummeConfig könnte im einfachsten Fall auch ein Record oder verschachtelter Record sein.
Wichtig ist aber die Trennung "Global" vom konkreten Anwendungsfall.

Anwendungsfall im Programm erzeugen

Delphi-Quellcode:

var
  config: TAnwendungsfallSummeConfig;
begin
  config := TAnwendungsfallSummeConfig.Create;
  config.Rundungstyp := Global.Settings['Allgemein.Rundungstyp'];

  AnwendungsfallSumme := TAnwendungsfallSumme.Create(config);

  // wie man den Anwendungsfall mit dem Formular verknüpft, ist schon das nächste Thema ... MVC usw.
end;

Im Testprojekt gibt es die Unit 'Global' nicht. Auch das Formular wird dort nicht gebraucht.
Dort soll unter anderem die Berechnung für jeden Rundungstyp getestet werden.
Wie man eine Testanwendung und Testfälle erzeugt ist bekannt?

[Shadowwalker]

#9
dann habe ich aber das Problem was ich in #6 angesprochen habe

#10
Klassen möchte ich keine verwenden.
Records mit Class-Variablen bedeuten weniger Stress, weniger Fehleranfälligkeit wenn man mal irgendwas vergisst und weniger Code.

#11
das ist das was ich im Eingangsbeitrag schrieb. Nur eben mit class-Variablen, damit ich keine lokalen Variablen benötige.

Zitat:

Anwendung dafür ist mir bis jetzt noch keine eingefallen.

Habe ich im Eingangspost und in #6 geschrieben.

[Benedikt Magnus]

In meinem Beispiel kannst du nur ProgrammEinstellungen.Allgemein.Bla aufrufen, Allgemein.Bla gibt es nicht. Das von dir in Beitrag 6 beschriebene Problem ist damit also nicht gegeben.

[Shadowwalker]

Aber auch nur mit dieser zusätzlichen Zeile

Delphi-Quellcode:

var
  ProgrammEinstellungen: TProgrammEinstellungen;

Was ist hiergegen einzuwenden?

Delphi-Quellcode:

type
 TProgrammEinstellungen = record
 public
  type Allgemein = record
   class var Bla...
  end;

  type Dateien = record
   class var Bla...
  end;
 end;

Alle meine Units mit Prozeduren und Funktionen sind mit solchen Records mit class-vars aufgebaut.

Was absolut für eine Klasse mit Settern und Gettern spricht ist aber, dass ich schon in der Unit selber Überprüfungen durchführen kann


hier mein erster eigener versuch

Delphi-Quellcode:

// Unit uSettings

uses uSettingsAllgemein;

type
 TSettings = class
 private
 protected
 public
  Allgemein: TAllgemein;

  constructor Create; overload;
  destructor Destroy; override;
 end;

var
 Settings: TSettings;

implementation

constructor TSettings.Create;
begin
 inherited;

 Settings.Allgemein:= TAllgemein.Create;
end;

destructor TSettings.Destroy;
begin
 Settings.Allgemein.Free;

 inherited;
end;

Delphi-Quellcode:

// Unit uSettingsAllgemein

type
 TAllgemein = class
 private
  function GetBla: Integer;
  procedure SetBla(const Value: Integer);
 public
  constructor Create; overload;
  destructor Destroy; override;

  property Bla: Integer read GetBla write SetBla;
 end;

implementation

... contructor destructor

function TAllgemein.GetBla: Integer;
begin
 Result .. keine Ahnung was hier hin muss
end;

procedure TAllgemein.SetBla(const Value: Integer);
begin
 auch hier keine Ahnung wo was zugewiesen wird.
 hier würde ich aber prüfen, ob Value < -1 oder > X wäre
end;

[MichaelT]

Warum machst du nicht ein Singleton der Form.

Zitat von Shadowwalker:

#9

#11
das ist das was ich im Eingangsbeitrag schrieb. Nur eben mit class-Variablen, damit ich keine lokalen Variablen benötige.

Zitat:

Anwendung dafür ist mir bis jetzt noch keine eingefallen.

Habe ich im Eingangspost und in #6 geschrieben.

[Shadowwalker]

Weil ich das nicht verstehe und lieber bei einfachen Sachen bleibe.

[freimatz]

http://clean-code-developer.de/die-g...le_stupid_KISS