Interfaces und Properties

[Windwalker]

Hallo zusammen,

ich entwerfe gerade einiges Klassen und zugehörige Interfaces.
Wie verhält es sich denn mit Properties und deren Setter- und Getter-Methoden in Bezug auf Sichtbarkeit?

Als Beispiel hier folgendes kleine Interface und eine implementierende Klasse aufgeführt:

Delphi-Quellcode:

IMyInterface = Interface
  function get_Feld: string;
  procedure set_Feld(s: string);  
  property Feld: string read get_Feld write set_Feld;
end;

TMyClass = class(IMyInterface)
private
  fFeld : string;
  function get_Feld: string;
  procedure set_Feld(s: string);
public
  property Feld: string read get_Feld write set_Feld;

Die Deklaration der Property im Interface verlangt ja auch die Deklaration der Getter- und Setter-Methoden im Interface.
Meine Frage nun:
Hat das "Private" denn nun noch eine Auswirkung auf die Sichtbarkeit der Getter- und Setter-Methoden oder werden sie durch die Deklaration im Interface automatisch "public"?

Wäre ja blöd...
Mein Kollege meint, dem wäre so, denn das sei ein Design-Problem von Delphi.

Danke für die Hilfe!

[Bernhard Geyer]

Was wäre der Sinn davon ein Interface zu haben das versteckte Methoden hat?
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.

AFAIK gibt es keine Sprache die Interface mit private/protected Methoden unterstützt.

[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.

Delphi-Quellcode:

IMyInterfaceInternal = Interface
  function get_Feld: string;
  procedure set_Feld(s: string);
end;

IMyInterface = Interface(IMyInterfaceInternal)
  property Feld: string read get_Feld write set_Feld;
end;

TMyClass = class(TInterfacedObject, IMyInterface)
private
  fFeld : string;
  function get_Feld: string;
  procedure set_Feld(s: string);
public
  property Feld: string read get_Feld write set_Feld;

@Bernhard Geyer:
Für micht ergab dieses ein übersichtlicheres Interface, vorallem bei der Autovervollständigung von Delphi.

[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.

[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.

[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.