Amitié mutuelle et pointeurs: Quel motif ou anti-pattern est-ce?

Question

En étudiant le C++ source d'une application énorme, je trouve ce modèle (la syntaxe pour l'exemple peut être peu précis, mais les détails essentiels sont là):

class A : X 
    friend B; 
    B *parent; 
    ...stuff... 

class B : Y 
    friend A; 
    A *myhelper; 
    ...stuff... 

Peut-être qu'il est significatif que la classe B est vraiment nommé AHelper, mais je suis plus curieux de connaître cette relation assez symétrique entre deux classes. Est-ce que cela fait partie d'un des modèles standard du GoF, ou d'un anti-pattern établi? Y a-t-il un concept ou une façon de comprendre cela en plus des détails, un tout plus grand que les parties?

Serait-il logique de combiner A et B en une seule classe? Il y a le sujet de chaque classe héritée des autres classes X, Y. J'ai hâte de refactoriser ce code pour le rendre plus facile à maintenir et plus petit.

Answer 1

Cela dépend de ce que font les classes. Si c'est quelque chose comme le modèle d'itérateur (c'est-à-dire std::vector<t> et std::vector<t>::iterator), alors il peut être utilisé pour quelque chose de bien. D'autre part, si les classes font des choses fondamentalement différentes, il est probablement préférable qu'elles soient seulement exposées les unes aux autres en utilisant leurs interfaces publiques. En d'autres termes, je ne pense pas que ce soit un motif ou un anti-pattern - cela dépend entièrement de l'utilisation des classes réelles en question.

Answer 2

A et B sont étroitement couplés mais leurs durées de vie peuvent être différentes. Il peut être utile de faire une classe si:

• A et B ont la même durée de vie, de sorte que l'un existe toujours avec l'autre.
• Il y a toujours une instance A pour chaque instance B et vice versa.

Il se pourrait cependant que ce ne soit pas le cas. Etant donné que A dérive de X et B dérive de Y, quand j'ai eu des classes couplées conjointement, ce sont normalement les classes de base qui sont couplées, et chaque classe n'interagit pas avec la classe concrète réelle de l'autre.

Dans ces cas, il ne s'agissait pas d'une seule relation de durée de vie. En fait, j'ai un objet maître qui crée et charge des objets plus petits qui reviennent au maître pour plus d'informations.

Je ne sais pas si le motif a un nom. Je n'ai jamais été chaud sur les noms de modèles de conception.