在C ++桌面應用程序上下文中使用MVC進行導航/查看流

Question

假設您有一個全屏C ++桌面應用程序，該應用程序由多個屏幕組成，每個屏幕具有不同的功能，以及一個具有適當模型的ViewController。 例如，一組以下非常簡化的屏幕：

1. 測驗：引導用戶瀏覽一組多項選擇題。
2. 帶有統計的測驗結果。
3. 信息：向用戶顯示有關特定主題的信息。
4. 菜單（測驗，信息，退出）

根據GRASP原則Information Expert的判斷，每個ViewController將在完成時以及移動到新屏幕的時間上最清楚。 但是，根據相同的原則，並不是確定下一個屏幕實際應該是什么的正確位置。 在這個相當簡單的示例中，人們可能會認為這是可以的，但是在更復雜的應用程序中，無疑會導致代碼和邏輯重復，以及耦合度更高和凝聚力更低。 還有一個問題是，您將不得不在當前屏幕的ViewController中創建新的小部件和控制器，這會帶來各種各樣的新問題，至少根據Creator原則，這不是正確的選擇。 您將不得不引入Factory來緩解某些問題，尤其是其中的一些問題。

因此，下一個合乎邏輯的步驟是引入ApplicationController，其唯一職責是管理視圖及其控制器，包括從一個視圖到下一個視圖的導航流程。

在我看來，這仍然留下了一個尚待解決的問題：如何向ApplicationController發出信號，是時候該移動到另一個屏幕並將控件正確地移交給該對象了？

例如，可以使用觀察者模式。 但是，如果您目前有一個昂貴的View處於活動狀態，並且希望在新屏幕處於活動狀態時將其銷毀怎么辦？ 如果當前ViewController向ApplicationController發出信號，通知下一個屏幕應該向上，則它可以管理所有事務，直到銷毀當前活動的屏幕為止，由於當前調用恰好來自該對象，所以它無法執行操作。 除了這種方法的其他幾個問題。

所以我的問題是（對所有冗長的介紹很抱歉：P）：您如何使用MVC正確地實現從一個全屏小部件到另一個小部件的導航流程，從而解決了上述問題，在View-和ApplicationController之間分配了責任，在耦合和內聚方面很好地面向對象嗎？

Answer 1

有時，您會在思考過程中遺漏一個細節，從而打開了一整套問題，甚至沒有意識到自己犯的錯誤。

在這種情況下，細節是您可以自然地發布異步事件和同步事件。 如果必須確保您不再處於事件發布方法的上下文中，請發布異步事件。 在處理程序中收到該事件后，就可以確定已保留上下文。 例如，您可以根據需要安全地刪除對象。 自然，事件處理程序不應位於您要刪除的同一對象的上下文中。

為了完整起見：在Qt中，您可以為使用connect（）建立的每個信號/插槽連接指定類型為Qt :: QueuedConnection。 如果發出信號，則在控件返回到線程的事件循環之前將不會傳遞該信號。 通常，如果接收方在同一線程中，則使用Qt :: AutoConnection在發出信號時發送信號（Qt :: DirectConnection），或者如果接收方在同一線程中則退回到排隊該信號（Qt :: QueuedConnection）。一個不同的線程。

在wxWidgets中，您可以使用wxEvtHandler :: QueueEvent（wxEvent * event）對事件進行排隊，例如，可通過Application單例使用。