- Mettez certaines fonctions de la classe de conteneur en statique.
C'est ce qu'on peut appeler "au revoir OOP!" option et je m'abstiens de l'utiliser autant que possible.
- l'objet de classe de conteneur passe le pointeur sur lui-même (ce pointeur) pour le constructeur de classe contenue. À l'aide de ce pointeur, la classe contenue peut accéder aux méthodes de la classe conteneur.
A condition que la classe implémente une interface contenant et contenu des cours ne connaissent que l'interface, je ne vois pas de problème. En fait, c'est ce que je fais moi-même. Évidemment, il faut être conscient des pièges de l'approche, quand par exemple. l'objet contenu appelle la méthode du conteneur lors de la destruction de ce dernier (ou tout autre moment où le conteneur est dans un état intermédiaire).
Pour découpler davantage le contenu des classes contenant, des événements ou des messages pourraient également être utilisés. Les objets confinés ne savent pas où ils sont contenus, mais envoient des messages. L'objet contenant lors de la création des objets contenus s'enregistre lui-même en tant que destinataire des messages. Cette technique permet de rendre les objets littéralement indépendants, mais nécessite (1) un cadre de messagerie, (2) en raison de la nature statique de C++ plutôt élaborée à implémenter et (3) nécessite également un niveau de documentation supplémentaire en tant qu'interface de classes.
Sinon, réfléchissez à deux fois pourquoi les objets contenus doivent appeler les méthodes du conteneur. Se pourrait-il que vous ayez besoin de séparer certaines fonctionnalités génériques du conteneur en 3ème classe? Si les objets contenus sont bien les objets actifs et la source logique des événements dans le système, vous aurez peut-être besoin d'un système basique d'événements/messages pour permettre au conteneur d'interroger efficacement les changements d'état des objets contenus.
Je ne vois pas vraiment comment les associations bidirectionnelles ont quelque chose à voir avec le principe de responsabilité unique. Je peux penser à de nombreux cas où les associations bidirectionnelles sont utiles sinon obligatoires. Par exemple, dans les structures arborescentes (voir Composite), il est souvent utile d'avoir une référence au parent dans un nœud. –
Cela dépend plutôt de la situation. Dans un graphique, connaître les autres nœuds n'est pas une grosse affaire. Cependant, dans la plupart des autres cas, c'est une mauvaise idée. Les sockets ne devraient pas connaître le FD_SET dans lequel ils se trouvent, et si votre implémentation le fait, c'est parce que vos sockets font plus d'une chose qui viole la SRP. Ce n'est donc pas automatique non, mais 9 fois sur 10 ce n'est pas la bonne chose à faire. La plupart du temps quand je le vois, le conteneur est un conteneur et fait quelque chose d'autre où il devrait juste contenir un autre pair. – stonemetal
Je voudrais pouvoir supprimer mon downvote, puisque votre commentaire ajoute maintenant la nuance que je pensais manquer dans votre réponse, mais ce n'est plus possible :( –