在桌面程式中。都會有乙個主介面。從我經歷的 專案來看，每個主介面都包含了大量的方法。我以前參與過的乙個專案的mainform的**量居然有2w行。造成這個問題的原因有兩個: 第一是 主介面是系統的主控制器。系統的大部分功能都在這裡展現出來。大量的選單、工具條當然需要大量的**來構造，掛接事件。處理事件。第二個原因和vs.net有關係。一般我們都通過vs.net工具直接掛接事件。這樣事件的響應方法就在主介面裡面。大部分時候我們都沒有很好的將業務方法和介面分離。這樣主介面裡的**量龐大就是必然的了。
除了**量巨大以外,它還帶來一些問題，首先這樣大量的**要維護其可讀性是一項大的挑戰。其次由於**都對在一起，不同子系統之間的互相依賴也被強化了。
在開發了多個專案以後，我很想改變這種做法。我想在的想法是主介面就是乙個控制項容器。我們把控制項放置在這個form上面就可以了。至於它要掛接的內容都在別的地方處理。
目前我的具體做法是:
1.在主介面中宣告所有的控制項 (都為 internal)
2.在主介面中提供對系統各個部分的資料模型的訪問方法
3.對於每一組控制項提供乙個ui類來負責構建控制項、響應事件等工作。
4.業務方法都封裝為特定的類，這些類在第三部的 ui類中的事件響應**中完成對資料模型的更新。
使用這種方法有乙個很顯著的問題.那就是主介面上的所有控制項的訪問級別至少必須是internal。有可能還需要public .在開始考慮使用這種方法的時候。覺得不應該將這些東西暴露出來。但是實際上除了ui類以外沒有別人需要訪問這些控制項。所以這樣做是可以的。如果為每個控制項寫乙個geter/seter的，那**量就大了。而且會顯得多此一舉。因為我們分解主介面的主要目的是減少主介面的**量，提高**的可讀性、降低不同子系統之間的耦合。
而這些ui類本身對主介面有依賴,以及關係緊密的子系統互相之間有所依賴也是可以的。
介面的作用
我在專案中大量使用介面，如果是多人合作專案更是不可少，舉個例子 我要寫乙個列印程式，但是面臨的問題是必須使用不同的印表機，有 hp的，ibm的 epsom 的等等。但是針對每乙個印表機的程式只有 2個必須要用到的函式，print printpreview 這兩個函式不同的印表機裡面的具體實現 是不一...
介面的作用
介面的最主要的作用是達到統一訪問，就是在建立物件的時候用介面建立，介面名 物件名 new 實現介面的類 這樣你像用哪個類的物件就可以new哪個物件了，不需要改原來的 就和你的usb介面一樣，插什麼讀什麼，就是這個原理。就像你問的，都有個method1的方法，如果我用介面，我上面就可以one.meth...
介面的作用
介面是一套大家事先商量好的協議,類似生產充電器和生產手機的兩個廠家,為了讓充電器能完美插上手機,那他們各自生產產品之前,必須商量好我的資料線的尺寸該多大,你的手機留的槽該多大合適,於是它們就給出第三方標準,就是介面,兩者只要滿足這個介面的要求,就能確保你生產的充電器能完美適配我生產的手機 所以,介面...