Interface et structure de conception de l'implémentation?

Question

Je suis relativement nouveau dans la conception de grands programmes en C++. J'écris des séries d'opérations, chacune ayant sa propre classe, qui sera invoquée par la classe ProcessMgr.

J'utilise ProcessMgr en tant que classe d'interface, à partir de laquelle chaque opération peut être invoquée:

class ProcessMgr 
{ 
private: 
    class OperationOne; 
    class OperationTwo; 
    class OperationThree; 
} 

class ProcessMgr::OperationOne 
{ 
public: 
    ... 
}; 
class ProcessMgr::OperationTwo 
{ 
public: 
    ... 
}; 
class ProcessMgr::OperationThree 
{ 
public: 
    ... 
}; 

Cela me permet de contrôler les types d'accès aux Operation des classes, donc pas d'exposer une grande partie de leur sous-jacent code.

Il est important que l'utilisateur de ce code ne peut interagir avec les Operation des classes de manière spécifique et ne pas avoir un accès complet à tous les contenus des Operations classes.

Mes questions:

1) Est-ce une bonne approche pour la conception de grands programmes? La plupart des bibliothèques, telles que CURL, sont-elles structurées de cette manière?

2) Existe-t-il des méthodes de séparation et d'implémentation meilleures/plus efficaces?

Answer 1

Une interface normale en C++ (ou d'autres langages OOP) fournit les définitions. Les "classes-opérations" doivent être dérivées de l'interface, de sorte que vous découpliez l'implémentation du client. Ce principe est appelé Dependency inversion principle(DIP).

Un UML-schéma commun du DIP se présente comme suit:

Étant donné que le client est tout simplement familier avec l'interface, vous pouvez contrôler l'accès aux sous-classes spécifiques. Une mise en œuvre pourrait ressembler à ceci:

class ProcessMgr { 
    virtual void foo() = 0; 
    virutal void bar() = 0; 
} 

class Operation1 : public ProcessMgr { 
    virtual void foo() { ... } 
    virtual void bar() { ... } 
} 

class Operation2 : public ProcessMgr { 
    virtual void foo() { ... } 
    virtual void bar() { ... } 
} 

Le DIP est un principe d'une série de très bons principes, appelé SOLID. Pour concevoir de grands projets, il y a beaucoup plus à faire et à apprendre. Mais les principes SOLID sont un bon début pour comprendre comment concevoir des applications logicielles.