1

我剛開始使用wxPython,並且一直在通過每個教程以及我可以掌握的示例工作。但是,我遇到了一個小問題,它與wx.App和wx.Frame有關,它應該包含特定的方法。幾乎所有我見過的例子都沒有超出佈局/尺寸和事件處理的範圍,沒有一個真正解決wxPython項目的項目組織問題。從wx框架類中調用應用程序方法

例如,我有一個獲取文件夾列表的方法。大多數例子將處理這個問題的方法是將方法正確地固定在框架類中。這種方法有可能在應用程序的其他幾個部分中使用,所以將它存儲在應用程序級別更有意義。

我應該如何組織和調用像這樣的「通用」方法,以免混亂我的框架類。

UPDATE:

爲了澄清,在「文件夾列表」只是一個例子,我實際的方法做了很多工作。我說的是我有不是特定於幀的代碼。如果我在應用程序類中有這個,那麼從我的框架中調用它以及event方法的最佳方式是什麼。

我正在尋找實際的項目組織技巧,而不是編程基礎知識。

+0

如果你真的在學習冒險,並且你沒有時間緊張,那麼你可以瀏覽Audacity應用程序的源代碼。這是一個非常成功的,非基本的,不平凡的應用程序,它恰好是開源*和*使用wxWidgets。 http://audacity.sourceforge.net – pestophagous 2008-12-24 06:31:30

回答

2

從wxWidgets/wxPython數據類型繼承的類不應該實現任何業務邏輯。 wxWidgets是一個GUI庫,因此wxApp或wxFrame的任何子類都應該專注於GUI,即顯示界面並響應用戶操作。

執行一些有用的代碼應該與wx分開,因爲您可以稍後決定在某些Web或控制檯應用程序中使用它,並且不希望在此類情況下創建wxApp對象。您也可以稍後決定移動一些計算來分離「工作線程」,而您的GUI將成爲「主線程」 - 響應並在長期計算過程中正確重新繪製。

最後但並非最不重要 - 封裝邏輯的類可能會在項目生命週期中增長。如果它們與您的GUI類混合在一起,它們會變得更快,最後它們會變得如此複雜以至於您幾乎無法調試它們...

雖然在不混合的情況下將它們分開會導致乾淨的代碼GUI中存在錯誤的邏輯錯誤(刷新/佈局/進度條等)。這種方法還有另一個很好的特性 - 可以在GUI人員和邏輯人員之間分配工作,他們可以在不經常發生衝突的情況下完成工作。

0

在適當的OOP設計中,這將是獨立的或文件系統類的一部分 - 它不會是應用程序或框架的一部分。

2

正如馬克說,你應該做一個新的類來處理這樣的事情。

使用類似wxWidgets的代碼的理想佈局是模型視圖控制器,其中wxFrame類只具有顯示項目所需的代碼,並且所有邏輯和業務規則都由其他與wxFrame交互的類處理。通過這種方式,您可以更改邏輯和業務規則,無需更改界面,更改(或交換)界面,而無需更改邏輯和業務規則。

相關問題