Tutorial Interfaces

[hoika]

Hm?
wieso privat?
Die Methoden müssen doch implementiert werden,
wenn sie privat wären, macht das doch keinen Sinn, oder?

[Fritzew]

Zitat:

wieso privat?
Die Methoden müssen doch implementiert werden,
wenn sie privat wären, macht das doch keinen Sinn, oder?

Interface Methoden sind immer aufrufbar, egal wo sie definiert sind.
Ich mache das immer so, dann lassen Sich die Funktionen nur über das Interface ansprechen, verhindert einfach dass man aus versehen Klassen-Instanzen und Interfaces mixed.
Als IInterface geht es als Tclass nicht

[Zacherl]

Zitat:

Zitat von hoika (Beitrag 1367408)

wieso privat?
Die Methoden müssen doch implementiert werden,
wenn sie privat wären, macht das doch keinen Sinn, oder?

Naja protected meinetwegen, um bei Klassen-Terminologie zu bleiben.

Zitat:

Zitat von Fritzew (Beitrag 1367409)

Interface Methoden sind immer aufrufbar, egal wo sie definiert sind.
Ich mache das immer so, dann lassen Sich die Funktionen nur über das Interface ansprechen, verhindert einfach dass man aus versehen Klassen-Instanzen und Interfaces mixed.
Als IInterface geht es als Tclass nicht

Hintergrund meiner Frage ist, dass ich Interfaces sehr gerne zum Vermeiden von zirkulären Unit-Referenzen bzw. "Super-Units" benutzen würde. Habe ab und zu mehrere Klassen, die sich "kennen" müssen und untereinander auf interne Methoden zugreifen. Öffentlich will ich diese Methoden nicht deklarieren, weil ein Zugriff von außen unerwünscht ist.

[Stevie]

Zitat:

Zitat von Zacherl (Beitrag 1367407)

Was ich mich schon länger frage: Gibt es eigentlich einen bestimmten Grund, warum Interfaces in Delphi keine privaten Methoden haben dürfen? Unter C++ ist das beispielsweise problemlos möglich.

Weil C++ keine Interfaces hat, sondern das alles (abstrakte) Klassen sind? Und Klassen haben nunmal Sichtbarkeiten.

[Zacherl]

Zitat:

Zitat von Stevie (Beitrag 1367431)

Zitat:

Zitat von Zacherl (Beitrag 1367407)

Was ich mich schon länger frage: Gibt es eigentlich einen bestimmten Grund, warum Interfaces in Delphi keine privaten Methoden haben dürfen? Unter C++ ist das beispielsweise problemlos möglich.

Weil C++ keine Interfaces hat, sondern das alles (abstrakte) Klassen sind? Und Klassen haben nunmal Sichtbarkeiten.

Das weiß ich, aber dank multiple-inheritance ist es ja dennoch 1 zu 1 das Gleiche. Mit dem C++ Vergleich wollte ich aber auch nur ausdrücken, dass es technisch auf jeden Fall möglich ist und ich mich deshalb wundere, dass Delphi hier eine Einschränkung vorgibt.

[Uwe Raabe]

Zitat:

Zitat von Zacherl (Beitrag 1367419)

Hintergrund meiner Frage ist, dass ich Interfaces sehr gerne zum Vermeiden von zirkulären Unit-Referenzen bzw. "Super-Units" benutzen würde. Habe ab und zu mehrere Klassen, die sich "kennen" müssen und untereinander auf interne Methoden zugreifen. Öffentlich will ich diese Methoden nicht deklarieren, weil ein Zugriff von außen unerwünscht ist.

Dann deklariere die Interfaces in zwei Units: eine mit den öffentlichen und eine mit den protected. Streng genommen sind protected Methoden bei Klassen auch keine saubere Lösung für eine solche Trennung (was ja durch ein strict protected auch forciert werden kann). Insofern ist das eh nur eine Konvention und die kannst du auf uses-Ebene ebenso gut (oder schlecht) durchsetzen.

[Zacherl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1367434)

Zitat:

Zitat von Zacherl (Beitrag 1367419)

Hintergrund meiner Frage ist, dass ich Interfaces sehr gerne zum Vermeiden von zirkulären Unit-Referenzen bzw. "Super-Units" benutzen würde. Habe ab und zu mehrere Klassen, die sich "kennen" müssen und untereinander auf interne Methoden zugreifen. Öffentlich will ich diese Methoden nicht deklarieren, weil ein Zugriff von außen unerwünscht ist.

Dann deklariere die Interfaces in zwei Units: eine mit den öffentlichen und eine mit den protected. Streng genommen sind protected Methoden bei Klassen auch keine saubere Lösung für eine solche Trennung (was ja durch ein strict protected auch forciert werden kann). Insofern ist das eh nur eine Konvention und die kannst du auf uses-Ebene ebenso gut (oder schlecht) durchsetzen.

Ja, vielleicht bin ich da einfach zu penibel. Ich gehöre auch tatsächlich zu den ca. 10 Leuten weltweit, die konsequent

Delphi-Quellcode:

strict private

verwenden.

[Stevie]

Zitat:

Zitat von Zacherl (Beitrag 1367439)

Ja, vielleicht bin ich da einfach zu penibel. Ich gehöre auch tatsächlich zu den ca. 10 Leuten weltweit, die konsequent

Delphi-Quellcode:

strict private

verwenden.

Wenn die Class completion da nich immer drauf schei*** würde, wär ich der elfte.

[delphirocks]

Interfaces haben in C++ normalerweise auch keine privaten Member, sonder sind als public pure abstrakte Methoden implementiert.

Ich denke da gibt es keinen grossen Unterschied zu Delphi:

Code:

struct IWriter {  // structs immer public
   virtual void Write() = 0;
};

class FileWriter : public IWriter {
public:
   void Write() override { doTheWriting(); }
};

[hph97]

Warum funktioniert das Beispiel von DeddyH nur, wenn alles in der selben Unit implementiert ist? Wenn ich diesen kompletten Interface Teil in einer Unit2 auslagere so bekomme ich die Compiler Fehlermeldung "E2010 Inkompatible Typen IDisplay und TEdit".