Wie deklariert man eine Schnittstelle in C++?

Question

Wie kann ich eine Klasse einrichten, die eine Schnittstelle darstellt? Ist dies nur eine abstrakte Basisklasse?

Answer 1

Meine Antwort ist im Grunde dieselbe wie die der anderen, aber ich denke, es gibt noch zwei weitere wichtige Dinge zu tun:

1. Deklarieren Sie einen virtuellen Destruktor in Ihrer Schnittstelle oder erstellen Sie einen geschützten nicht-virtuellen Destruktor, um undefiniertes Verhalten zu vermeiden, wenn jemand versucht, ein Objekt des Typs IDemo .

2. Verwenden Sie die virtuelle Vererbung, um Probleme bei der Mehrfachvererbung zu vermeiden. (Bei der Verwendung von Schnittstellen kommt es häufiger zu Mehrfachvererbung).

Und wie andere Antworten:

• Erstellen Sie eine Klasse mit rein virtuellen Methoden.

• Verwenden Sie die Schnittstelle, indem Sie eine andere Klasse erstellen, die diese virtuellen Methoden außer Kraft setzt.

  class IDemo
  {
      public:
          virtual void OverrideMe() = 0;
          virtual ~IDemo() {}
  }

  O

  class IDemo
  {
      public:
          virtual void OverrideMe() = 0;
      protected:
          ~IDemo() {}
  }

  Und

  class Child : virtual public IDemo
  {
      public:
          virtual void OverrideMe()
          {
              //do stuff
          }
  }

Answer 2

In C++11 können Sie die Vererbung leicht ganz vermeiden:

struct Interface {
  explicit Interface(SomeType& other)
  : foo([=](){ return other.my_foo(); }), 
    bar([=](){ return other.my_bar(); }), /*...*/ {}
  explicit Interface(SomeOtherType& other)
  : foo([=](){ return other.some_foo(); }), 
    bar([=](){ return other.some_bar(); }), /*...*/ {}
  // you can add more types here...

  // or use a generic constructor:
  template<class T>
  explicit Interface(T& other)
  : foo([=](){ return other.foo(); }), 
    bar([=](){ return other.bar(); }), /*...*/ {}

  const std::function<void(std::string)> foo;
  const std::function<void(std::string)> bar;
  // ...
};

In diesem Fall hat eine Schnittstelle Referenzsemantik, d.h. man muss sicherstellen, dass das Objekt die Schnittstelle überlebt (es ist auch möglich, Schnittstellen mit Wertsemantik zu erstellen).

Diese Arten von Schnittstellen haben ihre Vor- und Nachteile:

• Sie mehr Speicherplatz benötigen als vererbungsbasierter Polymorphismus.
• Sie sind im Allgemeinen schneller als vererbungsbasierter Polymorphismus.
• In den Fällen, in denen Sie den endgültigen Typ kennen, sie sind viel schneller! (einige Compiler wie gcc und clang führen mehr Optimierungen in Typen durch, die keine Typen mit virtuellen Funktionen haben bzw. von ihnen erben).

Schließlich ist die Vererbung die Wurzel allen Übels bei der Entwicklung komplexer Software. Unter Sean Parents Wertesemantik und konzeptbasierte Polymorphie (sehr empfehlenswert, dort werden bessere Versionen dieser Technik erläutert) wird der folgende Fall untersucht:

Angenommen, ich habe eine Anwendung, in der ich meine Formen polymorph mit der MyShape Schnittstelle:

struct MyShape { virtual void my_draw() = 0; };
struct Circle : MyShape { void my_draw() { /* ... */ } };
// more shapes: e.g. triangle

In Ihrer Anwendung tun Sie dasselbe mit verschiedenen Formen, indem Sie die YourShape Schnittstelle:

struct YourShape { virtual void your_draw() = 0; };
struct Square : YourShape { void your_draw() { /* ... */ } };
/// some more shapes here...

Nehmen wir nun an, Sie möchten einige der von mir entwickelten Formen in Ihrer Anwendung verwenden. Vom Konzept her haben unsere Formen die gleiche Schnittstelle, aber damit meine Formen in Ihrer Anwendung funktionieren, müssten Sie meine Formen wie folgt erweitern:

