設計模式概述【整理】

標籤：設計模式   設計原則   

 

       設計模式不是很快的提高你的編碼能力，設計模式的學習，旨在避免重複編碼，減少勞動量。學習設計模式，對提高編寫高效代碼，大有裨益。學習設計模式，首先引入設計原則。

設計原則

設計模式的核心原則是:"開-閉"原則(  Open - Closed Principle 縮寫:OCP  ),一切的一切都是圍繞著"開-閉"原則展開的..
     意思是,在一個系統中,對於擴充是開放的,對於修改是關閉的,一個好的系統是在不修改原始碼的情況下,可以擴充你的功能..而實現開閉原則的關鍵就是抽象化.
     在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充的是具體的實作類別,抽象類別和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴充..所以在這裡"抽象化"是關鍵!!!

      可變性的封閉原則:找到系統的可變因素,將它封裝起來..這是對"開-閉"原則最好的實現..不要把你的可變因素放在多個類中,或者散落在程式的各個角落..你應該將可變的因素,封套起來..並且切忌不要把所用的可變因素封套在一起..最好的解決辦法是,分塊封套你的可變因素!!避免超大類,超長類,超長方法的出現!!給你的程式增加藝術氣息,將程式藝術化是我們的目標!!

      裡氏代換原則:任何基類可以出現的地方,子類也可以出現..如果你通讀過<Java編程思想>,我想你應該明白這個原則,在書中,Bruce Eckel 大師用了大量的章節來講解"向上轉型"和"向下轉型",我想目的很清楚,不僅是要你明白類的型別,更重要的是要你明白父類與子類的關係..

      依賴倒轉原則:要依賴抽象,而不要依賴具體的實現..如果說開閉原則是目標,依賴倒轉原則是到達"開閉"原則的手段..如果要達到最好的"開閉"原則,就要盡量的遵守依賴倒轉原則..可以說依賴倒轉原則是對"抽象化"的最好規範!!我個人感覺,依賴倒轉原則也是裡氏代換原則的補充..你理解了裡氏代換原則,再來理解依賴倒轉原則應該是很容易的..
  合成/彙總原則:要盡量使用合成/彙總原則,而不是繼承關係達到軟體複用的目的..此原則和裡氏代換原則氏相輔相成的,兩者都是具體實現"開-閉"原則的規範..違反這一原則:就無法實現"開-閉"原則..先來看看什麼是合成,什麼是彙總.

      什麼是合成?
     合成:是指一個整體對依託他而存在的關係,例如:一個人對他的房子和傢具,其中他的房子和傢具是不能被共用的,因為那些東西都是他自己的..並且人沒了,這個也關係就沒了..這個例子就好像,烏雞百鳳丸這個產品,它是有烏雞和上等藥材合成而來的一樣..也比如網路遊戲中的武器裝備合成一樣,多種東西合并為一種超強的東西一樣..
      
      什麼是彙總?
      彙總:彙總是比合成關係的一種更強的依賴關係,彙總是一個整體對個體的部分,例如,一個平治S360汽車,對平治S360引擎,平治S360輪胎的關係..這些關係就是帶有彙總性質的..因為平治S360引擎和平治S360輪胎他們只能被平治S360汽車所用,離開了平治S360汽車,它們就失去了存在的意義..在我們的設計中,這樣的關係不應該頻繁出現..這樣會增大設計的耦合度..
      明白了合成和彙總關係,再來理解合成/彙總原則應該就清楚了..要避免在系統設計中出現,一個類的繼承層次超過3次..如果這樣的話,可以考慮重構你的代碼,或者重新設計結構..當然最好的辦法就是考慮使用合成/彙總原則...

      迪米特法則:系統中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因為在你的系統中,擴充的時候,你可能需要修改這些類,而類與類之間的關係,決定了修改的複雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如A類依賴B類,則B類依賴C類,當你在修改A類的時候,你要考慮B類是否會受到影響,而B類的影響是否又會影響到C類..如果此時C類再依賴D類的話,呵呵,我想這樣的修改有的受了..

     介面隔離法則:這個法則與迪米特法則是相通的,迪米特法則是目的,而介面隔離法則是對迪米特法則的規範..為了做到儘可能小的耦合性,我們需要使用介面來規範類,用介面來約束類.要達到迪米特法則的要求,最好就是實現介面隔離法則,實現介面隔離法則,你也就滿足了迪米特法則...

設計模式

http://www.cnblogs.com/beijiguangyong/archive/2010/11/15/2302807.html

 

 

【轉載使用，請註明出處：http://blog.csdn.net/mahoking】

 

參考資料

http://www.cnblogs.com/lixianhuei/archive/2006/01/12/315849.html

http://www.cnblogs.com/beijiguangyong/archive/2010/11/15/2302807.html