Klassendesign - wie umgehen mit bedingten Eigenschaften?

[SProske]

Hallo,

ich habe eine Klasse (für Exportzwecke), in der festgelegt ist, ob eine bestimmte Eigenschaft fest hinterlegt ist oder dynamisch ausgelesen werden soll. Für den Fall der festen Hinterlegung, muss natürlich noch der konkrete Wert hinterlegt sein. Im simpelsten Falle also:

Delphi-Quellcode:

  TFoo = class
  strict private
    FHasFixBar: Boolean;
    FBar: Integer;
  public
    property HasFixBar: Boolean [..];
    property Bar: Integer [..];
  end;

Solange ein fester Wert hinterlegt, ist das alles noch relativ simpel, aber was sollte im dynamischen Fall geschehen:
- Einen Defaultwert für FBar hinterlegen
- Auf Variants umsteigen und NULL hinterlegen
- TFoo hat nur die Eigenschaft HasFixBar und für den Ja-Fall gibt es eine abgeleitete Klasse, die auch Bar hinterlegt hat
- irgendeine viel, viel bessere Lösung

Ich würde Wetten, dass sich zu dieser oder zumindest einer ähnlichen Problematik, schon irgendwer mal sehr viele schlaue Gedanken gemacht hat - allein mir fehlt der Suchansatz.
Ich wäre also für Denkansätze, Links zu schlauen Gedanken, passenden Stichwörtern und einem aussagekräftigerem Threadtitel sehr dankbar.

[himitsu]

Interfaces und Bar da rein?


stored kennt nicht nur True oder False

Delphi-Quellcode:

private
  function StoredBar: Boolean;  // Result := FBar <> FAktuellerDefaultWert;
published
  property Bar: Integer read FBar write FBar stoded StoredBar;

Vorallem Default muß aber unbedingt mit dem übereinstimmen, was nach dem Constructor wirklich standardmäßig gesetzt ist, da es sonst nette unschöne Ergebnisse liefert.
In "aktuelleren" Delphis, kann man das Default und Stored auch als Attribute definieren (vorallem Default ist da gut, da es auch Strings unterstützt)

[HeZa]

Ich verstehe deine Aufgabenstellung jetzt so:

Ist HasFixBar True dann hat die Klasse selber den Wert, ansonsten muss der Wert gesetzt werden.

Wenn dem so ist kannst du ein Event anbieten:

Delphi-Quellcode:

  TGetBarEvent = procedure (var Bar: Integer) of object;

  TFoo = class
  strict private
    FHasFixBar: Boolean;
    FBar: Integer;
    FOnGetBar: TGetBarEvent
    function GetBar: Integer
  public
    property HasFixBar: Boolean [..];
    property Bar: Integer read GetBar [..];
    property OnGetBar: TGetBarEvent [...];
  end; 

[...]

function TFoo.GetBar: Integer;
begin
  Result := Default;

  if FHasFixBar then
    Result := FBar
  else
  if Assigned(FOnGetBar) then
    FonGetBar(Result)
// und abhängig davon, wie hart du den Fehler betrachtest, dass jemand nicht die dynamik des property Bar beachtet
//else
//  raise EInvalidOperation.Create('Internal Error. OnGetBar musst assigned.');
end;

[Namenloser]

Der einfachste und allgemeinste Weg:

Delphi-Quellcode:

  TFoo = class
  strict private
    FHasFixBar: Boolean;
    FBar: Integer;
  public
    function GetBar(out Value: Integer): Boolean;
  end;


function TFoo.GetBar(out Value: Integer): Boolean;
begin
  Result := FHasFixBar;
  if Result then
    Value := FBar;
end;

Properties kann man dann halt nicht verwenden, aber eine saubere Schnittstelle finde ich wichtiger als syntaktischen Zucker.

[Dejan Vu]

Nenne die Methode doch lieber 'TryGetValue', dann passt das zu 'TryStrToInt' etc.

Ich würde das wirklich als 2 Properties abbilden, genauso, wie Du das gemacht hast. Man kann das auch mit Variants abbilden ('Null' oder 'UnAssigned') wäre dann 'HasFoo=False', aber das hat den Nachteil, das Du hier zwei Aussagen 'Wert ist vorhanden' und 'Wert' kodierst. Das spart vielleicht ein wenig Tipparbeit, aber kodieren von Information ist immer blöd.

Du kannst das natürlich auch über eine generische Klasse, ähnlich dem TNullable<T> abbilden. Letzteres ist mW in Spring4D abgebildet. Es gibt hier im Forum auch Beiträge darüber.

[Namenloser]

Zitat von Dejan Vu:

Nenne die Methode doch lieber 'TryGetValue', dann passt das zu 'TryStrToInt' etc.

Verbesserungsvorschlag akzeptiert.

Zitat von Dejan Vu:

Ich würde das wirklich als 2 Properties abbilden, genauso, wie Du das gemacht hast. Man kann das auch mit Variants abbilden ('Null' oder 'UnAssigned') wäre dann 'HasFoo=False', aber das hat den Nachteil, das Du hier zwei Aussagen 'Wert ist vorhanden' und 'Wert' kodierst. Das spart vielleicht ein wenig Tipparbeit, aber kodieren von Information ist immer blöd.

Bei zwei Properties hat man das Problem, dass jemand eventuell nur die Property "Bar" sieht und gar nicht auf dem Schirm hat, dass es passieren könnte, dass der Wert nicht existiert, und es daher auch nicht prüft. Ich finde, sowas sollte man von vornherein ausschließen, wenn es geht. Ich setze mir immer als Ziel, dass nur legale Methodenaufrufe möglich sein sollen (lässt sich natürlich nicht immer erreichen).

[Dejan Vu]

Hmm... Dann vielleicht eine 'TDynamic<T>' Klasse

Delphi-Quellcode:

Type
  TDynamic<T> = class
  private
     FHasValue : Boolean;
     FValue : T;
  ...
  public 
    property HasValue : Boolean Read FHasValue Write FHasValue;
    property Value : T Read GetValue Write SetValue;
  End;

GetValue knallt, wenn HasValue = False. SetValue setzt HasValue := False;

[Sir Rufo]

Suchst du eventuell so etwas?

Delphi-Quellcode:

type
  TFoo = class
  private const
    FixedBarValue = 42;
  protected
    function GetBar: Integer; virtual;
  public
    property Bar: Integer read GetBar;
  end;

  TSpecialFoo = class( TFoo )
  protected
    function GetBar: Integer; override;
  end;

function TFoo.GetBar: Integer;
begin
  Result := FixedBarValue;
end;

function TSpecialFoo.GetBar: Integer;
begin
  Result := Random( 42 );
end;

[SProske]

Erstmal Danke an alle für die Vorschläge/Ideen.
Mir persönlich gefällt die Idee von Namenloser, das nur über Methoden zu lösen. So sollte jedem klar sein, wann er auf welche Werte zugreifen kann.
Wird dann im Endeffekt wohl so etwas wie:

Delphi-Quellcode:

  TFoo = class
  strict private
    FHasFixBar: Boolean;
    FBar: Integer;
  public
    function TryGetBar(out Value: Integer): Boolean;
    procedure SetToDynamicBar;
    procedure SetToFixedBar(const Value: Integer);
  end;