Der grundlegende Denk-Fehler ist, dass du der Meinung bist, in der Anwendung
alles Mögliche über das Interface geben zu müssen. Aber eben genau diese Implementations-spezifischen Informationen habe dort nichts verloren.
Nehmen wir mal den ganz simplen Fall, dass wir einfach nur einen Text versenden wollen. Dann sähe das interface so aus
Delphi-Quellcode:
IMy_MQ = interface
procedure Send( const AText : string );
end;
So, jetzt wollen wir diesen Text wie in deinem Beispiel über MSMQ versenden:
Delphi-Quellcode:
procedure TForm1.Button2Click(Sender: TObject);
var
mq: IMy_MQ;
//Interface
begin
mq := TMy_MSMQ.Create( '
DIRECT=OS:.\Private$\Test', MQ_RECEIVE_ACCESS, MQ_DENY_NONE );
//Objekt vom Typ "TMy_MSMQ"
mq.Send( '
Mal was senden' );
end;
In der Implementierung von
TMy_MSMQ
kann ich doch nun ganz gemütlich überprüfen, ob die Queue schon geöffnet wurde, wenn nicht, die Queue öffnen und einfach den Text versenden. Genauso eben auch Empfangen. Der Anwendung kann es wie gesagt völlig egal sein, was alles passieren muss, damit ein Text versendet werden kann. Das ist Aufgabe der Implementierung dieses entsprechend zu gewährleisten.
(Das das Beispiel jetzt nicht ganz passt, weil du hier eine Empfangs-Queue öffnen willst und ich etwas senden möchte weiß ich, es sollte aber den Ansatz hinreichend erklären).
Denk immer daran, wie das im wahren Leben funktioniert. Egal ob du mit UPS, DHL, Hermes, etc. ein Paket verschicken möchtest, bei allen ist folgendes gleich:
- Paket mit Inhalt
- Adresse
- kostet Geld
Die Unterschiede sind die Paketaufkleber und die Abgabestellen. Dein Interface ist jetzt der Mitarbeiter in der hauseigenen Poststelle. Dem gibst du das Paket und der kümmert sich um den Versand. Ob dann heute mit UPS, morgen mit DHL, übermorgen mit Hermes oder in ferner Zukunft per berittenem Boten das Paket transportiert wird, für die Mitarbeiter im Haus ändert sich nichts, denn die geben das Paket wie eh und je beim Mitarbeiter der Poststelle ab.
Das ist dann ein Interface