struct Circle : MyShape, YourShape { 
  void my_draw() { /*stays the same*/ };
  void your_draw() { my_draw(); }
};

Erstens ist es vielleicht gar nicht möglich, meine Formen zu ändern. Außerdem führt die Mehrfachvererbung zu Spaghetti-Code (stellen Sie sich vor, es kommt ein drittes Projekt hinzu, das die TheirShape Schnittstelle... was passiert, wenn sie auch ihre Zeichenfunktion aufrufen my_draw ?).

Update: Es gibt ein paar neue Referenzen über Polymorphismus, der nicht auf Vererbung basiert:

• Sean Parent's Vererbung ist die Basisklasse des Übels sprechen.
• Sean Parent's Wertesemantik und konzeptbasierter Polymorphismus sprechen.
• Pyry Jahkola's Vererbungsfreier Polymorphismus Gespräch und die Dokumente der Polybibliothek .
• Zach Laine's Pragmatische Typenlöschung: Lösung von OOP-Problemen mit einem eleganten Entwurfsmuster sprechen.
• Andrzejs C++ Blog - Teile von Type Erasure i , ii , iii y iv .
• Polymorphe generische Programmierung zur Laufzeit - Mischen von Objekten und Konzepten in ConceptC++
• Boost.TypeErasure-Dokumente
• Adobe Poly Dokumente
• Boost.Any , std::any Vorschlag (Revision 3) , Boost.Spirit::hold_any .

Answer 3

Alle oben genannten Antworten sind gut. Eine zusätzliche Sache, die Sie im Auge behalten sollten - Sie können auch einen rein virtuellen Destruktor haben. Der einzige Unterschied ist, dass Sie ihn noch implementieren müssen.

Verwirrt?

    --- header file ----
    class foo {
    public:
      foo() {;}
      virtual ~foo() = 0;

      virtual bool overrideMe() {return false;}
    };

    ---- source ----
    foo::~foo()
    {
    }

Der Hauptgrund, warum Sie dies tun sollten, ist, wenn Sie, wie ich, Schnittstellenmethoden bereitstellen möchten, deren Überschreibung aber optional ist.

Um die Klasse zu einer Schnittstellenklasse zu machen, ist eine rein virtuelle Methode erforderlich, aber alle Ihre virtuellen Methoden haben Standardimplementierungen, so dass die einzige Methode, die noch rein virtuell gemacht werden muss, der Destruktor ist.

Die Reimplementierung eines Destruktors in der abgeleiteten Klasse ist überhaupt keine große Sache - ich reimplementiere immer einen Destruktor, ob virtuell oder nicht, in meinen abgeleiteten Klassen.

Answer 4

Sie können auch Vertragsklassen in Betracht ziehen, die mit dem NVI (Non Virtual Interface Pattern) implementiert werden. Zum Beispiel:

struct Contract1 : boost::noncopyable
{
    virtual ~Contract1() = default;
    void f(Parameters p) {
        assert(checkFPreconditions(p)&&"Contract1::f, pre-condition failure");
        // + class invariants.
        do_f(p);
        // Check post-conditions + class invariants.
    }
private:
    virtual void do_f(Parameters p) = 0;
};
...
class Concrete : public Contract1, public Contract2
{
private:
    void do_f(Parameters p) override; // From contract 1.
    void do_g(Parameters p) override; // From contract 2.
};

Answer 5

Wenn Sie den C++-Compiler von Microsoft verwenden, können Sie wie folgt vorgehen:

struct __declspec(novtable) IFoo
{
    virtual void Bar() = 0;
};

class Child : public IFoo
{
public:
    virtual void Bar() override { /* Do Something */ }
}

Ich mag diesen Ansatz, weil er zu einem viel kleineren Schnittstellencode führt und die Größe des generierten Codes deutlich geringer sein kann. Die Verwendung von novtable entfernt alle Verweise auf den vtable-Zeiger in dieser Klasse, so dass Sie ihn niemals direkt instanziieren können. Siehe die Dokumentation hier - novable .