Est-ce une mauvaise pratique d'utiliser des classes co-dépendantes?

Question

Si j'ai une classe Container qui contient un tas d'objets Component (similaire au framework UI de Java), est-ce que ce serait un mauvais style/pratique de garder une trace du parent Container dans chaque Component? Cela finit par provoquer des problèmes de compilation étranges car le Component inclut le fichier d'en-tête Container et vice-versa. Même avec une correction de garde d'en-tête, je finis par devoir déclarer un prototype class Component; au-dessus de l'en-tête Container, et de même pour Component.

Il semble que vous ayez à passer pas mal de temps pour obtenir une interaction bidirectionnelle entre deux classes. Serait-il conseillé de chercher une autre solution au problème que la co-dépendance "résout" ou est-ce que cette implémentation alambiquée est attendue de C++ et que je devrais juste l'aspirer?

EDIT: Peut-être qu'un contexte/raisonnement aiderait. La raison pour laquelle j'utilise cette co-dépendance est que je dois notifier le parent quand le destructeur d'un enfant a été appelé (afin qu'il puisse être retiré de la liste des enfants), et j'ai aussi besoin d'avoir la position dessinée de l'enfant être relatif à celui du parent.

Merci,
Jengerer

Answer 1

En fait, je pense que c'est un problème de conception. Vous devriez vraiment regarder le design dans son ensemble et voir si vous pouvez le concevoir mieux. Demandez-vous pourquoi vous avez les classes dépendantes nécessitant un accès au conteneur. Peut-être que le conteneur fournit des fonctionnalités qu'il ne devrait pas. Cette fonctionnalité peut-elle être fournie d'une autre manière?

Answer 2

Il est généralement préférable d'avoir pas de telles dépendances cycliques: ils sont un peu d'une douleur au code, frustrer le raisonnement logique sur le code, etc .. testabilité

Ils peut être facilement évité de toute façon - vous pouvez garder certains foncteurs dans les Composants, les pointer sur les opérations Conteneur appropriées aux événements traités, ou dériver le Conteneur d'une interface abstraite, ainsi les Composants peuvent avoir un pointeur vers lui et le Conteneur en dériver. Ou bien les composants peuvent être stockés par un pointeur (intelligent), avec un type dérivé implémentant des gestionnaires d'événements virtuels personnalisés pour le conteneur. Il y a beaucoup d'autres possibilités, par ex. Si vous voulez éviter le surcoût lié à l'exécution, prenez en compte les classes de stratégies CRTP ou de modèle.

Answer 3

Avoir un composant garder un pointeur sur son parent est largement utilisé, et je ne le vois pas comme une mauvaise pratique. Il peut être utilisé pour une variété de choses, du travail des arbres de widgets à la manipulation des composants perdus ou fui. Pour contourner le problème avec le compilateur, vous devez soit placer les lignes d'inclusion dans les protections d'en-tête, soit avoir un troisième fichier avec des déclarations directes pour les deux classes (dans l'espace de noms approprié).

J'ai vu ce dernier fait dans quelques grandes bibliothèques OO, et il est généralement inclus dans presque tous les autres fichiers du projet. Bien que cela puisse conduire à un peu de pollution de l'espace de noms, cela présente certains avantages (sans avoir besoin d'inclure la définition de classe complète ou les dépendances d'une autre classe juste pour avoir un pointeur dessus).

Widget.hpp:

#include "Library.hpp" 

namespace MyLibrary 
{ 
    class Widget 
    { 
    private: 
     Window * parent; 
    }; 
} 

fenêtre.HPP:

#include "Library.hpp" 

namespace MyLibrary 
{ 
    class Window 
    { 
    private: 
     std::vector<Widget*> widgets; 
    }; 
} 

Library.hpp:

namespace MyLibrary 
{ 
    class Window; 
    class Widget; 
}