Interfaces und Properties

[Windwalker]

Zitat von Bernhard Geyer:

Was wäre der Sinn davon ein Interface zu haben das versteckte Methoden hat?

Damit nicht direkt auf die Getter/Setter zugegriffen werden kann und man beim Instanzieren und Verwenden der Objekte gezwungen ist, über die Properties die Felder zu setzen und auszulesen.

wenn ich *nicht* von einem Interface ableite, ist das ja auch genau der Sinn hinter der Property.

Zitat von Bernhard Geyer:

Greifst du über das Interface auf die Klasse zu sind die Getter/Setter immer sichtbar.
Greifst du über das Objekt zu dann gelten die dortigen Sichtbarkeiten der Methoden.

Das habe ich mir fast so gedacht.
Eigentlich ist letzterer Fall der wünschenswerte.
Getter/Setter versteckt, alleinige Schnittstelle nach außen ist das Property.
Da ich ja aber auch den Vorteil des Reference Counting mir zunutze machen will, muss ich das Objekt als InterfacedObject instanzieren.
Und dann sind die Getter und Setter wieder sichtbar.

Zitat von himitsu:

Bei einem Interface ist alles so, als wäre es Public.

Ich hatte mir mal, zur Lösung dieses Problemchens, Folgendes überlegt, wärend ich damals die Interfaces für mein himXML zusammenstellte.
 ... Code entfernt ...

Dadurch sind die Getter und Setter aber immer noch nicht private, oder?
Weil dein äußeres IMyInterface nachwievor alles von IMyInterfaceInternal erbt.

[Bernhard Geyer]

Zitat von Windwalker:

Damit nicht direkt auf die Getter/Setter zugegriffen werden kann und man beim Instanzieren und Verwenden der Objekte gezwungen ist, über die Properties die Felder zu setzen und auszulesen.

Du weißt aber schon das beim Compilieren genau der umgekehrte Fall gemacht wird. Überall wo eine Property gesetzt wird, wird der entsprechende Setter aufgerufen. Entsprechend beim lesen.

Delphi macht es gegenüber Java schöner das man diese Getter/Setter-Methoden verstecken kann damit man weniger Schnittstelleneinträge (Anzahl Methoden+Properties) hat. Aber für Interfaces ist sowas in keiner Programmiersprache AFAIK vorgesehen.

[Windwalker]

Zitat von Bernhard Geyer:

Zitat von Windwalker:

Damit nicht direkt auf die Getter/Setter zugegriffen werden kann und man beim Instanzieren und Verwenden der Objekte gezwungen ist, über die Properties die Felder zu setzen und auszulesen.

Du weißt aber schon das beim Compilieren genau der umgekehrte Fall gemacht wird. Überall wo eine Property gesetzt wird, wird der entsprechende Setter aufgerufen. Entsprechend beim lesen.

Selbstverständlich!
Aus diesem Grund gibt es ja in Delphi die Properties, während man in Java/C++ direkt die Getter/Setter verwenden muss.

Natürlich ist es kein Beinbruch und v.a. auch kein Verlust an Funktionlität/Sicherheit, aber mindestens an Lesbarkeit ghet was verloren, wenn man die internen Felder eines Objekte nun sowohl über Property als auch Getter/Setter auslesen kann.

[himitsu]

Zitat von Windwalker:

Damit nicht direkt auf die Getter/Setter zugegriffen werden kann und man beim Instanzieren und Verwenden der Objekte gezwu

Ob man nun das Property nutzt oder direkt auf Getter/Setter zugreift, das macht intern keinerlei Unterschied.

Nur im externen Aufruf, also in der Nutzung sieht es anders aus.
Und da kann es manchmal schöner sein, wenn man einen Setter direkt nutzt.
Aber egal.

Wie gesagt, vom Programmfluß her ist es egal, ob man das Property oder den Getter/Setter nutzt ... man kann mit einer veränderten Sichtbarkeit und für mehr "Komfort" sorgen, oder in eine gewisse Richtung der Nutzung steuern, damit die Aufrufe einheitlicher werden.

Ganz verstecken kannst du keine Interfaceinhalte, denn was einmal sichtbar ist, dab bleibt auch irgendwo sichtbar.


Wenn das IMyInterfaceInternal nicht bei TMyClass aufgelistet ist, dann kann man von TMyClass nicht so einfach auf IMyInterfaceInternal casten und hat somit keinen direkten Zugriff darauf.


PS: Interface = offene Schnittstelle ... da ist, wie schon genannt, keine Versteckmöglichkeit vorhanden.