Designfrage: Liste selber schreiben? Oder von TList oder TList<T> ableiten?

[mh166]

Hallo Leute,

ich bin im Moment gerade dabei für ein Projekt meine Klassen zu konzipieren und stehe dabei vor einer vermutlich eher trivialen Entscheidung. Dennoch würde ich gern eure Meinung dazu hören, ob ihr Argumente Für oder Wider habt — oder ob ihr der Meinung seid, dass es hier auf den persönlichen Geschmack ankommt.

Kurz zur Situation: ich habe verschiedene Klassen, für die ich jeweils Listen-Klassen erstellen möchte. Mal als Konzept in Pseudo-Code:

Delphi-Quellcode:

type
  TESPBase = class
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean; virtual;
    function DumpToJSON: String; virtual;
  end;

  TEmployee = class(TESPBase)
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean;
    function DumpToJSON: String;
    property ID: String;
    property FirstName: String;
    property LastName: String;
  end;

  TEmployeeList = class(TESPBase)
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean;
    function DumpToJSON: String;
    procedure Add(Elem: TEmployee);
    procedure Clear;
    procedure Delete(Index: Integer);
    procedure IndexOfID(SearchID: String);
    property Items[Index: Integer]: TEmployee;
    property ItemsByID[Index: String]: TEmployee;
  end;

Das soll jetzt mal als Beispiel dienen. Worum es mir jetzt geht: ich habe einige andere Klassen, die wie TEmployee im Beispiel, jeweils eine Listen-Klasse erhalten sollen. Im Großen und Ganzen unterscheiden diese sich jeweils nur durch diverse Properties und die Implementierung der Funktion LoadFromXML().

Ich würde an der Stelle jetzt eine Klasse TEspBaseList erstellen, von der ich dann sowohl TEmployeeList als auch alle anderen Listen ableiten kann.

Dafür sehe ich jetzt 3 Möglichkeiten:

1. Klasse TEspBaseList selbst schreiben
   Vorteil: Ich könnte mich beim Funktionsumfang auf das beschränken, was für mich erforderlich ist. Ableitung von TEspBase ist möglich.
   Nachteil: Muss eben selber geschrieben werden. Ist jetzt kein zu großer Nachteil, aber kostet halt doch Zeit.
2. Klasse TEspBaseList von TList ableiten
   Vorteil: Listenverwaltung komplett fertig und Einsatzbereit.
   Nachteil: Keine Ableitung von TEspBase möglich, da keine Mehrfachvererbung möglich ist.
3. Klasse TEspBaseList von TList<TEmployee> ableiten
   Vorteil: ... ich hab ehrlich gesagt keine Ahnung was der Vorteil gegenüber #2 ist ...
   Nachtteil: Wie auch bei #2: kein Nachfahre von TEspBase.

Was würdet ihr an meiner Stelle tun? Gibt es noch Vor- oder Nachteile an die ich nicht gedacht habe? Oder ist das wirklich eine reine Geschmackssache?

Vielen Dank schon mal!

Gruß, mh166

[Uwe Raabe]

Hast du schon mal daran gedacht, die Funktionalität von TESPBase in zwei Interfaces zu verlagern? Damit brauchst du nicht mehr die gemeinsame Basisklasse. Das befreit ungemein...

[mjustin]

Kleine Randbemerkung:

die Basisklasse

Delphi-Quellcode:

  TESPBase = class
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean; virtual;
    function DumpToJSON: String; virtual;
  end;

ist fest an eine andere Klasse TJclSimpleXMLElem gebunden. Und alle abgeleiteten Klassen ebenfalls. Was wäre, wenn statt Jcl einmal eine andere XML Bibliothek verwendet werden soll?

Die Basisklasse sollte von der Konvertierung des Objekts nach/von JSON/XML unabhängig sein.

Lesetipp: http://de.wikipedia.org/wiki/Prinzip...LID-Prinzipien

[Lemmy]

und dann noch die TList<> verwenden und nicht davon ableiten - dann hast Du noch weitere Freiheit dazu gewonnen...

[Der schöne Günther]

Ich mache selber immer noch zu viele Anfänger- und Deppenfehler um zu laut Ratschläge geben zu dürfen, aber:

• Ich kann mir nichts vorstellen dass es rechtfertigen würde, nicht von einer bereits vorhandenen und vielfach eingesetzten Standardklasse abzuleiten. Warum sollte man das Rad nochmal neu erfinden?
• Warum hat eine Liste plötzlich was mit JSON und XML zu tun? Was wirst du später alles noch drantackern? Deine Oracle-Datenbank? Eine Liste ist eine Liste. Nicht ein XML-Leser.
• Lies mal ein Tutorial über Generics. Eine normale TList nimmt nur Pointer (meine ich). Da kannst du alles reinstecken. Nimm doch eine generische Liste- Die ist soweit "fertig" dass sie nur mit deinen Angestellten-Objekten arbeitet.
• Grade bei weiteren Spezialfälle solltest du nicht von einer Liste ableiten, sondern an eine Liste (oder irgendeinen anderen Container) delegieren. Ob das Prinzip einen schnieken Namen (oder Abkürzung) hat weiß ich nicht.

[mjustin]

Zitat:

Zitat von Der schöne Günther (Beitrag 1271561)

Ich mache selber immer noch zu viele Anfänger- und Deppenfehler um zu laut Ratschläge geben zu dürfen, aber:

• Ich kann mir nichts vorstellen dass es rechtfertigen würde, nicht von einer bereits vorhandenen und vielfach eingesetzten Standardklasse abzuleiten. Warum sollte man das Rad nochmal neu erfinden?

Ja, TList<> verwenden ist sicher richtig, wie Lemmy sagte allerdings nicht davon ableiten sondern sie private Variable intern als Datenspeicher nutzen, und nach aussen nur fachlich notwendige Methoden veröffentlichen (Hinzufügen/Entfernen/Suchen).

Genau das:

Zitat:

Zitat von Der schöne Günther (Beitrag 1271561)

• Grade bei weiteren Spezialfälle solltest du nicht von einer Liste ableiten, sondern an eine Liste (oder irgendeinen anderen Container) delegieren. Ob das Prinzip einen schnieken Namen (oder Abkürzung) hat weiß ich nicht.

Information hiding ;), aber auch Open/Closed Prinzip

[Stevie]

Zitat:

Zitat von mjustin (Beitrag 1271562)

Ja, TList<> verwenden ist sicher richtig, wie Lemmy sagte allerdings nicht davon ableiten sondern sie private Variable intern als Datenspeicher nutzen, und nach aussen nur fachlich notwendige Methoden veröffentlichen (Hinzufügen/Entfernen/Suchen).

Ja dann aber bitte nicht immer wieder für jede Datenklasse, die man in einer Liste braucht sondern eine generische mit nem Constraint auf TESPBase:

Delphi-Quellcode:

type
  TESPBase = class
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean; virtual;
    function DumpToJSON: String; virtual;
  end;

  TEmployee = class(TESPBase)
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean;
    function DumpToJSON: String;
    property ID: String;
    property FirstName: String;
    property LastName: String;
  end;

  TESPBaseList<T: TESPBase> = class(TESPBase)
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean;
    function DumpToJSON: String;
    procedure Add(Elem: T);
    procedure Clear;
    procedure Delete(Index: Integer);
    procedure IndexOfID(SearchID: String);
    property Items[Index: Integer]: T;
    property ItemsByID[Index: String]: T;
  end;

  TEmployeeList = TESPBaseList<TEmployee>;

[mh166]

Zitat:

Zitat von Uwe Raabe (Beitrag 1271557)

Hast du schon mal daran gedacht, die Funktionalität von TESPBase in zwei Interfaces zu verlagern? Damit brauchst du nicht mehr die gemeinsame Basisklasse. Das befreit ungemein...

Darüber hatte ich auch nachgedacht. Allerdings sind Interfaces, soweit ich weiß, nur Vorgaben, welche Funktionen implementiert werden müssen. In meinem Fall wäre das ja weniger das Problem: ich kann ja zweimal das gleiche implementieren, wenn ich mag. Nur will ich genau das vermeiden: Ich hätte zweimal 1:1 den gleichen Code, nur für 2 verschiedene Klassen. So zumindest hab ich das mit den Interfaces verstanden.

Zitat:

Zitat von mjustin (Beitrag 1271558)

Kleine Randbemerkung:
die Basisklasse [...] ist fest an eine andere Klasse TJclSimpleXMLElem gebunden. Und alle abgeleiteten Klassen ebenfalls. Was wäre, wenn statt Jcl einmal eine andere XML Bibliothek verwendet werden soll?

Da geb ich dir grundsätzlich recht. In anderen Projekten, wo solch ein Austausch wahrscheinlich ist oder ich nicht allein dran arbeite, gebe ich auf sowas in der Tat auch Acht: ich schreibe dann entweder Abstraktionen oder Provider, die dann jeweils im Detail implementiert werden. Hier allerdings handelt es sich um ein vergleichsweise kleines Projekt für den privaten Gebrauch. Da ist ein Austausch der XML-Klasse eher unwahrscheinlich. :)

