inner/nested interface

Hallo zusammen,

ich bin letztens über ein Codeschnipsel gestolpert, das mir doch etwas merkwürdig vorkam. Da wurde ein abstraktes Interface innerhalb eines anderen Interfaces deklariert. Also ein nested Interface sozusagen. Ähnliches hab ich auch schon in einer nicht abstrakten Klasse sehen können (also Interface nested in einer Klasse).

Gemeint ist sowas hier:

class IFoo
{
public:
   class IBar
   {
   public:
      virtual void fBar() = 0;
   }

   virtual void fFoo() = 0;
};

Leider hält sich Google ziemlich bedeckt, was das Thema angeht. Es gibt nur Beispiele aus der Java-Welt, z.B. Map.Entry. Daher ein paar Fragen dazu:

- Wozu sollte man das machen? Kennt jemand Beweggründe dafür? Leider kenne ich den Kontext des Codeschnipsels nicht mehr, deshalb kann ich nicht sagen, was da der Anwendungsfall war. Für mich sah es nur sehr ungewohnt aus.

- Warum finde ich in Verbindung mit C++ dazu nichts? Weil es blödsinn ist? Weil noch niemand auf die Idee gekommen ist?

Habt vielen Dank,
robert

Nennt sich nested classes und haben auch schon andere vor dir entdeckt (http://en.cppreference.com/w/cpp/language/nested_types). Ist praktisch um Details der Implementierung zu verstecken.

Columbo

Es geht im AFAICS mehr darum, dass diese verschachtelte Klasse abstrakt ist, und die sie umgebende genauso.

Richtig. Es ging mir nur darum, warum man ein Interface in eine Klasse oder in ein weiteres Interface packen sollte. Ich war der Ansicht, dass gerade ein Interface für die Außenwelt bestimmt sei

Also wir mir scheint, steckt da nicht viel Magic dahinter...

rob#rt schrieb:

Also wir mir scheint, steckt da nicht viel Magic dahinter...

Nein, ist ja auch programmieren und nicht zaubern ...

Dein Beispiel wird aber wohl auch nicht so ganz passen. Im Original gibt eine Funktion des äußeren Interfaces bestimmt eine Instanz des inneren Interfaces zurück.

Finnegan

rob#rt schrieb:

Richtig. Es ging mir nur darum, warum man ein Interface in eine Klasse oder in ein weiteres Interface packen sollte. Ich war der Ansicht, dass gerade ein Interface für die Außenwelt bestimmt sei

Ich sehe in dem "für die Außenwelt bestimmt" keinen Widerspruch, wenn das Interface public ist. Du hast doch selbst mit dem Map.Entry ein Beispiel für ein solches Interface gegeben, das ich persönlich ganz sinnvoll finde: Warum nicht zusammenpacken was zusammen gehört, wenn es z.B. keinen Sinn macht dass ein Map-Entry auch für sich alleine existiert, ohne dass jemals eine Map ins Spiel kommt?

Und wenn die Map schon ein Interface ist, dann kann es durchaus auch sinnvoll sein, dass der Entry ebenfalls eines ist, da in konkreten Maps die Einträge wahrscheinlich unterschiedliche interne Eigenschaften haben werden.

Ich sehe bei so einem Map.Entry eine ganz ähnliche Design-Motivation wie z.B. bei einigen eingebetteten Typen die man in den Container-Klassen der Standardbibliothek findet: bspw. std::vector<int>::iterator oder std::map<int, int>::iterator . Die Typen gehöhren logisch zu ihren jeweiligen Container-Typen, und sie können alle iterator heissen, weshalb man sie auch alle recht leicht finden kann, wenn man weiss wie der Container-Typ heisst. Ich denke bei deinem IFoo::IBar -Beispiel hat sich wahrscheilich jemand ähnliche Gedanken gemacht.

Finnegan

volkard

Ich könnt mir ne abstrakte Memberklasse in Sachen Strategy-Pattern verstellen vielleicht. Zusammen mit Merkels und Finnegans Leitspruch "Warum nicht zusammenpacken was zusammen gehört".

hustbaer

Ja, vermutlich einfach ne Stilfrage.
Namespace-Pollution vermeiden.
Technischen Grund sehe ich da keinen wenn die inner class eine reine "Interfaceklasse" ist.

Finnegan schrieb:

Warum nicht zusammenpacken was zusammen gehört

Damit habt ihr sicher recht
Ich dachte einfach, dem liegt irgendetwas besonderes zugrunde, wovon ich noch nichts gehört hab. Hab ich einfach so noch nicht gesehen.

Danke für die Gedanken zu dem Thema.
Robert