Sowohl TMyClass als auch TMyOtherClass leiten die Implementierung des Interfaces an die Instanz einer anderen Klasse TDumpToJSON weiter, die interessanterweise über IDumpToJSON gar nichts weiß.
Der Nachteil hierbei ist allerdings, dass du hier die Abhängigkeit TDumpToJSON an alle deine IDumpToJSON fähigen Klassen hardcodest.
Und außerdem muss das TDumpToJSON nun für alle Klassen wissen, wie sie zu dumpen sind (wohlmöglich über
RTTI, klar das geht).
Aber dann würde ich fragen, warum muss die dann in dem Objekt drin sein und warum muss son Objekt das Interface implementieren?
Bei nem bisschen Stringgematsche für JSON mag das noch harmlos sein, aber dann gehts los und jemand möchte die Instanzen in ner Datenbank speichern und schon haste irgendnen
SQL oder Datenbank Zeugs an allen deinen Objekten kleben.
Andere Ansätze sind oft, dass die Klasse, die persistierbar ist, nur die Informationen ausspuckt, die so ein Persistierer benötigt (z.B.
RTTI oder was selbstgebautes). Oder dass es ein Interface zum Persistierer übergeben bekommt und dann selbst seine Infos da rein schreibt.
Dann hast du maximal entkoppelte Klassen, so ne Liste oder Objekte wissen gar nix von ihrem Glück, persistierbar zu sein (möglicherweise nur über ihre
RTTI/Attribute) und du kannst sie dann an die jeweiligen Instanzen geben, die diesen Job übernehmen.
Misko geht
in diesem Artikel ein bisschen auf das Problem von diesen 2 Arten von Objekten ein - solche die einfach nur Daten halten (die er newable nennt) und solchen die wirkliche Arbeit durchführen (Injectables). Und welche Probleme bei der Architektur beim vermischen dieser beiden Arten passieren können.