Designfrage: Pest oder Cholera

[Patrick]

Ich habe da mal ne Designfrage: Auf diese Unschönheit bin ich jetzt schon öfter gestoßen:

Und zwar habe ich ein paar Basisklassen:
z.B. THaus, TGarten und TGarage. (Können auch mehr sein, die in Beziehung zueinander stehen (auch Vererbung).

Jetzt haben alle Klassen etwas gemeinsam:
Ich kann sie (oder Besser die Daten, die sie enthalten) z.B. als XML exportierten und sie in eine Datenbank speichern. Deshalb hat jede Klasse eine Methode SaveToDataBase(Query : TQuery) und eine Methode ExportToXML(XMLAccess : TXMLAccess);

Damit weiß jede Klasse nur das, was sie wissen muss. (Es gibt keinen Datenbank-"Blob" der alle Klassen kennt und das komplette speichern übernimmt.)
Und jede Klasse gibt nur so viel preis, wie sie muss. (Wie sie in die Datenbank gespeichert wird weiß jede Klasse selbst am Besten.)

Und jetzt habe ich zwei Programme, die die Basisklassen verwenden. Programm1 benutzt die Klassen in vollem Umfang. Programm2 hat allerdings keine Datenbank-Anbindung, weshalb die Methoden SaveToDataBase keinen Sinn machen und einen TQuery kennt das Programm daher auch nicht. Wenn beide Programme aber die selben Units verwenden sollen muss ich mit hässlichen Compilerschaltern arbeiten um die Datenbank-Methoden und entsprechende Units aus der Uses-List vor Programm2 zu verstecken.

Gibt es dafür nicht ne Bessere Lösung? Stimmt mein Design nicht?

[Phoenix]

Sicher aufwändig, aber machbar:

Entwerfe ein Interface IExporter und die Klassen bekommen beide nur noch eine Methode ExportTo(IExporter).

Du baust dann einen XMLExporter und einen DatabaseExporter, und nur diese beiden Klassen brauchen dann die XML-Lib bzw. die DB-Komponenten zu kennen.

Somit entkoppelst Du Deine Klassen komplett von der Persistenzschicht.

[Stevie]

RTTI und Attribute benutzen und deklarativ festlegen, was die Klassen exportieren.

Hier zeigt Rob, wie's geht.

[Namenloser]

Wären Class Helpers nicht eine Möglichkeit? Ansonsten fiele mir auch nix besseres ein als die Variante von Phoenix.

[Phoenix]

Zitat:

Zitat von NamenLozer (Beitrag 1107710)

auch nix besseres ein als die Variante von Phoenix.

Als ob das ein schlechter Vorschlag wäre ;-)
Allein schon gemäß des SRP sollte eine Klasse sowieso niemals irgendwelche Logik haben UND nach XML exportieren UND in eine Datenbank schreiben. Das sind drei 'Verantwortlichkeiten' bzw. Responsibilities und daher sollten das auch auf jeden Fall drei Klassen sein ;-)

[Blup]

Es bietet sich dieses Muster an: http://de.wikipedia.org/wiki/Visitor
Der Visitor kapselt ein bestimmtes Verhalten, z.B. das Speichern in eine Datenbank.

Für jede Klasse kann eine Hilfsklasse (z.B. THausDataBaseWriter) geschaffen werden,
die sowohl die Datenbank als auch die konkrete Datenklasse kennt.
Die Hilfsklasse wird beim Visitor registriert und von diesem benutzt, wenn er eine entsprechende Klasse besucht.

[DeddyH]

Zum Visitor Pattern kann man schön bei Uwe Raabe nachlesen.

[mschaefer]

Eigentlich ist das ein Compilerproblem. Wahrscheinlich kann man sowas nur mit MultiPassCompilern lösen.
Sonst denke ich auch, dass Phoenix einen guten Ansatz hat.

[himitsu]

Wenn es unbedingt direkt in der Klasse verfügbar sein muß, dann eben Class-Helper oder die bösen Generics.
Aber dieses Visitor-Patern, kann auch nicht schaden.

Oder einfach nur eine Vererbung:
- in der Basisklassen gibt es abstrakte Speichermethoden
- und dann in Ableitungen jeweils mit der entsprechenden Speichermethode versehen.

Visitor hat aber den Vorteil, daß du die Speicherklassen dann auch noch für andere Dinge wiederverwenden kannst.

[himitsu]

[del] :shock:

[stahli]

Dem Vorschlag von Stevie würde ich mich anschließen.

Daniel hatte in seinem D2010-Video die Propertyattribute und die neue RTTI vorgestellt.
Darauf aufbauend habe ich eine Objektserialisierung realisiert.
Einer Methode wird ein Objekt übergeben, das beim schreiben die "markierten Propertys" exportiert (MyProp=MyValue), bzw. beim einlesen prüft, ob eine markierte Property "MyProp" im Objekt existiert und weist dem MyValue zu.

Es muss also nicht für jedes Objekt eine spezifische Export/Import-Funktion geschrieben werden.

[BerndS]

Hallo,
ich würde das über "Unit-Aliasse" lösen und so die Klasse TQuery gegen eine Dummyklasse austauscht. Mache das bei Quickreport so, um TQuery durch TFIBDataset zu ersetzen.

Gruß Bernd

[himitsu]

Unit-Aliasse sind eher für "Notfälle" gedachtgeeignet.

Und was macht macht man, wenn mn an der einen Stelle in die XML speichern will und an anderer Stelle in die DB,
oder wenn es per Programm-Optionen umschaltbar sein soll?

[Stevie]

