C++ mit Pure Interfaces Interfaces oder "mixed Implementierung"

[Gast]

Hallo,

gibt es vernünftige Argumente für das erste oder das zweite Szenario? Das erste ist ein sauberes, abstraktes Interface im eigentlichen Sinne... und ohne eigene Implementierung. Mit dem Nachteil das prinzipiell jede Implementierung den gleichen Teil implementieren muss und es richtig machen muss... sonst funktioniert der Kram nicht. Das zweite hat eigene Implementierung mit reingemischt und verschmiert damit die Interface Definition

Oder gibt es noch ein drittes Szenario? Den Implementierungsteil z.B. in eine Implementierung CFoo : public IFoo auszulagern und von CFoo zu erben? Irgendwie begegnen einem immer wieder die einen oder anderen Konstrukte dieser Art und mir ist nie ganz klar, was wann zu bevorzugen ist bzw. die Vorteile sind.

class IFoo {
public:
virtual void process( const B& ptr ) = 0;
virtual void setOutput( IOutput_ptr& p ) = 0;
virtual IOutput_ptr getOutput() = 0;
}


class IFoo {
public:
~IFoo() {};
virtual void process( const B& ptr ) = 0;
virtual void setOutput( IOutput_ptr& p ) {
this->output=p;
};
virtual IOutput_ptr getOutput() {
return this->output;
};
protected:
IOutput_ptr output;
}

btw: Oder brauch ich im ersten Beispiel etwa auch einen virtuellen Destruktur? Auch wenn die Klasse keine eigenen Member hat?

[Baalzamon]

Ich verstehe irgendwie das Problem nicht so ganz.

Im Grunde genommen sind es einfach zwei unterschiedliche Anwendungsfälle, ein mal ein Interface und einmal eine abstrakte Klasse.

Zumal es in C++ das Konstrukt der 'pure virtual Class' überhaupt nicht gibt, in deinem ersten Beispiel wird automatisch ein Standardkonstruktor und -destruktor angelegt.

[pest]

btw: Oder brauch ich im ersten Beispiel etwa auch einen virtuellen Destruktur? Auch wenn die Klasse keine eigenen Member hat?

was hat das damit zu tun?

[Ectoplasma]

btw: Oder brauch ich im ersten Beispiel etwa auch einen virtuellen Destruktur? Auch wenn die Klasse keine eigenen Member hat?

Ja brauchst du, bzw. solltest du besser haben, sonst wird der Destruktor eines Implementierers deines Interfces IFoo nicht durchlaufen, wenn du folgendes übliches Konstrukt hast:


IFoo* pIFoo = new IFooImpl;

delete pIFoo;

[Coda]

C++11 fügt übrigens automatisch einen leeren virtuellen Destruktor ein, falls die Klasse eine VTable hat, wenn ich mich richtig entsinne.

[Gast]

Ich verstehe irgendwie das Problem nicht so ganz.

Im Grunde genommen sind es einfach zwei unterschiedliche Anwendungsfälle, ein mal ein Interface und einmal eine abstrakte Klasse.Ja... es wird aber ähnlich verwendet. Beides taugt um eine Menge an Implementierungen hinter einem Interface zusammenzufassen.

Und bei diesem Vorgehen frage ich mich was Vorteile hat... der Ansatz eines echten Interfaces oder einer abstrakten Klasse.

[Gast]

was hat das damit zu tun?Erstmal nichts... es war mir nur in dem Zusammenhang beim Schreiben eingefallen.
Ja brauchst du, bzw. solltest du besser haben, Danke!
C++11 fügt übrigens automatisch einen leeren virtuellen Destruktor ein, falls die Klasse eine VTable hat, wenn ich mich richtig entsinne.Das ist interessant! Jetzt müßte ich noch rausfinden ob VS2010 diesen Teil von C++11 implementiert. :)

[Nasenbaer]

Schon en bissl alt der Thread aber ich geb auch mal meinen Senf dazu:

Erstmal hab ich hier ne Liste was VS 2010 und 2012 an C++11 implementieren:
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

Dann halte ich es so, dass ich immer so viel wie möglich so früh (d.h. so weit unten in der Klassenhierarchie) implementiere wie möglich. Also hab ich fast nie ein reines Interface, sondern meistens immer mindetens eine Methode, die ich bereits in der Basisklasse implementiert ist. Diese sind dann auch meist nicht virtuell, weil die Notwendigkeit nicht besteht.