Verständnisproblem: Globale, gruppierte Konstanten

[Keks]

Ich benötige in meiner Software regelmäßig gewisse Werte, die stets gleich bleiben sollen und sich in einer Ini Datei speichern lassen.
Die Werte sollten zudem irgendwie gruppiert sein, damit man damit leichter arbeiten kann (Autovervollständigung, Parameter-Eingrenzung).

So eine Liste ist zwar oft sehr praktisch und per Ord() lässt sich auch ein speicherbarer Wert ableiten, aber wenn ich die Liste später irgendwann verändere, ist es unmöglich, neue Werte zwischenrein zu setzen, da sich sonst die Zählnummer ändert.
TTier = (tiHund, tiKatze, tiMaus)

Um den Werten speicherbare Zahlen zuzuordnen, dachte ich stattdessen an sowas:

Delphi-Quellcode:

  TTier = record
    const HUND = 0;
    const KATZE = 12;
    const MAUS = 5;
  end;

Leider bin ich mir noch etwas unschlüssig, ob Records wirklich der beste Weg dafür sind oder ob es eine noch bessere Möglichkeit gibt.
Ich weiß, dass ich das auch als Klasse/Objekt lösen kann. Aber irgendwie fände ich es seltsam, für jede Wertegruppe ein globales Objekt zu erzeugen, das nur konstante Werte bereithält!?

Schön wäre es z.B., wenn man damit auch die Parameter-Typen in Funktionen festlegen könnte.
Also etwa sowas:
function GetTiername(tn: TTier): String;
Mit Aufruf:
s := GetTiername(TTier.HUND);
Das geht aber natürlich nicht, weil dann ein vollständiges Record und nicht ein einfacher Wert erwartet wird. Ändert man den Parameter in Integer, geht der Aufruf, aber die Funktion lässt sich dann natürlich auch mit allen anderen Integern und nicht nur den TTier-Werten aufrufen.

Zudem weiß ich leider nicht, ob es OK ist, direkt auf die Record-Werte zuzugreifen (TTier.HUND ) oder ob man das besser erst instanzieren sollte (var Tier: TTier; {...} Tier.HUND )

Ich würde mich freuen, wenn Ihr mir hier etwas auf die Sprünge helfen würdet. Danke!

[himitsu]

Zitat von Keks:

So eine Liste ist zwar oft sehr praktisch und per Ord() lässt sich auch ein speicherbarer Wert ableiten, aber wenn ich die Liste später irgendwann verändere, ist es unmöglich, neue Werte zwischenrein zu setzen, da sich sonst die Zählnummer ändert.

Man kann über die RTTI den einen Enum oder Set auch problemlos in einen String übersetzen lassen. (siehe die Enums/Sets in Property, welche in der DFM gespeichert werden)

Diese RTTI-Daten kann man kann auch problemlos verwenden, um damit die Autovervollständigung zu füttern.

Constanten stehen nicht in der RTTI, also lassen sie sich nicht automatisch auslesen und du bräuchstest somit eine manuell erstellte Liste/Array mit den Werten, um sie in der Autovervollständigung nutzen zu können. (siehe die TColor-Konstanten) Diese Liste kann auch über eine Registrierungsfunktion zur Laufzeit (z.B. beim Programmstart) gefüllt werden.

[Keks]

Zitat von himitsu:

RTTI

Nach dem Wechsel zu Delphi XE vor einigen Jahren war ich über den Größenzuwachs der kompilierten Exe erschrocken. Nach ein paar Recherchen war klar, dass hauptsächlich RTTI daran Schuld ist. Ich habe daraufhin alles mögliche getan, um es möglichst rauszunehmen, sodass sich die Dateigröße dann deutlich wieder reduzierte. Ich weiß nicht, ob ich das jetzt alles wieder rückgängig machen möchte...

Zitat von himitsu:

siehe die TColor-Konstanten

Was meinst Du genau? In Graphics.pas werden die Farben normalen Konstanten zugewiesen.
Meinst Du ich soll das so ähnlich machen?

Delphi-Quellcode:

type
  TTier = -$7FFFFFFF-1..$7FFFFFFF;
const
  tiKatze = TTier($00000C);

[himitsu]

Keine Sorge, selbst wenn man die neue erweiterte RTTI fast komplett deaktiviert (was möglich ist), dann funktioniert das immernoch, da diese Funktion auf die alte RTTI aufbaut, welche es schon praktisch immer gibt, da sie von der VCL (FormDesigner) rege verwendet wird.

http://geheimniswelten.de/tipps/code...und-zu-string/
GetEnumName und SetToString (Unit TypInfo), bzw. besser und vorallem (typ)sicherer hinter den Generics versteckt.


Und ich meinte das Colors-Array, welches sich aktuell in UIConsts versteckt und das z.B. von ColorToString verwendet wird.
Natürlich ist dieses Array fest, so daß man (eigentlich) keine eigenen TColor-Konstanten in den DFM-Loader einschleußen kann.

[Perlsau]

