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.