代碼的壞味道03:過大的類(Large Class)

    如果想利用單個類做太多的事,其內往往就會出現太多執行個體變數。這樣 重複代碼(Duplicated Code)就接踵而至了。 運用Extract Class (提煉類)將幾個變數一起提煉到新類裡。提煉類時應該選擇類內彼此相關的變數,將它們放在一起。通常類內的數個變數有相同的首碼或字尾,這就意味有機會把它們提煉到某個組件內。如果這個組件適合作為一個子類,就可以運用 Extract Subclass (提煉子類)。

代碼壞的味道21:被拒絕的遺贈 (Refused Bequest)

    子類應該繼承超類的函數和資料。但如果它們不想或不需要繼承,又該這麼辦呢?它們得到所有禮物,卻只從中挑選幾樣來玩。         按傳統說法,這就意味著繼承體系設計錯誤。你需要為這個子類建立一個兄弟類,再次運用 push down Method (函數下移)和 push down field (欄位下移)把所有用不到的函數下推給那個兄弟。這樣一來,超類就只持有所有子類共用的東西。你常常會聽到這樣的建議:所有超類都應該是抽象的。        

代碼的壞味道04:過長參數列(Long Parameter List)

    如果向已有的對象發出1條請求就可以取代1個參數,那麼就運用 Replace Parameter with Methods (以函數取代參數)。在這裡,"已有的對象"可能是函數所屬類裡的1個欄位,也可能是另一個參數。還可以運用 Preserve Whole Object (保持對象完整)將來自同一對象的一堆資料收集起來,並以該對象替換它們。如果某些資料缺乏合理的對象歸屬,可使用 Introduce Parameter Object (引入參數對象)為它們製造出一個參數對象。

代碼壞的味道22:過多的注釋 (Comments)

  我們之所以在這裡提到注釋,是因為人們常把它當做除臭劑來使用。常常會有這樣的情況:你看到一段代碼有著長長的注釋,然後發現,這些注釋之所以存在是因為代碼很糟糕。         注釋可以帶我們找到代碼中的壞味道。找到壞味道後,我們首先應該以各種重構手法把壞味道去除。完成之後我們常常會發現:注釋已經變得多餘了,因為代碼已經清楚說明了一切。         如果你需要注釋來解釋一塊代碼做了說明,試試Extract Method (提煉函數);如果函數已經提煉出來,但還是需要注釋來解釋其行為,試試

代碼的壞味道05:發散式變化(Divergent Change)

    如果某個類經常因為不同的原因在不同的方向上發生變化,發散式變化(Divergent Change)就出現了。那麼此時也許將這個對象分成2個會更好,這麼一來每個對象就可以只因1種變化而需要修改。針對某以外界變化的所有相應修改,都只應該發生在單一類中,而這個新類內的所有內容都應該反應此變化。為此應該找出某特定原因而造成的所有變化,然後運用Extract Class (提煉類)將它們提煉到另一個類中。

代碼壞的味道06:散彈式修改(Shotgun Surgery)

    散彈式修改(Shotgun Surgery)類似 發散式變化(Divergent Change),但恰恰相反。如果每遇到某種變化,都必須在許多不同的類中做出許多小修改,你所面臨的壞味道就是散彈式修改(Shotgun Surgery)。如果需要修改的代碼散布在四處,你不但很難找到它們,也很容易忘記某個重要的修改。    可以使用 Move Method (搬移函數)和 Move Field (搬移欄位)把所有需要修改的代碼放進同1個類。如果暫時沒有合適的類,就建立一個。通常可以運用

代碼壞的味道19:不完美的庫類 (Incomplete Library Class)

  複用常被視為對象的終極目的。不過複用的意義常被高估:大多數對象只要夠用就好。但是無可否認,許多編程技術都建立在程式庫的基礎上。      庫類的構築者沒用未蔔Crowdsourced Security Testing的能力,不能因此責怪他們。麻煩的是庫往往構造的不夠好,而且往往不可能讓我們修改其中的類使它們完成我們希望完成的工作。這是否意味著那些經過實踐檢驗的技術,如今都派不上用場了?        

代碼壞的味道20:純稚的資料類 (Data Class)

  所謂的Data Class是指:它們擁有一些欄位,以及用於訪問這些欄位的函數,除此之外一無長物。這樣的類只是不會說話的資料容器,它們幾乎一定被其他類過分細瑣的操控著。這些類早期可能擁有public欄位,果真如此你應該在別人注意到它們之前,立刻運用 Encapsulated Field (封裝欄位)將它們封裝起來。如果這些類含容器類的欄位,你應該檢查它們是不是得到了恰當的封裝;如果沒有,就運用 Encapsulated Collection

代碼的壞味道01:重複代碼(Duplicated Code)

  如果你在一個以上的地點看到相同的程式結構,那麼可以肯定:設法將它們和而為一,程式會變得更好。   同一個類的2個函數含有相同的運算式,這時可以採用Extract Method (提煉函數)提煉出重複的代碼,然後讓這2個地點都調用被提煉出來的那段代碼。   2個互為兄弟的子類內含相同運算式,只需對2個類都是用Extract Method (提煉函數),然後對被提煉出來的函數是用Pull Up Method