Wieso eine Ini-Datei, wenn es sich doch angeblich um immer gleichbleibende Konstanten handelt? Konstanten wird gewöhnlich ein Wert im Programmcode zugewiesen. Weist du Variablen Werte aus einer Ini-Datei zu, sind das keine Konstanten, sondern eben Variablen, auch wenn diese im gesamten Programmverlauf weitgehend konstant bleiben (sollen), wie z.B. ein Datenbank-Pfad oder der Benutzername usw. Deshalb unterscheidet Delphi doch Konstanten und Variablen, deren Deklaration mit unterschiedlichen Tokens eingeleitet wird: Const und Var.

[Keks]

Zitat von Perlsau:

Wieso eine Ini-Datei, wenn es sich doch angeblich um immer gleichbleibende Konstanten handelt? Konstanten wird gewöhnlich ein Wert im Programmcode zugewiesen. Weist du Variablen Werte aus einer Ini-Datei zu, sind das keine Konstanten, sondern eben Variablen, auch wenn diese im gesamten Programmverlauf weitgehend konstant bleiben (sollen), wie z.B. ein Datenbank-Pfad oder der Benutzername usw. Deshalb unterscheidet Delphi doch Konstanten und Variablen, deren Deklaration mit unterschiedlichen Tokens eingeleitet wird: Const und Var.

Letztlich geht es darum, dass der Anwender irgendwelche Auswahlen im Programm trifft, die gespeichert und wieder geladen werden müssen. Um bei dem Beispiel mit den Tieren zu bleiben: Der Anwender wählt selektiert in einer Liste mehrere Tiere. Diese Selektion muss auch später noch geladen und ausgewertet werden können. Es reicht nicht, die Indizes zu speichern, weil sich die Liste jederzeit ändern kann. Un in anderen Fällen brauche ich auch ganz bestimmte Werte, um konsistent mit anderen Programmen, auf die ich keinen Einfluss habe, zu bleiben (wenn man sich eine Datenquelle teilt). Ob das nun Ini- oder DB-Einträge sind, spielt eigentlich keine Rolle.

[nuclearping]

Du kannst auch sowas machen:
TTier = (tiHund = 1, tiKatze = 27, tiMaus = 15, ...)

[himitsu]

Zitat von nuclearping:

Du kannst auch sowas machen:
TTier = (tiHund = 1, tiKatze = 27, tiMaus = 15, ...)

Hier sollte man aber wissen, daß die RTTI so nicht mehr funktioniert, da hierbei die NamensListe der einzelnen Werte nicht mehr gespeichert wird.

Man kann hier dafür den ordinalen Wert speichern und nahezu beliebig festlegen,
aber Namen nur noch über eine selbst definierte Liste. (nicht aus der RTTI auslesbar)

[TiGü]

Uiuiui, da wird wieder mit den dicksten Kanonen auf kleinste Spatzen geschossen!

Die Idee von Nuclearping ist die simpelste und wahrscheinlich am schnellsten umsetzbare Lösung.

Ggf. kann man das noch per Pseudonamespaces und Klassen schöner verpacken:

Delphi-Quellcode:

  TLifeForms = class
  public type
    TAnimal = class
    public type
      TMammal = (Dog = 1, Cat = 27, Mouse = 15);
    end;

    TPlants = class
    public type
      TRoses = (DogRose = 23, RugosaRose = 58);
    end;
  end;

[Sir Rufo]

Zitat von TiGü:

Uiuiui, da wird wieder mit den dicksten Kanonen auf kleinste Spatzen geschossen!

Die Idee von Nuclearping ist die simpelste und wahrscheinlich am schnellsten umsetzbare Lösung.

Schnell und simpel ja, allerdings hat man nicht die gesamte Vereinbarung (wie hier mit einem externen System) in einem Objekt gekapselt und auch das Erzeugen über eine Id ist umständlicher.

Hier wird auch ein sehr simples Beispiel angeführt. In der Realität sind diese ValueObjects aber wesentlich komplexer (z.B. Währung). Teilweise können diese Werte weggelassen werden, weil kein Pflichtfeld und sind dann einfach nil oder bekommen einen Dummy-Wert zugewiesen (TTier.KeinTier) oder es wird nicht übergeben und dann wird automatisch der Dummy-Wert zurückgegeben.

Es ist dann schön, wenn man ein Konzept hat, was alle diese Anforderungen erfüllen kann und die Handhabung immer gleich ist.

Auch kann man ValueObjects (egal welchen Typs) einfach in eine Liste (z.B. Tags) packen.

Delphi-Quellcode:

TSomeObject = class
private
  FTags : TList<TValueObject>;
public
  procedure AddTag( ATag : TValueObject );
end;

SomeObject.Add( TTier.Create(5) );
SomeObject.Add( TColorInfo.Create( clRed ) );
...

Das die Klasse aufwändig ist und nicht zu den schnell mal eben hingetippten zählt ist mir durchaus bewusst, allerdings auch die Flexibilität und die Abgeschlossenheit in sich und ich kann mich jederzeit darauf verlassen, dass nur valide Werte ankommen.

Es hängt vom Einsatzgebiet und den zu erwartenden Erweiterungen ab ob ich so etwas ins Rennen bringe, je komplexer das System umso eher nehme ich solche Konstrukte.