Classe abstraite vs Interface en C++ [dupliquer]

je suppose qu'avec interface vous voulez dire une Classe C++ avec seulement méthodes purement virtuelles (i.e. sans aucun code), au lieu de classe abstraite vous voulez dire une Classe C++ avec des méthodes virtuelles qui peuvent être dépassées, et certains codes, mais au moins une méthode virtuelle pure qui rend la classe non instantible. par exemple:

class MyInterface
{
public:
  // Empty virtual destructor for proper cleanup
  virtual ~MyInterface() {}

  virtual void Method1() = 0;
  virtual void Method2() = 0;
};


class MyAbstractClass
{
public:
  virtual ~MyAbstractClass();

  virtual void Method1();
  virtual void Method2();
  void Method3();

  virtual void Method4() = 0; // make MyAbstractClass not instantiable
};

dans Windows programming, les interfaces sont fondamentales dans COM . En fait , un composant COM exporte uniquement des interfaces (c'est-à-dire des pointeurs vers V-tables , c'est-à-dire des pointeurs vers un ensemble de pointeurs de fonction). Cela aide à définir un ABI (Application binaire Interface) qui permet par exemple de construire un composant COM en C++ et de l'utiliser dans Visual Basic, ou de construire un composant COM en C et de l'utiliser en C++, ou de construire un composant COM avec Visual C++ version X et utilisez-le avec Visual C++ version Y. En d'autres termes, avec les interfaces, vous avez un découplage élevé entre le code client et le code serveur.

de plus, lorsque vous voulez construire des DLL avec une interface orientée objet C++ (au lieu de C DLL pure), comme décrit dans cet article , il est préférable d'exporter interfaces (l '"approche mature") au lieu de classes c++ (c'est essentiellement ce que COM fait, mais sans le fardeau de COM infrastructure.)

j'utiliserais une interface si je veux définir un ensemble de règles à l'aide desquelles un composant peut être programmé, sans spécifier un comportement particulier concret. Les Classes qui implémentent cette interface fourniront elles-mêmes un comportement concret.

à la place, j'utiliserais une classe abstraite quand je veux fournir une certaine valeur par défaut code d'infrastructure et le comportement, et rendre possible au code client de dériver de cette classe abstraite, en supplantant les méthodes virtuelles pures avec du code personnalisé, et complète ce comportement avec du code personnalisé. Pensez par exemple à une infrastructure pour une application OpenGL. Vous pouvez définir une classe abstraite qui initialise OpenGL, met en place l'environnement window, etc. et puis vous pouvez dériver de cette classe et implémenter du code personnalisé pour par exemple le processus de rendu et la gestion des entrées utilisateur:

// Abstract class for an OpenGL app.
// Creates rendering window, initializes OpenGL; 
// client code must derive from it 
// and implement rendering and user input.
class OpenGLApp
{
public:
  OpenGLApp();
  virtual ~OpenGLApp();
  ...

  // Run the app    
  void Run();


  // <---- This behavior must be implemented by the client ---->

  // Rendering
  virtual void Render() = 0;

  // Handle user input
  // (returns false to quit, true to continue looping)
  virtual bool HandleInput() = 0;

  // <--------------------------------------------------------->


private:
  //
  // Some infrastructure code
  //
  ... 
  void CreateRenderingWindow();
  void CreateOpenGLContext();
  void SwapBuffers();
};


class MyOpenGLDemo : public OpenGLApp
{
public:
  MyOpenGLDemo();
  virtual ~MyOpenGLDemo();

  // Rendering
  virtual void Render();  // implements rendering code

  // Handle user input
  virtual bool HandleInput(); // implements user input handling


  //  ... some other stuff
};