Schon amüsant (oder sollte ich sagen schockierend?), auf was für Ideen hier manche kommen (vor allem fast ausschließlich >=Delphi 2010 User) :shock:

[Iwo Asnet]

Der Vorschlag von Stevie ist was für Hacker. ;-) So würde ein guter IExporter umgesetzt werden.

Die Frage lautete doch aber, was vom Klassendesign besser ist.

Jeder Klasse ein 'ExportTo' zu spendieren, ist imho nicht ganz richtig (im Sinne der Ästhetik), denn einem Haus ist es egal, ob es sich irgendwo hin exportieren kann. Es steht einfach nur da und soll auch bei einem Sturm nicht umpurzeln (z.B.)

Wenn man das Haus exportieren will, beauftragt man einen Spezialisten, der das kann, nämlich einen, der die IExporter-Schnittstelle implementiert. WIE der das macht, und WAS er genau exportiert (Blaupause, Konzept, Hausbaukasten, Architekt etc.) ist wurscht.

Der Nachteil der Vorgehensweise, eine neues Verhalten in den Klassen zu hinterlegen ist der, das man Beziehungen schafft (TExportableClass), die rein logisch gar nicht vorhanden sind.

Was hat denn z.B. ein Haus mit einem Kuchen zu tun? Bloß weil beide exportierbar sind? Sie stehen aber in einer Beziehung, weil beide von TExportableClass abgeleitet sind.

Klar, man kann auch mit Interfaces arbeiten und implementiert dann kreuz und quer und je nach Lust und Laune mal hier ein IExportable, mal dort. Kraut & Rüben sind bei so einem Konzept im wahrsten Sinne des Wortes vorprogrammiert.

Ich lasse meine Klassen so kompakt und klein, wie es geht. Mit der Maxime hatte ich noch nie Probleme. Es ist manchmal nur etwas schwieriger, es 'richtig' zu machen. Dafür sieht so ein Klassenkonzept immer ordentlich aus und ist es auch.

[Stevie]

Zitat:

Zitat von Iwo Asnet (Beitrag 1107937)

Der Vorschlag von Stevie ist was für Hacker. Die Frage lautete doch aber, was vom Klassendesign besser ist.

Hacker? ROFL! Ich empfehle dir mal, das hier zu lesen, um nen Plan zu bekommen, was ich meinte.

P.S. Grundlagen der Serialisierung in .NET Framework

[implementation]

Zitat:

Zitat von Stevie (Beitrag 1107938)

das hier zu lesen

Katze Garfield :mrgreen::roteyes::spin:

[Iwo Asnet]

Zitat:

Zitat von Stevie (Beitrag 1107938)

Zitat:

Zitat von Iwo Asnet (Beitrag 1107937)

Der Vorschlag von Stevie ist was für Hacker. Die Frage lautete doch aber, was vom Klassendesign besser ist.

Hacker? ROFL! Ich empfehle dir mal,... zu lesen

Kenn ich doch.
ROFL? RTTT! (=Read The Thread Title): Hier gehts um Klassendesign (=Architekten), nicht um Implementierung (=Handwerker, Hacker).

[Stevie]

Mal vorweg: unabhängig von den aktuellen Meldungen um LulzSec und co empfinde ich persönlich Hacker als Beleidigung (mag damit zusammenhängen, dass mein Info Lehrer damals im Grundkurs Informatik uns immer so genannt hat, wenn wir ohne was aufs Papier zu schreiben die - natürlich simple - Lösung gleich runtercodiert haben) ;)

Ich habe übrigens nicht nur den Thread Titel gelesen, sondern auch den ganzen Post.
Dementsprechend ist die Nutzung der RTTI und/oder des ISerializable (oder wie du es auch sonst nennen willst) Interfaces für Standard und benutzerdefinierte Serialisierung durchaus eine Designentscheidung und hat erstmal nix mit der Implementierung zu tun.

Um dein Beispiel von dem Haus und dem Kuchen nochmal aufzugreifen, käme das Konzept über RTTI/Attribute der Bereitstellung eines Bauplans/Rezepts gleich, die diese Klasse gleich mitliefert aber dennnoch nichts direkt mit der Implementierung zu tun hat (in dem Programm, wo man keine Serialisierung braucht, kann man die RTTI auch ausschalten, wenn man mag).

Kritisch sehe ich ähnlich wie du im Sinne der Trennung die Implementierung des Interfaces, denn dann hast du wieder eine Abhängigkeit und sei es auch nur auf ein ISerializer, IExporter oder wie auch immer.

[Namenloser]

Zitat:

Zitat von Stevie (Beitrag 1107951)

Mal vorweg: unabhängig von den aktuellen Meldungen um LulzSec und co empfinde ich persönlich Hacker als Beleidigung

Wieso? Ein Hack ist eine unkonventionelle Lösung. Konventionell ist in diesem Fall das Anwenden von Design-Patterns etc., was u.U. einigen Overhead im Code zur Folge hat. Du hingegen benutzt einfach die die RTTI und sparst dir damit das ganze Gedöhns. Das könnte man schon irgendwie als „Hack“ bezeichnen. Aber das ist doch nix schlimmes...

[mkinzler]

[OT]Das ist halt ein Problem der Interpretation. Im Allgemeinen Sprachgebrauch wird aber Hacker und Cracker in einen Topf geworfen. Deshalb hat der Begriff a Gschmäckle, wie der Schwabe zu sagen pflegt.[/OT]

[Stevie]

Wenn man dieser Argumentation folgt, könnte man ja behaupten, dass die Benutzung von Reflektion ein Hack wäre und nicht der Anwendung von Design Patterns folgt - was ich gelinde gesagt als Unfug bezeichnen würde.