2
c ++モデルビュープレゼンター：プレゼンターを構築する場所は？
MFCプロジェクトでThe Humble Dialog Boxペーパー（pdf）に記載されているモデルビュープレゼンター（MVP）パターンを使用しています。問題はほとんどのGUIツールキットと同じだと思います。 私を悩ませているのは、プレゼンターだけでなく、プレゼンターが必要とするサービスも作成している具体的なビュー（つまり、ダイアログクラス）です。それは正常ですか？ビューがプレゼンターが必要とするサービスを知る必要があるのはなぜですか？私が考えているのは、プレゼンターをダイアログクラスに依存的に挿入する必要があるということです。 アプリケーションのメインコントロールは、CWinAppから派生したクラスです。では、このクラスでサービスとプレゼンターを作成してから、ダイアログクラスに挿入する必要がありますか？ ただし、プレゼンターがコンストラクターでビュークラスへの参照を必要とする場合、ダイアログクラスにプレゼンターを依存性注入するにはどうすればよいですか？ MyPresenter(IView *view, MyService *service); また、メインウィンドウがポップアップウィンドウからスポーンした場合、そのウィンドウプレゼンターとサービスの詳細はどこに構築する必要がありますか？ これはC ++なので、どんな種類のDIフレームワークにも興味があるとは思いません。 更新 私が持っていた1つのアイデアは、nullビューでプレゼンターを作成し、コンストラクターがプレゼンターをダイアログクラスに挿入し、ダイアログクラスのコンストラクターでSetView(IView *view)プレゼンターのメソッドを呼び出すthis場所thisがダイアログクラスになる場所（IViewから派生）でした。 ）。そう： MyApp::Start() { SomeService *service = new SomeService(); MyPresenter *presenter = new MyPresenter(null, service); MyDialog *dialog = new MyDialog(presenter); ... } MyDialog::MyDialog(MyPresenter *presenter): presenter_(presenter) { presenter_->SetView(this); } 少しぎこちないように見えますが、サービスの構築をDialogクラスから除外しています。空のビューは少し危険なようです。代わりの方法は、空のメソッド本体を持つNullViewクラスを実際に作成し、それをプレゼンターコンストラクターに渡すことです。