Das ist ein guter Einwand.
Wenn man aber die Instanziierung der Klassen (Erzeugen der Objekte) auslagert und fortan nur noch mit Interfaces arbeiten will, dann braucht man wiederum mächtige Interfaces, die die gesamte Funktionalität veröffentlichen.
Andernfalls müsste man immer prüfen, ob das vorliegende (Objekt-)Interface nun gerade zufällig IRead oder IWrite unterstützt, darauf casten und dann auf die Propertys zugreifen.
Andererseits bringt das natürlich auch wieder Vorteile, da man so sehr flexibel mit den Objekt-Interfaces umgehen kann.
Eigentlich bräuchte man dann IReadWrite gar nicht sondern würde einfach mit IInterface arbeiten:
Delphi-Quellcode:
var RW: IInterface;
X: Integer;
...
RW := TFactory.GetNewRW; // erzeugt ein TReadWrite und gibt es als IInterface zurück
...
if Supports(RW, IWrite) then
(RW as IWrite).WriteInt(1);
if Supports(RW, IRead) then
X := (RW as IRead).ReadInt;
// bzw. auch über Property
if Supports(RW, IWrite) then
RW.Int := 1;
if Supports(RW, IRead) then
X := (RW as IRead).Int;
Dann braucht man sich gar nicht mehr kümmern, was genau da für ein Objekt vorliegt (eigentlich ja der Sinn von Interfaces).
Wenn man sicher ist, was man übergibt kann man Supports ja notfalls weg lassen.
Alternativ könnte man natürlich noch Variablen wie R: IRead und W: IWrite einführen.
Auf jeden Fall könnte man auf mächtige Schnittstellen als Klassenkopien so verzichten.
Aktuell scheint mir der Ansatz eigentlich sinnvoll zu sein (kann sich aber wieder ändern
).
Ginge das so?