Properties in Interfaces

[Uwe Raabe]

Zitat von TBx:

Leg einfach den Getter und den Setter, den Du im Interface refernzierst, in der entsprechenden Klasse public an.

Warum jetzt gerade public?

Implementierungen von Interfaces können sogar private sein, solange sie nicht auch in abgeleiteten Klassen benötigt werden. Eigentlich ist das auch vorzuziehen, da diese Methoden von außen in der Regel nur über das Interface angesprochen werden sollen und nicht über die Klasseninstanz.

[Helmi]

Hallo,

also einfach functions und procedures anlegen und die dann im Host aufrufen?
Aber wie reagier ich in der BPL darauf?

[jaenicke]

Zitat von Helmi:

also einfach functions und procedures anlegen und die dann im Host aufrufen?
Aber wie reagier ich in der BPL darauf?

Wir machen das (bei DLLs, aber kommt auf das gleiche raus) so, dass wir eine Schnittstelle initialisieren, die dann in beide Richtungen Interfaces durchreicht.

Konkret gibt es im IHostInterface ein RegisterClient, das wiederum ein Interface weitergibt. Auf die Weise kann die Anwendung in beide Richtungen kommunizieren. Wir machen das dann so, dass wir in einer Methode GetInterface die GUID des benötigten Interfaces anfragen und dann die entsprechende Implementierung als Instanz zurückbekommen. So können wir über eine schlanke Schnittstelle sehr viel Funktionalität durchleiten.

Wir würden also konkret vom Host aus am Client z.B. einen ITimerManager anfragen, der dann z.B. eine Property TimerEnabled hat.

[Helmi]

Zitat von jaenicke:

Zitat von Helmi:

also einfach functions und procedures anlegen und die dann im Host aufrufen?
Aber wie reagier ich in der BPL darauf?

Wir machen das (bei DLLs, aber kommt auf das gleiche raus) so, dass wir eine Schnittstelle initialisieren, die dann in beide Richtungen Interfaces durchreicht.

Konkret gibt es im IHostInterface ein RegisterClient, das wiederum ein Interface weitergibt. Auf die Weise kann die Anwendung in beide Richtungen kommunizieren. Wir machen das dann so, dass wir in einer Methode GetInterface die GUID des benötigten Interfaces anfragen und dann die entsprechende Implementierung als Instanz zurückbekommen. So können wir über eine schlanke Schnittstelle sehr viel Funktionalität durchleiten.

Wir würden also konkret vom Host aus am Client z.B. einen ITimerManager anfragen, der dann z.B. eine Property TimerEnabled hat.

Könntest du mir ein kleines Beispiel basteln dafür?

[jaenicke]

Das hatte ich schon länger vor... ich weiß nicht, ob ich in den nächsten Tagen dazu komme.

[TBx]

Zitat von Uwe Raabe:

Implementierungen von Interfaces können sogar private sein

Ui, das war mir neu. Funktioniert aber, wie ich gerade feststelle.

Zitat von Uwe Raabe:

Eigentlich ist das auch vorzuziehen, da diese Methoden von außen in der Regel nur über das Interface angesprochen werden sollen und nicht über die Klasseninstanz.

Das leuchtet ein. Wieder was gelernt.

[Mavarik]

Zitat von Uwe Raabe:

Implementierungen von Interfaces können sogar private sein...

Ich setzte die "sogar" immer strict private...

2 Gründe:

1. Ich nutze sonst NIE strict private also ist es für mich ein "flag" die Methoden kommen aus einem Interface...
   Bedeutet, wenn meine Klasse zwei oder mehr Interfaces Implementiert, gibt es auch für jedes Interface eine eigene strict private Region.
2. Ich komme auch nicht auf die Idee innerhalb der Unit diese Methoden zu benutzen.

Mavarik

[jaenicke]

Ich mache die eher protected, aus dem einfachen Grund, dass sie dann in abgeleiteten Klassen auch erreichbar sind, nicht aber wie schon gesagt wurde von außen, wenn jemand versucht die Klassenreferenz statt der Interfacereferenz zu nutzen.

[freimatz]

Ich mache immer ein Property und nicht nur Getter und Setter - weil ich zu faul bin
Wenn ich ein property habe, dann kann das der MMX verwalten und ich muss es nicht tun.

Methoden die auf interface liegen machen wir in der Regel public, Getter und setter strict private.
An sich ist es aber relativ egal, weil die Klasse im Produktivcode eh keiner kennen darf sondern nur das interface.

Im übrigen finde ich es aber schlecht wenn solche Methoden proteced sind, damit Nachfahren diese kennen. Öffentliche Methoden sollen nie virtuell sein.

[sakura]

Zitat von freimatz:

Im übrigen finde ich es aber schlecht wenn solche Methoden proteced sind, damit Nachfahren diese kennen. Öffentliche Methoden sollen nie virtuell sein.

Protected ist nicht gleich Virtuell...

......