重構手法05:Introduce Explaining Variable (引入解釋性變數)

 你有一個複雜的運算式。將該複雜運算式(或其中一部分)的結果放進一個臨時變數,以此變數名稱來解釋運算式用途。if (Platform.ToUpperCass().indexOf("MAC") > -1 && (Browser.ToUpperCass().indexOf("Ie") > -1) && WasInitalized() )            {                //do something           

代碼壞的味道16:中間人 (Middle Man)

  對象的基本特徵之一就是封裝:對外部世界隱藏其內部細節。封裝往往伴隨委託。比如說你問你主管是否有時間參加一個會議,他就把這個訊息“委託”給他的記事簿,然後才能回答你。你沒必要知道這位主管到底使用傳統記事簿或電子記事簿或秘書來記錄自己的約會。         但是人們可能過度運用委託。你也許會看到某個類有一半的函數都委託給其他類,這樣就是過度運用。這時應該使用 Remove Middle Man (移除中間人),直接和真正負責的對象打交道。如果不幹實事的函數只有少數幾個,可以運用 Inline

虛擬硬碟

前些時間看到有人在說用虛擬硬碟建立資料庫,存放檔案等等,就到網上找了有關這方面的知識。概念  所謂虛擬硬碟就是用記憶體中虛擬出一個或者多個磁碟的技術。   記憶體的速度要比硬碟快得多,就要利用這一點,在記憶體中虛擬出一個或多個硬碟就可以加快磁碟的資料交換速度,從而提高電腦的運行速度。  從上面我們可以看出:所謂“虛擬”有二:其一所謂“虛擬”首先是假的,其次是能夠起到所虛擬硬碟的功能。虛擬硬碟的目的無非是為了速度犧牲一些容量。 虛擬硬碟主要作用  1.增加訪問速度

系統減輕資料峰值辦法(MSMQ)

在做一個證券系統,伺服器接收的資料量特別頻繁,也是為了系統的可擴充性,系統設計如下:接收資料-->MSMQ隊列-->處理業務-->MSMQ隊列-->返回資訊,通過介面把資料接收存放到MSMQ實現。MSMQ可以應用到很多地方,現在把思路放出來,給各位朋友參考參考,或許已經過時了,但總希望能有人需要吧!首先引用命名空間:  using System.Messaging;        private static bool InsertData(string mqName,

重構手法01:Extract Method (提煉函數)

你有一段代碼可以被組織在一起並獨立出來。將這段代碼放進一個獨立函數,並讓函數名稱解釋該函數的用途。       void PrintOwing(double amount)        {            PrintBanner();            //print details            Console.WriteLine("name:"+_name);            Console.WriteLine("amount:"+_amount);       

web控制項開發系列(四) 自訂控制項屬性(下)

控制項在WEB開發時經常要用到,雖然有部分已經存在工具箱裡,但有時總需要根據自己的要求,開發一些合適自己的控制項。接上一節,已經說過了控制項的屬性, 例如,我們需要一組屬性的集合時,這時我們需要用到的就是複雜屬性了,簡單的屬性滿足不了我們的要求,例如:大家熟悉的字型資訊設定那欄。下面為大家介紹一下實現的幾種代碼與注意細節一、連字號形式的複雜屬性標記<asp:Button ID="Button1" runat="server" Font-Bold="True"

物件導向編程設計模式–簡單原廠模式講解(曆史上最簡單明白的例子)

工作之餘,在看資料過程中發現一個極易理解的簡單原廠模式的例子,自己親自試練一番,感覺對這個設計模式不熟悉的朋友,一看馬上就知道是什麼回事了。簡單原廠模式根據提供給它的資料,返回幾個可能類中的一個類的執行個體。通常它返的類都有一個共同的你類和共同的方法,但每個方法執行的任務不同,而且根據不同的資料進行了最佳化。簡單原廠模式是屬於建立型模式,又叫做靜態Factory 方法(Static Factory Method)模式,但不屬於23種GOF設計模式之一。下面進行一個程式碼範例:       

web控制項開發系列(-) 基礎介紹

控制項在WEB開發時經常要用到,雖然有部分已經存在工具箱裡,但有時總需要根據自己的要求,開發一些合適自己的控制項。web控制項開發已經成為WEB程式員必備的知識。有過WEB開發的朋友都知道,建立一個WEB項目,Default頁面顯示的資訊,好多人都會有Page_Load事件中進行處理,這就對了。這個是Page頁面的生命週期,控制項也一樣有自己的生命週期。當你瞭解生命週期後,就不奇怪,為什麼有部分代碼要寫在Page_Load事件中了。生命週期大概有如下幾個:·執行個體化(Instantiate)控

代碼的壞味道02:過長函數(Long Method)

90%的場合裡,要把函數變小,只需使用Extract Method (提煉函數),找到函數中適合集中在一起的部分,將它們提煉出來形成新函數。如果函數內有大量的參數和臨時變數,它們會對你的函數提鍊形成障礙。你可以經常運用Replace Temp with Query (以查詢取代臨時變數),來消除這些臨時元素。Introduce Parameter Object (引入參數對象),Preserve Whole Object

DataGridView行的標題

 datagridView的Rows裡面有個HeaderCell可以通過value來設定列名文字,但是一排序後,文字就清空了. 所以這種辦法是不行的.下面我介紹一種新的辦法..就是datagridview產生行時,在列名那寫進文字,這樣排序完成後也不會改變原來的數值 private void dataGridView1_RowPostPaint(object sender, DataGridViewRowPostPaintEventArgs e){SolidBrush B = new

使用IFormatProvider打造自己個性格式化方法

C#中提供了好多格式化數字或字串的方法,但在項目開發中,有很多自己需要的格式無法實現,那就需要我們去定義IFormatProvider,其實很簡單,只需繼承二個介面,然後實現二個方法就可以了。ICustomFormatter介面中實現Format方法:string Format (string format,Object arg,IFormatProvider formatProvider)IFormatProvider介面中實現GetFormat方法:object

總頁數: 61357 1 .... 6064 6065 6066 6067 6068 .... 61357 Go to: 前往

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.