Saya menggunakan pola Model View Presenter (MVP) seperti yang dijelaskan dalam kertas The Humble Dialog Box (pdf) dengan proyek MFC. Saya yakin masalahnya sama dengan sebagian besar toolkit GUI.
Hal yang mengganggu saya adalah pandangan konkret (yaitu, kelas dialog) menciptakan tidak hanya presenter tetapi juga layanan yang dibutuhkan presenter. Apakah itu normal? Mengapa pandangan perlu mengetahui layanan apa yang dibutuhkan presenter? Yang saya pikirkan adalah saya harus ketergantungan menyuntikkan presenter ke dalam kelas dialog.
Kontrol utama untuk aplikasi adalah kelas yang berasal dari CWinApp. Jadi haruskah saya membuat layanan dan presenter di kelas ini dan kemudian menyuntikkannya ke dalam kelas dialog?
Meskipun bagaimana saya ketergantungan akan menyuntikkan presenter ke dalam kelas dialog ketika presenter membutuhkan referensi ke kelas tampilan di konstruktor itu?
MyPresenter(IView *view, MyService *service);
Juga bagaimana jika jendela utama memunculkan jendela popup, di mana detail untuk presenter dan layanan windows itu dibangun?
Karena ini adalah C ++ saya tidak berpikir saya akan tertarik pada segala jenis kerangka kerja DI.
MEMPERBARUI
Satu ide yang saya miliki adalah untuk membangun presenter dengan tampilan nol, konstruktor menyuntikkan presenter ke dalam kelas dialog, dan kemudian dalam konstruktor kelas dialog memanggil SetView(IView *view)
metode pada presenter dengan di this
mana this
akan menjadi kelas dialog (yang berasal dari IView ). Begitu:
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);
}
Tampaknya sedikit kotor tetapi membuat konstruksi layanan keluar dari kelas Dialog. Tampilan nol sepertinya sedikit berbahaya. Alternatifnya adalah dengan benar-benar membangun kelas NullView yang memiliki tubuh metode kosong dan kemudian meneruskannya ke konstruktor presenter.