建站
咨詢
售后
建站咨詢
新聞中心
.NET代碼設計的重點在于重視程度，也就是開發(fā)人員需要集中思想，提前做好準備工作。如果不重視，很可能出現(xiàn)太多的public會讓使用這些class的二次開發(fā)的人員無所適從的局面。
專注于為中小企業(yè)提供成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)相城免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉變。
為什么要重視.NET代碼設計？
在絕大多數(shù)項目中，尤其是在大型、資源缺少(這是軟件項目的典型現(xiàn)象)的項目中，正規(guī)的架構可能只是解決系統(tǒng)級的事項，而特意把大部分的設計工作留待代碼構建階段去做。這可能會引發(fā)兩個問題：
1) 代碼構建階段的設計分散保存在開發(fā)人員的頭腦中，得不到有效的驗證
2) 由于開發(fā)人員各有所長，也各有所短，往往在進行了部分或完成代碼構建后,問題才能被明確。最終，不合理的設計導致大量的重構工作，延誤項目工期。
設計工作千頭萬緒，然而軟件設計的首要使命是“管理復雜度”；重點和難點是“管理變化”。雖然“管理變化”是“管理復雜度”的內(nèi)容之一，但由于“管理變化”具有突出的重要性，因此單獨進行介紹。在代碼構建整個過程中，所有設計工作必須充分考慮這兩個方面，從而實現(xiàn)高質(zhì)量代碼。
1. 管理復雜度
復雜度來源：
1) 用復雜的方法解決簡單的問題
這個現(xiàn)象通常出現(xiàn)在過度設計上：首先是簡單的問題復雜化，然后對復雜化的問題使用復雜的方法。
如在10個有序數(shù)字中檢索某個數(shù)字。按照目前的CPU運算速度，直接采用順序檢索簡單有效。如果盲目考慮CPU運算的因素，采用二分法檢索，反而導致邏輯冗余。但是，如果對位數(shù)過萬的數(shù)組進行檢索，則應采用二分法或其它更有效的算法。
2) 用簡單但錯誤的方法解決復雜的問題
由于設計是一個由淺入深，不斷嘗試，不斷失敗，最終得到正確結果的過程，因此，在代碼構建之初，當設計者未能正確考慮復雜問題的各個方面，將復雜問題簡單化后，將會導致“用簡單但錯誤的方法解決復雜的問題”。
對此，我說一下自己的一個切身體會，在SharePoint開發(fā)中，我們一個常見的問題是“內(nèi)容數(shù)據(jù)庫非關系型數(shù)據(jù)庫”，雖然Moss提供了Lookup類型的字段來建立這種關系，但是存在兩個問題，首先是不能跨站點，更不能查詢多個列表的內(nèi)容，也不能綜合顯示多個字段的內(nèi)容。這些缺陷對于很多應用來說，似乎是致命的。為此，我曾經(jīng)設計出同時支持跨網(wǎng)站、跨列表、多字段的自定義Field。但是設計中欠缺考慮，以致完成該Field的開發(fā)后，一個顯著的缺陷讓我頭疼不已：將關聯(lián)關系存儲與字段值中，雖然在顯示、編輯和存儲上簡化了編碼工作，但是卻未能解決關聯(lián)關系本質(zhì)上的問題，從而導致了一系列更為復雜的問題的出現(xiàn)，如反向關聯(lián)查詢，關聯(lián)同步，以致于花費了大量的精力來維護這種關系。
在該字段新版本的設計中，我將關聯(lián)關系單獨存儲在一個列表中，同時擴展基內(nèi)容類型的New & Edit Form。嵌入維護不同列表間項與項關系的可視化展示與編輯部件(基于Silverlight實現(xiàn))。順便提一下，使用了多年的Flex，發(fā)現(xiàn)Silverlight除了在基礎組件庫上略遜色外，性能方面還是很不錯的，尤其是繼承自NET的垃圾回收機制。
但是無論是Flex和Silverlight，都要注意它在圖形繪制方面的局限性，當需要繪制的組件和圖表過多時，盡量只繪制ViewPort中的部分，否則性能問題將導致整個程序的崩潰。
總結一下，如果使用簡單但錯誤的方法解決復雜問題，那么代價會在后面成幾何級數(shù)回饋給你。
套用一句話：代碼無小事！
3) 用不恰當?shù)膹碗s方法解決復雜問題
在舊有經(jīng)驗的指導下，某些復雜問題的表象會誤導設計者，將之當作另外一個曾經(jīng)發(fā)生過的復雜問題，而問題本身的復雜程度也令人望而卻步，不愿做進一步的分析，直接套用已有的解決方法雖然省事，卻有可能“用不恰當?shù)膹碗s方法解決復雜問題”。
管理復雜度的方法：
1) 任何人在同一時間只處理必不可少的復雜度
a) 分類匯總
從問題的領域著手，而不是從底層實現(xiàn)細節(jié)入手去編寫程序，在最抽象的層次上工作，也能減少人的腦力負擔。
問題的領域在不同抽象程度上，可以劃分為不同的級別：業(yè)務，子系統(tǒng)，功能模塊，類、子程序。通常，從較高的領域分解下來，會有效的降低問題的復雜程度。如在子系統(tǒng)級別確定好每個功能模塊接口，那么在進入功能模塊領域后，你只需要關心少量的接口，而把更多的精力放在該功能的數(shù)據(jù)、邏輯和UI設計上。
C#等面向?qū)ο笳Z言可以輕易實現(xiàn)這種抽象，通過定義基類或抽象類(如C#中的abstract 關鍵字)。
b) 一致的抽象
定義基類或抽象類時，必須保持同級別抽象的一致性，摒除不必要的細節(jié)。
如ASP.NET編程中的Page和Control就屬于同一級別的抽象。 在Page類的實現(xiàn)中，它無需知道具體是什么類型的Control，是DataGrid還是TextBox，它根本不關心，它只關心Control類中的Render()可以提供什么樣的Html。而這個Control是紅的還是綠的，是方的還是圓的，根本不需要關心。如果編寫Page類時調(diào)用了Control的一個子類，那抽象就不一致了，Page將自動降級，Page對于Control基類毫無意義。當然，這樣的錯誤誰也不會去犯，僅僅用來說明這個道理而已。
在SharePoint中，通常我們也會實現(xiàn)一些基礎類以提高團隊的開發(fā)效率，如BaseAjaxWebPart、BaseAjaxField等等。這些Base類中一定不要使用某些實現(xiàn)了特定細節(jié)的類或組件。
2) 不要讓偶然性的復雜度無謂地快速增長
偶然性的復雜度，即潛在的變化，包括：已知的未知、未知的未知。
對于未知的未知這種情況，我們可以不過多考慮，只需要根據(jù)經(jīng)驗在任務工期上預留一定資源：時間、人力等。
對于已知的不確定的變化，在下面《管理變化》中簡要介紹。
2. 管理變化
沒有變化的程序是不可能存在的。但不能讓變化像病毒一樣蔓延到整個程序。
管理變化的手段比較多，如24種設計模式，大部分都是解決這個問題的。但萬變不離其宗，主要還是以下兩個方面：
1) 封裝
通過有效的繼承和一致的抽象，可以確保發(fā)生變化時，最小的代碼改動量。
2) 模塊化
通過對系統(tǒng)模塊化及劃分界面，確定接口，可以有效地將變化控制在模塊內(nèi)部。
使用封裝和模塊化來管理變化時，必須注意隱藏信息：該使用private之處，絕不要使用protected。該使用protected之處，絕不要使用public。Internal也不要多用，它的作用域是程序集內(nèi)部，在編寫代碼時，往往跟public一樣混淆視聽，降低了代碼的可讀性。
太多的public會讓使用這些class的二次開發(fā)的人員無所適從。充斥著非必要public成員的class，不符合管理復雜度的原則。有可能是設計原因，也有可能是未按照設計嚴格編碼。
.NET代碼設計的要點就介紹到這里。
鏈接：http://www.cnblogs.com/ghner/archive/2009/09/05/1560998.html
分享文章：簡述為什么要重視.NET代碼設計
標題來源：http://www.dlmjj.cn/article/cocsgcp.html
