Ich mache es ein klein wenig anders als oki:
bei mir ist TDataList NICHT von TObjectList abgeleitet sondern ANTHÄLT eine TObjectList:
Delphi-Quellcode:
type
TDataList = class
private
FList: TObjectList;
function GetCount: Integer; // gibt FList.Count zurück
function GetItem(Index: Integer): TMyData; // gibt FList[i] as TMyData zurück
...
public
constructor Create; // erstellt die Liste mit FList := TObjectList.Create(True{AOwnsObjects});
destructor Destroy; // löscht die Liste mit FList.Free;
procedure Clear; // ruft FList.Clear auf
property Count: Integer read GetCount;
property Items[Index: Integer]: TMyData read GetItem;
...
end;
Nachteil: Ich muss alle Funktionen die ich aus der ObjectList brauche nochmal schreiben (Clear usw), die Inhalte sind aber kurz da sie ja nur die entsprechenden FList-Funktionen aufrufen (FList.Clear usw).
Vorteil: Der Benutzer dieser Klasse (das kann ja ein ganz anderer Programmierer sein) kann in diese Liste nur die von mir gewünschten Objekte einfügen, also beispielsweise nur TMyData. Andere Klassen werden - anders als beim Ableiten von TObjectList - nicht angenommen. Dafür entfällt dann der Typecast (bei oki die Zeile Data := TMyData(self.Items[Index]); die besser Data := Items[Index] as TMyData wäre aber nun Data := Items[Index] sein muss).
Wie oki das macht hab ich's früher auch gemacht, aber die Erfahrung lehrt mich, dass das zu fehlerträchtig und zuwenig flexibel ist. Ich will auch gar nicht alle public-Funktionen von TObjectList anbieten, sondern nur einen Teil, den ich dann teilweise auch verändern möchte.