それは「さようならOOP!」と呼べるものです。可能な限り使用を控えております。
- コンテナー クラス オブジェクトは、それ自体へのポインター (このポインター) を、含まれているクラス コンストラクターに渡します。このポインターを使用して、含まれるクラスはコンテナー クラスのメソッドにアクセスできます。
包含クラスがインターフェースを実装し、包含クラスがインターフェースしか認識していない場合、個人的には問題はないと思います。実際、それは私自身がしていることです。明らかに、アプローチの落とし穴に注意する必要があります。たとえば、含まれているオブジェクトがコンテナーの破棄中にコンテナーのメソッドを呼び出す場合 (または、コンテナーが中間状態にあるその他の瞬間) です。
含まれているものを含まれているクラスからさらに分離するには、イベントまたはメッセージも使用できます。収容されたオブジェクトは、どこに収容されているかを知りませんが、代わりにメッセージを送信します。包含オブジェクトを作成するとき、包含オブジェクトはそれらからのメッセージの受信者として自身を登録します。この手法により、オブジェクトを文字通り独立させることができますが、(1) 何らかのメッセージング フレームワークが必要であり、(2) C++ の静的な性質のために実装が複雑であり、(3) クラスのインターフェイスにメッセージングが含まれるようになったため、追加レベルのドキュメントも必要です。
それ以外の場合は、含まれているオブジェクトがコンテナーのメソッドを呼び出す必要がある理由をよく考えてください。コンテナからいくつかの一般的な機能を第 3 クラスに分割する必要があるのでしょうか? 含まれているオブジェクトが実際にアクティブなオブジェクトであり、システム内のイベントの論理ソースである場合、コンテナーが含まれているオブジェクトの状態変化を効率的にポーリング/監視できるようにするために、基本的なイベント/メッセージング システムが本当に必要になる場合があります。