Klasse die benötigte Klasse erstellt

[Sascha L]

Hallo,

der Titel passt nicht unbedingt, aber ich wusste nicht, wie ich es anders in Kurzform ausdrücken sollte.

Ich habe eine Hauptklasse "TParser":

Delphi-Quellcode:

TParser = class(TPersistent)
    private
      fFeedItem : TFeedItem;
      fFeed: TFeed;
      fFeedType: TFeedType;
      fXMLDoc: IXMLDocument;
      procedure GetFeedType;
    public
      constructor Create(XMLDoc: TStream); virtual;
      property FeedType: TFeedType read fFeedType write fFeedType;
  end;

Das ist nur ein kleiner Teil und die Klasse ist mehr oder weniger noch ohne Funktion.

Von dieser leite ich dann ab und habe z.B. dann die Klassen TRSSParser, TAtomParser, TRDFParser, usw.

In den Unterklassen werden dann später die entsprechenden abstrakten Prozeduren überschrieben und mit Inhalt gefüllt, sodass ich die entsprechenden XML-Dateien auslesen kann.

Nun zum eigentlichen Problem: Wenn die ganzen Klassen später fertig sind, soll es so einfach wie nur möglich sein, einen Feed zu parsen. Wenn ich das nun so alles lasse, müsste man im Hauptprogramm z.B. beim Öffnen einer XML-Datei immer erst überprüfen, um was für einen Feed-Typ es sich handelt und demendsprechend dann TRSSParser.Create, TAtomParser.Create, etc. machen.

Am besten wäre es ja, wenn man einfach nur TIrgendwas.Create machen würde und dann die entsprechende Klasse erstellt wird.

Gibt es dafür irgendeine "coole" Lösung? Die einzige, nicht so schöne, die mir einfällt wäre eine Funktion, der ich die XML-Datei übermittel, die dann halt überprüft, um was es sich handelt und dann die entsprechende Klasse erstellt und zurückliefert.

Gruß
Sascha

[OregonGhost]

Ungefähr so wird es auch gemacht. Du kannst dir eine "professionelle" Lösung dafür im .NET-Framework anschauen, genauso wird es nämlich bei der WebRequest-Klasse gemacht. Diese hat eine statische Methode Create (kein Konstruktor), die als Parameter die zu öffnende URI übernimmt und dann die entsprechende Ableitung instanziiert, also z.B. HttpWebRequest oder FtpWebRequest. Ist zwar, wie ich finde, nicht die allersauberste Lösung (weil die Basisklasse über ihre Ableitungen Bescheid wissen muss), aber es ist recht praktisch.
In deinem Fall ist es ja vermutlich so, dass deine Klasse den XML-Code so oder so runterladen muss, das kann die Basisklasse ja schon machen, und dann anhand der ersten Zeilen, also DTD, Schema oder Root-Element, wie auch immer, ermitteln kann, an welchen Parser das ganze übergeben werden muss.

[3_of_8]

Mach es wie bei TPicture: Polymorphie.

Du bastelst dir einen Wrapper, der einen TParser enthält und per property nach außen anbietet. Der überprüft dann, was für eine Art von Datei es ist und erzeugt dann den entsprechenden Parser.

[Khabarakh]

Siehe auch Factory-Pattern.

[add]

Zitat von 3_of_8:

Mach es wie bei TPicture: Polymorphie.

Benutzt er doch schon längst . Und eine Factory-Klasse benötigt meistens keine Polymorphie.
[/add]

[OregonGhost]

TPicture geht doch den umgekehrten Weg, oder? Man lädt beliebige Daten rein, und bekommt dann anhand einer Eigenschaft genau das Format, das man will (falls es verfügbar ist). Hier geht es aber doch darum, beliebige Daten reinzuladen, und dann in einem standardisierten Format die Daten zu bekommen. Da würde ich eher keinen extra Wrapper für bauen, das ist ja nur eine Indirektion, die dem Benutzer hier nicht viel bringt (finde ich).

Edit roter Kasten:
Das ist zwar das Factory-Pattern, aber ich halte es in diesem Fall für, naja, zu viel, eine extra Klasse dafür zu haben. Ist dann eben ein kleiner Unterschied in der Ausrichtung, im einen Fall ist die statische Create-Methode ein Implementierungsdetail (für den Fall, dass der Benutzer eh nie mit den abgeleiteten Klassen selbst arbeiten soll), im anderen Fall ist die Factory das Implementierungsdetail von außen, das man unabhängig von der Basisklasse ändern kann, aber das auch eine zusätzlich Indirektion bedeutet, die hier eventuell nicht benötigt wird.
Edit roter Kasten 2:
Factory-Klasse hat doch Polymorphie, weil sie eine Ableitung einer Basisklasse zurückliefert (oder Implementierung einer Schnittstelle), oder?

