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?

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.

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

Hier zeigt Rob, wie's geht.

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

Zitat von NamenLozer:

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

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.

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

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

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.

[del]