シングルドキュメントプロジェクトの構造

Question

プロジェクトに存在するメンバー変数にアクセスするための適切な方法について以前に尋ねました。このプロジェクトでは、私はCWinappから派生したクラス、CMainFrmクラス、異なるビュークラスのリストを持っています。しかし、現在、CWinApp派生クラスでインスタンス化された別のユーザー定義クラスのインスタンスがあり、残りのクラスはAfxGetApp（）関数から取得したポインターを使用し、別のユーザー定義クラスにアクセスします。私はMFCニュースグループのコミュニティメンバーから、これは非常に悪いデザインであると言われました（つまり、親クラスはアプリケーションクラス、ビュークラス、またはドキュメントクラスについて何も知ってはいけません）。しかし、私は、このデザインを使用せずにさまざまなユーザー定義のクラスにどのようにアクセスできるかについてはわかりません。私は適切な検索条件を思い付くためにMFCに精通していないので、いくつかの提案を聞くことは素晴らしいことです。

Answer 1

「（つまり、親がアプリクラス、ビュークラス、またはドキュメントクラスについて何を知っているべきではありません）」

私はこの文章を理解していない、あなたはここで「親」で何を意味しています？

とにかく、私の意見では、あなたが描いたデザインは本当に問題ではありません。トレードオフです：これらのクラスを必要とするすべての関数に渡すか、APIの使用やAPIを複雑にするか、グローバル変数のように格納しますか？アクセスされるデータとアクセス頻度によって異なります。多くの場所で必要とされるデータは、同様に「グローバル」である可能性があります。

データを「グローバル」にするには、CWinAppのメンバー（つまり、CWinApp派生クラス）またはCMainFrameのメンバーにするか、実際のグローバル変数を作成するか、シングルトンを作る...

グローバル変数の問題は、どこにどこからアクセスするのかを把握することが難しくなることです。あなたがCWinAppのメンバーとしてデータを持っていれば、アクセッサ関数を使ってデータにアクセスし、そこからのアクセスをトレースすることができます（ログメッセージ、ブレークポイントなど）。これは、グローバル変数に関連する問題のほとんどを緩和します。私が通常やっているのは、Lokiシングルトンを使うことです。

デカップリングの問題としてデータをCWinAppのメンバーにしていないというあなたのポストに記載されている理由は、少し奇妙なことです。特定のクラスにアクセスが必要な場合は、とにかくそれらのデータ構造を知る必要があり、その格納場所は無関係です。たぶん私はあなたのデザインの詳細を知らないからです。