Die Speicherung habe ich nicht thematisiert, sondern deine Verwendung des Begriffs "Konstante", wo du doch eigentlich "Variable" meintest.
Deutsche Sprache <> Delphi.
In der deutschen Sprache sind Interpretationen Gott-Sei-Dank erlaubt. Ich definiere eine 'Konstante' übrigens als Wert, der im Anwendungskontext nicht verändert wird. Diese Interpretation lässt mir die Freiheit, in einer Spezifikation den Terminus 'Konstante' zu verwenden, ohne gerichtlich einklagbar darauf drängen zu müssen, das dieser Wert im Code auch als 'CONST' deklariert werden muss. Es reicht, wenn er während des Lebenszyklus der Anwendung nicht veränderbar ist, und das schließt initiales Laden aus. Gleichzeitig verbaue ich mir damit nicht die Möglichkeit des initialen Ladens. Aber wenn Du dich dran reibst, dann wende dich an Emba:
Delphi-Quellcode:
Const
IAmNotAConstant : Integer = 3;
begin
{$J+}
IAmNotAConstant := 4; // Verbooooten !!!1!!!!11!!!EINS!!!11!!ELF!!!
Im Übrigen bin ich auch für korrekte Terminologie, aber nur, wenn es um wichtige Dinge geht. Auch kann ich verstehen, das in der reinen Sprachenlehre eine Konstante nicht immer eine Konstante ist. Aber dann ist sie eigentlich auch keine Variable, denn verändert wird sie nicht (nur initialiert).
Zitat von
Heraklit von Ephesus:
Die einzige Konstante im Universum ist die Veränderung.
Zum Thema: Ich hätte da noch statische Klasseneigengeschaften anzubieten. Bei Applikationskonstanten etwa so:
Delphi-Quellcode:
Type
Unit ApplicationSettings;
Interface
Type
TApplicationContext =
Class
private
class var fMySetting :
string;
class var fSomeOtherValue : Integer;
class procedure Load();
public
Class property MySetting :
String read fMySetting;
class property SomeOtherValue : Integer
read fSomeOtherValue;
end;
...
implementation
...
initialization
TApplicationContext.Load();
end.
Diese
Unit bindest Du einfach immer dann ein, wenn Du Zugriff auf die Applikationskonstanten benötigst. Du hast hier dann alles, was Du brauchst. Damit wäre deine erste Vorgabe erfüllt:
Zitat:
Die Werte sollten zudem irgendwie gruppiert sein, damit man damit leichter arbeiten kann (Autovervollständigung, Parameter-Eingrenzung).
Für dein konkretes Beispiel der Tiere (das nur bedingt etwas mit dem generellen Problem der Applikationskonstanten zu tun hat) sollte man zunächst klarstellen, das die einzelnen Tiere eindeutige Identifikatoren (Id) besitzen, die eben nicht änderbar sind (also eine Perlsau'sche Konstante). Hier hat man immer das Dilemma, das man einfach darauf hoffen muss, das sich die Anwendungen an die Konvention halten, einem Hund immer die ID 1 zuzuweisen usw.
Ich würde meine TTier-Klasse wie folgt umsetzen, und dabei die von Sir Rufo vorgeschlagenen value objects einsetzen. Die Methode 'GetTierName' gehört dann zum Tier (
OOP) und ist keine isolierte Funktion (PP)
Delphi-Quellcode:
Type
TTier = class
private
fID: Integer;
fName : String;
class var fKatze: TTier;
class var fHund: TTier;
class procedure Load;
constructor Create (aID : Integer; Name : String);
public
property ID : Integer read fID;
property Name : String read fName;
class property Hund : TTier Read fHund;
class property Katze : TTier Read fKatze;
end;
{ TTier }
constructor TTier.Create(aID: Integer);
begin
fID := aID;
end;
class procedure TTier.Load;
begin
// Natürlich wird hier aus einer Datei/Registry/Datenbank geladen
fHund := TTier.Create(3,'Hund');
fKatze := TTier.Create(4,'Mitzekatze');
end;
initialization
TTier.Load;
end.
Und damit solltest Du alle deine Wünsche umsetzen können, denn eine Katze ist ein Tier, konstant, die Id ist Perlsau-konform (sofern man die Datei nicht verändert, siehe Heraklit) und deine Tiere können um Methoden und Eigenschaften erweitert werden, was bei einem Enum nicht geht. Ich persönlich halte auch nicht viel von
RTTI-Geraffel im Hintergrund.