Merkt man eigentlich, dass ich selbst hier mehr lerne als ich anderen erzähle? ^^

[Jelly]

Ich hatte mal ein ähnliches Problem, bei dem ich auch dynamisch festlegen musste, welche Klasse denn nun letztendlich instantiert werden muss.... Hier ist die Lösung, mit der ich dann das Ganze umgesetzt habe: mit Metaklassen.

[Sascha L]

Danke für eure Hilfen!!

Ich habe nun folgende Lösung, mit der ich zufrieden bin und die gleichzeitig sogar mehr Funktionalität hat:

Delphi-Quellcode:

  TFeedParser = class(TPersistent)
    private
      fFeeds: TList;
      function GetFeed(Index: Integer): TParser;
    public
      constructor Create;
      destructor Destroy;
      procedure AddFeed(XMLDoc: TStream);
      property Feeds[Index: Integer]: TParser read GetFeed;
  end;

Bei "AddFeed" wird dann überprüft um was für einen Feed es sich handelt und dann demendsprechend z.B. TRSSParser hinzugefügt.

Das klappt einwandfrei und das tolle ist, dass ich nun sogar mehrere und vor allem unterschiedliche Feeds hinzufügen kann, ohne z.B. einen Array zu erstellen

[Khabarakh]

Zitat von OregonGhost:

Das ist zwar das Factory-Pattern, aber ich halte es in diesem Fall für, naja, zu viel, eine extra Klasse dafür zu haben.

Für die funktion des Patterns ist es ziemlich irrelevant, ob es nun als statische Methode in der Basisklasse oder in einer eigenen Klasse implementiert ist. Ich würde wahrscheinlich Letzteres wählen, da ich die Benutzung der abgeleiteten Klassen in ihrer Basisklasse etwas unschön fände.

Zitat:

Factory-Klasse hat doch Polymorphie, weil sie eine Ableitung einer Basisklasse zurückliefert (oder Implementierung einer Schnittstelle), oder?

Wie gesagt, den Teil hat er doch schon . Aber die Factory-Klasse selbst ist bei einfachen Implementationen meist statisch (nicht ganz so simples Gegenbeispiel wäre System.Data.Common.DbProviderFactory/Factories).

@Jelly: Kommt ganz darauf an, wie generisch die Factory werden soll. Wenn es bei den vier, fünf Klassen bleibt, kann man die auch noch hart in die Factory coden.

[Jelly]

Zitat von Sascha L:

Das klappt einwandfrei und das tolle ist, dass ich nun sogar mehrere und vor allem unterschiedliche Feeds hinzufügen kann, ohne z.B. einen Array zu erstellen

Das mag auf den ersten Blick einfach erscheinen, aber Du hast jetzt immer 2 Stellen an denen Du pflegen musst, wenn mal ein neuer XMLParser hinzukommt. Dann musst Du nämlich nicht nur die neue Klasse implementieren, sondern auch die AddFeed Methode aus deiner TFeedParser Klasse.

Hast Du meinen Link gelesen?

[OregonGhost]

Zitat:

Für die funktion des Patterns ist es ziemlich irrelevant, ob es nun als statische Methode in der Basisklasse oder in einer eigenen Klasse implementiert ist. Ich würde wahrscheinlich Letzteres wählen, da ich die Benutzung der abgeleiteten Klassen in ihrer Basisklasse etwas unschön fände.

D.h., die Implementierung wie im WebRequest ist genau genommen auch das Factory-Pattern?
Wie ich schon sagte, im Normalfall fände ich die Benutzung der abgeleiteten Klasse auch unschön, aber in diesem Fall handelt es sich in meinen Augen um reine Implementierungsdetails, die dem Benutzer egal sein können. Wobei Sascha L ja ohnehin eine interessante Variante gefunden hat.

Zitat von Jelly:

Das mag auf den ersten Blick einfach erscheinen, aber Du hast jetzt immer 2 Stellen an denen Du pflegen musst, wenn mal ein neuer XMLParser hinzukommt. Dann musst Du nämlich nicht nur die neue Klasse implementieren, sondern auch die AddFeed Methode aus deiner TFeedParser Klasse.

Hmm, muss man beim Metaklassen-Prinzip nicht die ID der Klasse kennen? Sprich, man müsste auch zwei Stellen pflegen? Das mit den Metaklassen ist doch vom Prinzip her ähnlich wie COM-Instanziierung, oder sehe ich das falsch?