Zitat:

Zitat von Der schöne Günther (Beitrag 1271561)

Warum hat eine Liste plötzlich was mit JSON und XML zu tun? Was wirst du später alles noch drantackern? Deine Oracle-Datenbank? Eine Liste ist eine Liste. Nicht ein XML-Leser.

Die Liste wird nur auf zwei Wege befüllt: a) XML-Response von einem Webserver auslesen. Und b) Elemente aus a) in eine nächste Liste stecken. Dementsprechend finde ich das durchaus passend, die Methode in die Klasse einzubinden. Was den JSON anbelangt: das ist mehr oder minder eine Debug-Funktion, die mir den Inhalt der Listen und/oder Klassen liefert.
[/quote]

Zitat:

Zitat von Der schöne Günther (Beitrag 1271561)

Lies mal ein Tutorial über Generics. Eine normale TList nimmt nur Pointer (meine ich). Da kannst du alles reinstecken. Nimm doch eine generische Liste- Die ist soweit "fertig" dass sie nur mit deinen Angestellten-Objekten arbeitet.

Werde ich tun. :)

Zitat:

Zitat von Stevie (Beitrag 1271564)

Ja dann aber bitte nicht immer wieder für jede Datenklasse, die man in einer Liste braucht sondern eine generische mit nem Constraint auf TESPBase:

Delphi-Quellcode:

  TESPBaseList<T: TESPBase> = class(TESPBase)
    constructor Create;
    destructor Destroy;
    function LoadFromXML(xml: TJclSimpleXMLElem): Boolean;
    function DumpToJSON: String;
    procedure Add(Elem: T);
    procedure Clear;
    procedure Delete(Index: Integer);
    procedure IndexOfID(SearchID: String);
    property Items[Index: Integer]: T;
    property ItemsByID[Index: String]: T;
  end;

  TEmployeeList = TESPBaseList<TEmployee>;

Das sieht natürlich sehr hübsch aus. :)

[Uwe Raabe]

Zitat:

Zitat von mh166 (Beitrag 1271565)

Zitat:

Zitat von Uwe Raabe (Beitrag 1271557)

Hast du schon mal daran gedacht, die Funktionalität von TESPBase in zwei Interfaces zu verlagern? Damit brauchst du nicht mehr die gemeinsame Basisklasse. Das befreit ungemein...

Darüber hatte ich auch nachgedacht. Allerdings sind Interfaces, soweit ich weiß, nur Vorgaben, welche Funktionen implementiert werden müssen. In meinem Fall wäre das ja weniger das Problem: ich kann ja zweimal das gleiche implementieren, wenn ich mag. Nur will ich genau das vermeiden: Ich hätte zweimal 1:1 den gleichen Code, nur für 2 verschiedene Klassen. So zumindest hab ich das mit den Interfaces verstanden.

Solche Doppelimplementationen von Interfaces kann man dann wiederum mit einer Delegation auf eine andere implementierende Klasse auflösen (siehe reserviertes Wort implements).

BTW, könnte es sein, daß du in deinen abgeleiteten Klassen das override unterschlagen hast?

[Der schöne Günther]

Zitat:

Zitat von mh166 (Beitrag 1271565)

Die Liste wird nur auf zwei Wege befüllt: a) XML-Response von einem Webserver auslesen. Und b) Elemente aus a) in eine nächste Liste stecken. Dementsprechend finde ich das durchaus passend, die Methode in die Klasse einzubinden. Was den JSON anbelangt: das ist mehr oder minder eine Debug-Funktion, die mir den Inhalt der Listen und/oder Klassen liefert.

Ein- und Ausgabe von und nach irgendwohin tackere ich mir selbst auch oft an Klassen, die es eigentlich nicht haben sollten. Ich will dich davor bewahren, so zu enden wie ich:
Es ist, wie der Name schon sagt, eine Liste. Kein Webserver-Response-Ausleser. Irgendwann hast du einen Webserver, der dir die Daten anders formatiert. Dann musst du deine Liste von Arbeitnehmern anpassen, nur weil sich ein Webserver geändert hat?

Grade wenn man einmal damit angefangen hat verleitet es immer weiter, die Klasse mit Dingen aufzublähen die sie nicht haben sollte. Irgendwann kommt eine Methode

Delphi-Quellcode:

massenentlassung()

welche anhand von irgendwelchen Kriterien Arbeitnehmer auswählt und sie entfernt. Sie stecken zwar in der Liste, aber die Liste selbst hat auch nicht die Filterung zu treffen, wer entfernt wird. Das nur als Beispiel. Schuster, bleib bei deinen Listen (höhö).