OO設計根本的指導原則是提高可維護性和可複用性。這些原則主要有:

開閉原則 一個軟體實體應該對擴充套件開放,對修改關閉。 在設計一個模組的時候,就當使這個模組可以在不被修改的前提下被擴充套件。換言之,就當可以在不必修改原始碼的情況下改變這個模組的行為。 如何做到既不修改,又可以擴充套件? 解決問題的關鍵在於抽象化:在Java語言裡,可以給出一個或多個抽象Java類或Java介面,規定出所有的具體類必須提供的方法特徵作為系統設計的抽象層。這個抽象層預見了所有的可能擴充套件,因此,在任何擴充套件情況下都不會改變。這就使得系統的抽象層不需要修改,從而滿足了—對修改關閉。 同時,由於從抽象層匯出一個或多個新的具體類可以改變系統的行為,因此係統的設計對擴充套件是開放的。 開閉原則實際上是對“對可變性的封閉原則“:找到一個系統的可變因素,將之封裝起來。這個原則意昧著兩點: 1) 一個可變性不應當散落在程式碼的很多角落裡,而應當被封裝到一個物件裡面。同一種可變性的不同表象意昧著同一個繼承等級結構中的具體子類。 繼承就當被看作是封裝變化的方法,而不應當被認為是從一般的物件生成特殊物件的方法。 2) 一種可變性不應當與另一種可變性混合在一起。(所有類圖的繼承結構一般不會超過兩層,不然就意昧著將兩種不同的可變性混合在了一起。) 開閉原則是總的原則,其它幾條是開閉原則的手段和工具。

依賴倒轉原則 依賴倒轉原則講的是:要依賴於抽象,不要信賴於實現。 開閉原則是目標,而達到這一目標的手段是依賴倒轉原則。 抽象層次包含的是應用系統的商務邏輯和宏觀的、對整個系統來說重要的戰略性決定,是必然性的體現;而具體層次則含有一些次要的與實現有關的演算法和邏輯,以及戰術性的決定,帶有相當大的偶然性選擇。具體層次的程式碼是會經常有變動的,不能避免出現錯誤。 抽象層次含有一個應用系統最重要的宏觀商務邏輯,是做戰略判斷和決定的地方,那麼抽象層次就應當是較為穩定的,應當是複用的重點;也應當是維護的重點。 在很多情況下,一個Java程式需要引用一個物件。這個時候,如果這個物件有一個抽象型別的話,應當使用這個抽象型別作為變數的靜態型別。這就是針對介面程式設計的含義。 一般而言,在建立一個物件時,Java語言要求使用new關鍵詞以及這個類本身。而一旦這個物件已經被創建出來,那麼就可以靈活地使用這個物件的抽象型別來引用它。比如:List employees = new Vector();因此,Java語言中建立一個物件的過程是違背“開閉原則”以及依賴倒轉原則的(因為先生成了具體的型別,再使用抽象的引用),雖然在這個類被創建出來以後,可以透過多型性使得客戶端依賴於其抽象型別。正是由於這個問題,設計模式給出了多個建立模式,特別是幾個工廠模式,用於解決物件建立過程中的依賴倒轉問題。 工廠模式將建立一個類的例項的過程封裝起來,消費這個例項的客戶端僅僅取得例項化的結果,以及這個例項的抽象型別。當然,任何方法都無法迴避Java語言所要求的new關鍵字和直接呼叫具體類的構造子的做法(這違背了里氏代換原則)。簡單工廠模式將這個違反“開閉原則”和依賴倒轉原則的做法封裝到了一個類裡面,而工廠方法模式將這個違反原則的做法推遲到了具體工廠角色中。透過適當的封裝,工廠模式可以淨化大部分的結構,而將違反原則的做法孤立到易於控制的地方。 聯合使用Java介面和Java抽象類:宣告型別的工作由Java介面承擔,但是同時給出的還有一個Java抽象類,為這個介面給出一個預設實現。如果一個具體類直接實現這個Java介面的話,它就必須自行實現所有的介面;相反,如果它繼承自抽象類的話,它就可以省去一些不必要的方法,因為它可以從抽象類中自動得到這些方法的預設實現。這其實就是預設適配模式。 依賴倒轉的缺點: 1) 因為依賴倒轉的緣故,物件的建立很可能要使用物件工廠,以避免對具體類的直接引用,此原則的使用還會導致大量的類。對不熟悉面向物件技術的工程師來說,維護這樣的系統需要較好地面向物件的設計知識。 2) 依賴倒轉原則假定所有的具體類都是會變化的,這也不總是正確的。有一些具體類可能相當穩定、不會發生變化,消費這個具體類例項的客戶端完全可以依賴這個具體型別,而不必為此發明一個抽象型別。

