2010-09-29 79 views
4

目前我的Form1代碼非常重,主要是菜單和控制事件。我想要做的一件事是以某種方式組織它,所以我可以展開或摺疊「相關代碼」(在Visual Studio中)。使用類來組織代碼?

我的第一次嘗試就是把與主菜單相關的代碼放在一個名爲「MainMenu」的嵌套類中,它位於Form1類內,這樣我就可以簡單地摺疊嵌套類不需要它。這導致了各種各樣的問題(即我找不到在這個嵌套類中設置主菜單的方法)。

有沒有更簡單的解決方案,我錯過了?或者,有人可以闡明爲什麼我的嵌套式課堂想法有問題嗎?

+0

我想你需要發表一些代碼... – annakata 2010-09-29 12:17:59

+0

我想我可以重新說我的問題如下:如果我有一個窗體,必須有50個按鈕,我有任何選擇,但有50「私人無效button_Click「在我的代碼中的特定形式的事件? – 2010-09-29 12:25:20

+0

如果多個按鈕共享相同的點擊事件,那麼您可以讓它們指向相同的方法。如果多個按鈕具有相同的總體思路,但只有一個或兩個點不同,則可以創建一個僅佔用一個或兩個值的工作程序類,並執行實際點擊方法之外的所有工作。這一切都歸結爲讓你的按鈕的代碼量非常有限,然後輔助方法/類來完成實際的工作。 – Adkins 2010-09-29 13:10:29

回答

12

您可以使用#region和#endregion組織類中的代碼。這些地區然後可以崩潰。

+3

爲什麼downvote在這裏? - #區域正是針對所表達的問題。 – annakata 2010-09-29 12:12:24

+9

當我看到代碼與地區混雜在一起時,我總是想跑開。這真是一個壞習慣。相反,應該編寫不需要區域的代碼。如果這種情況不可能發生,那麼我會大量發現代碼,這種重構會大大改善。 – bitbonk 2010-09-29 12:12:36

+0

是的,非常感謝你testalino,我確實尋求簡單的解決方案! – 2010-09-29 12:13:03

0

嵌套類通常被認爲只是從上帝類輕微升級的一件事,封裝和代碼重用是非常模糊。

應該旨在表達您在代碼中實際擁有的作爲單個業務類的對象:一個類,一個文件。有沒有什麼特別的原因,你不這樣做?

+0

我應該規定我對C#很陌生。我有能力編寫似乎能完成這項工作的基本程序(很可能不是最佳方式),但仍然非常瞭解封裝等。 – 2010-09-29 12:19:15

0

根據代碼類型的不同,它將取決於您可以移動的位置。

如果它的數據處理代碼,那麼你可以在不同的命名空間移動這個分成不同的類處理過的數據返回給控制允許數據綁定等

如果Form1中越來越非常繁忙,然後代碼是這樣的因爲你在Form1中有太多的事情要做?你能把它分解成不同的/新的形式嗎?

15

雖然@testalino's answer肯定是你要求的,我會說你的真的問題可能與代碼設計有關。機會是,表單類只包含比它應該更多的代碼,並且其中一些應該移到其他類中。

如果在一個很好的方式完成的,這可能會給你一些好處:

  • 你可能會得到更多的封裝(少耦合的)行爲,當各種功能通過參數傳遞給方法的數據進行操作返回值而不是直接在UI控件中獲取和設置值。
  • 你可能會得到一個更可測試的代碼庫(你有有單元測試,對嗎?)。
  • 由於代碼分佈在多個不同的代碼文件中,因此幾個人就代碼進行協作會更容易。這減少了合併衝突(你有有一個源代碼管理系統,對吧?)。這一點可能不適用,如果你正在單獨工作,但無論如何也不會傷害到這種習慣。
+0

我很確定這些地區是OP尋找的地方,但是這個答案太好了,不會投票給任何人+1 – Adkins 2010-09-29 13:08:01

2

如果您的表單變得如此龐大而複雜,您突然想要以某種方式組織它,這對於重構的需求是一個強烈的暗示,這會提高代碼的可讀性,可測試性和可維護性。 您實際重構的取決於您的實際代碼。

它是一個有很多控件的窗體?考慮將其拆分成單獨的UserControl,其中每個UserControl顯示您的域數據的某個方面。你是否有很多交互邏輯,對很多事件做出反應?也許介紹一些控制器或EventAggregator。

有很多衆所周知的模式可以幫助您組織您的用戶界面和域代碼。 This series談到這一點,並向您介紹模式MVC,MVP,EventAggregator等等。它會根據需要討論Windows窗體上下文中的模式。

+1

非常感謝您的指導,我會給該網站一看。 – 2010-09-29 12:28:51

6

我建議你使用用戶控件來封裝一些表單的行爲。我猜,這是現在最簡單的解決方案。您只需選擇一些用戶界面並將其提取到用戶控件,並定義一些可從表單訪問的公共屬性。

保留Form.cs中的所有處理程序是一個壞的,不好的做法。你必須避免它,因爲它是不可或缺的(我已經看過很多類似的代碼,並且在後期階段添加或更改功能在不破壞任何內容的情況下被證明是不可能的,更不用說在不影響應用程序工作方式的情況下更改UI)。

將來,您可能想嘗試不同的方法將UI從應用程序邏輯中分離出來,例如,探索MVP/MVC模式。

2

使用partial class關鍵字爲了將你的類拆分成幾個文件。

0

您可以使用可摺疊的摘要,但我認爲這更適合爲其他開發人員提供信息,但始終是良好的做法!

在VB:

''' <summary> 
''' 
''' </summary> 
''' <remarks></remarks> 

在C#

/// <summary> 
/// 
/// </summary> 
/// <remarks></remarks> 
1

我與其他的答案說什麼關於#regions分組相似事件處理起來是固體給出事件數量龐大的同意。另外,如果處理程序中的代碼本身也很龐大,那麼您可能想要將這些代碼重構爲邏輯業務邏輯類。例如:

僞代碼之前:

僞後
private void SomeButton_Click(...) 
{ 
    using (FileStream fs = ...) 
    { 
     fs.Write(some form data); 
     fs.Write(some more form data); 
    } 

    DoMoreBusinessLogicStuff(); 
    ... 
    // lots more stuff 
    ... 
} 

private void SomeButton_Click(...) 
{ 
    IBusinessObject obj = new BusinessObject(injectable form data); 

    using (IPersistence store = new FilePersistence(...)) 
    { 
     obj.Persist(store); 
    } 

    obj.DoBusinessRules(); 
} 

這應該搬家業務,持久性和輔助邏輯自己的類,並留下您的事件處理程序僅設計爲輕質彈收集UI輸入並將其傳遞。