Nein, hat keine Nachteile (mein Vorschlag oben), mal davon abgesehen das deine ganze Objektorientierte Konstruktion insich falsch sein muß.
Wenn du über solche Sachen wie oben mein Typcast oder den Interfaces herangehen musst dann stimmt irgendwas nicht an deinem Grundkonzept.
Xaromz hat aber insofern Recht, das
1.) der Weg über die Interfaces ein unnötiger Überbau darstellt da wie in meinem Beispiel das Ganze auch ohne Interfaces geht
2.) du die Verwendung von Interfaces und Klassen nicht vermischen solltest da ansonsten das automatische Referencecounting und somit die Speicherfreigabe durcheinander kommt
3.) der Typcast eines Interfaces direkt in das implementierende Objekt in deinem Source vollkommen falsch ist
4.) der Typcast eines Interfaces in sein implementierendes Objekt grundsätzlich gegen die Regeln, bzw. dem Sinn der Interfaces ist
Wenn du schon eine Referenz von einem Interface auf sein implementierendes Objekt erhalten möchtest dann so:
Delphi-Quellcode:
type
IMyInterface = interface
function Implementor: TInterfacedObject;
end;
TMyImplementor = class(TInterfacedObject, IMyInterface)
function Implementor: TInterfacedObject;
end;
function TMyImplementor.Implementor: TInterfacedObject;
begin
Result := Self;
end;
// oder gleich so, da Result -> EAX und Self -> EAX
function TMyImplementor.Implementor: TInterfacedObject;
begin
end;
Aber!! zum Widersinnigen der Sache:
Interfaces sollen die Implementierung einer Funktionalität im Zusammenhang mit dessen Schnittstellen Deklaration vollständig voneinander trennen. Es soll also keinerlei Zusammenhang zwischen einer deklarierten Schnittstelle zu der eigentlichen Implementierung dieser Schnittstelle bestehen, vollkommene Abstraktion der verschiedenen Schichten eines Denkmodelles das zur "idealen" Black Box führt.
Führt man aber wie oben in die Schnittstelle = Interface wieder eine Schnittstelle auf den Implementor-> TMyInterfcae ein so durchbricht man diese strikte Logik und macht die Anwendung der Interfaces sinnnlos.
Denn die Deklaration von IMyInterface oben bedeutet das diese Schnittstelle nur durch ein Objekt kompatibel zur Klasse TInterfacedObject durchgeführt werden kann. Diese Restriktion soll aber gerade mit Interfaces strikt vermieden werden.
Ergo: ein normaler
OOP Ansatz wie in meinem letzten Posting erreicht exakt das Gleiche wie der Vorschlag über die Interfaces. Nur mit dem Unterschied
1.) das es Typsicher ist und somit sauber, wir eben keinen harten und typ-unsicheren Cast verwenden wie in deinen Sourcen
2.) ohne Umwege funktioniert und somit zusätzliche Fehlerquellen beseitigt. Bedenke die schlimmsten Fehler liegen immer im Konzept eines Modelles !
3.) kein Hilfsmittel misbraucht das für ganz andere Aufgaben gedacht ist, hier eben die Interfaces, und somit die spätere Verwenung deines Modelles für andere "korrekt denkende" Programmierer unmöglich macht. Denn für diese Programmierer ist es ein Unding wie du Interfaces mißbrauchen möchtest.
Grundsätzlich wird man aber deine Problemstellung durch pure
OOP und konzeptionelle Änderungen lösen können. Statt mit 2 Units zu arbeiten musst du
OOP konform dein Klassenkonzept umstellen und mit 3
Unit arbeiten.
1.
Unit -> Basisunit die eine abstrakte Vorfahrklasse enthält in der alle Gemeinsamkeiten der Nachfahrklassen deklariert wurden, meistens abstrakte Klassen. Sprich Klassen aus reiner Deklaration von abstrakten virtuellen Methoden ohne reale Implementierung.
2.
Unit -> Nachfahre Class1 von der Basisklasse und Verwendung von UnitClass2 in der Implementation Sektion dieser
Unit.
3.
Unit -> Nachfahre Class2 von der Basisklasse und Verwendung von UnitClass1 in der Implementation Sektion dieser
Unit.
Zitat:
Dieser Weg soll der sauberere sein,...
Ich werde wie gesagt den Quellcode erzeugen, also muss ich es nur einmal richtig hin bekommen, und alle interfaces sind richtig.
Wenn du davon überzeugt bist warum fragst du dann noch ? Ich meine, und damit bin ich nicht der Einzigste hier, das du mit dieser Meinung schon von vornherein deinen größten Fehler begehst. Begründungen siehe oben.
Gruß hagen