Du willst offenbar eine fixe Gitterkomponente bauen. Interfaces würden Dir ermöglichen, die aktuellen Zellen irgendwann durch andere Klassen zu ersetzen. Außerdem würden die Zellen automatisch freigegeben, wenn sie nicht mehr genutzt werden.
Bei einer Gitterkomponente würde ich erst mal denken, dass beides nicht unbedingt notwendig ist. Der Gitterkomponente können ja ruhig alle TRow, TColumn und TCell bekannt sein und sie kann die entsprechenden Objekte in eigener Kontrolle erzeugen, verwalten und freigeben.
Das würde bedeuten, dass jemand Drittes keine Möglichkeit hätte die Default-Implementierungen von Spalte, Zeile und Zelle zu tauschen, außer er leitet von den Defaultklassen ab - und das bedeutet er muss das Verhalten ändern / überschreiben.
(Und warum IInvokable statt IInterface?)
Für Interception (Mocks), dann spar ich mir das $M+.
OK, wenn Interfaces, dann würde ich Weg 2 gehen.
Es handelt sich hier um direkte Eigenschaften der Klassen. ISelectable wird unterstützt, wenn es der Klasse zugewiesen ist. Fertig.
Genau da bin ich mir unschlüssig. So ist für jemand Dritten nicht sofort klar welche Interfaces z.B. eine Zellenimplementierung unterstützen muss um reibungslos in der Tabellenkomponente zu funktionieren (ein Cast schlägt z.B. fehl). Also angenommen er würde die Implementierung hinter ICell austauschen wollen. Oder nicht?
Im Weg 1 müsstest Du ein Objekt erzeugen und es ISelectable zuweisen. Sonst wäre es nil.
Das würde ich so anwenden, wenn man z.B. ein Auto zusammenbaut. Lenker und Motor können dann als Instanzen verwaltet werden. Auf dem Fließband ist der Motor zunächst noch nil. Erst zum Schluss wird eine Motorinstanz eingebaut.
Die Implementierung setzt natürlich voraus, dass die Eigenschaften niemals NIL sind.
Weg 3 würde ich ausschließen. Warum willst Du auf einmal mit Records arbeiten. (Kann sein, dass das machbar ist, aber das erscheint mir erst mal nicht ganz plausibel).
Die Idee war, in der Tabellenkomponente immer über Records auf die Instanzen von Row, Cell und Column zuzugreifen und dort alle untersützten Interfaces zu konsolidieren. Aber das gefällt mir auch nicht, da stimme ich Dir zu