里氏代換原則 任何基類可以出現的地方,子類一定可以出現。 開閉原則的關鍵步驟是抽象化。而基類與子類的繼承關係就是抽象化的具體體現,里氏代換原則是對實現抽象化的具體步驟的規範。

合成/聚合複用原則 要儘量使用合成/聚合,而不是繼承關係達到複用的目的。 合成/聚合原則要求我們首先考慮合成/聚合關係,里氏代換原則要求在使用繼承時,必須確定這個繼承關係符合一定的條件(繼承是用來封裝變化的;任何基類可以出現的地方,子類一定可以出現。) 合成/聚合原則就是在一個新的物件裡面使用一些已有的物件,使之成為新物件的一部分;新的物件透過向這些物件的委派達到得複用已有功能的目的。

迪米特原則 一個軟體實體應當儘可能少的其他實體發生相互作用。模組之間的互動要少。這樣做的結果是當系統的功能需要擴充套件時,會相對更容易地做到對修改的關閉。 一個物件應當對其他物件有儘可能少的瞭解。 迪米特原則的具體操作: 1) 優先考慮將一個類設定成不變類。不變類易於設計、實現和使用。比如Java API中的String,BigInteger等類。 一個物件與外界的通訊大體上分成兩種,一種是改變這個物件的狀態,另一種是不改變這個物件的狀態的。如果一個物件的內部狀態根本就是不可能改變的,那麼它與外界的通訊當然就大大地減少。 當涉及任何一個類的時候,都首先考慮這個類的狀態是否需要改變。即便一個類必須是可變類,在給它的屬性設定賦值方法的時候,也要保持吝嗇的態度。除非真的需要,否則不要為一個屬性設定賦值方法。 2) 儘量降低一個類的訪問許可權。 3) 謹慎使用Serializable,一旦將一個類設定成Serializable,就不能再在新版本中修改這個類的內部結構,包括private的方法和句段。 4) 儘量降低成員的訪問許可權。

介面隔離原則 應當為客戶端提供儘可能小的單獨介面,而不要提供大的總介面。也即是使用多個專門的介面比使用單一的總介面要好。 介面隔離原則與迪米特都是對一個軟體實體與其他的軟體實體的通訊限制。迪米特原則要求儘可能地限制通訊的寬度和深度,接品隔離原則要求通訊的寬度儘可能地窄。這樣做的結果使一個軟體系統在功能擴充套件過程當中,不會將修改的壓力傳遞到其他物件。 一個介面相當於劇本中的一種角色,而此角色在一個舞臺上由哪一個演員來演則相當於介面的實現。因此,一個介面應當簡單地代表一個角色,而不是多個角色。如果系統涉及到多個角色的話,那麼每一個角色都應當由一個特定的介面代表。 定製服務:如果客戶端僅僅需要某一些方法的話,那麼就應當向客戶端提供這些需要的方法,而不要提供不需要的方法。(向客戶端提供public介面是一種承諾,沒有必要做出不必要的承諾,過多的承諾會給系統的維護造成不必要的負擔。)

您好，程式模式大概分為單一模式，工廠模式等一些常用的設計模。這些模式的學習，我推薦給你一本書叫老鳥的程式設計模式。嗯此外，那程式設計模式不僅僅是看書更重要的，是在實際的專案中，不管是你自己寫程式碼還是公司的專案，只有在實踐中才能得到最好的鍛鍊，所以在看書的同時不要忘記了去實踐。