這里說的幾個(gè)軟件模式是屬于原則層次一級的，比GoF等軟件設(shè)計(jì)模式高一層。遵循這些原則可以使我們設(shè)計(jì)出來的軟件有更好的可復(fù)用性和可維護(hù)性，同樣GoF等軟件設(shè)計(jì)模式也是遵循這一原則的。

     下邊的條列只是簡單的介紹，以便忘記了偶爾過來游覽一下，詳細(xì)的介紹請參閱：《Java模式》、《UML和模式應(yīng)用-面向?qū)ο蠓治雠c設(shè)計(jì)導(dǎo)論》

1.         GRASP模式

GRASP是General Responsibility Assignment Software Pattern(通用指責(zé)分配軟件模式)的縮寫。

1)  專家模式(Expert)

解決方案：將職責(zé)分配給具有履行職責(zé)所需要的信息的類

通俗點(diǎn)就是：該干嘛干嘛去，別管別人的閑事或者我的職責(zé)就是搞這個(gè)，別的事不管。

舉個(gè)簡單的例子，如果有一個(gè)類是專門處理字符串相關(guān)的類，那么這個(gè)類只能有字符串處理相關(guān)的方法，而不要將日期處理的方法加進(jìn)來。也就是提高軟件高內(nèi)聚一種原則。

2)  創(chuàng)建者(Creator)

解決方案：將創(chuàng)建一個(gè)類A的實(shí)例的職責(zé)指派給類B的實(shí)例，如果下列條件滿足的話：

a)         B聚合了A對象

b)        B包含了A對象

c)        B紀(jì)錄了A對象的實(shí)例

d)        B要經(jīng)常使用A對象

e)         當(dāng)A的實(shí)例被創(chuàng)建時(shí)，B具有要傳遞給A的初始化數(shù)據(jù)(也就是說B是創(chuàng)建A的實(shí)例這項(xiàng)任務(wù)的信息專家)

f)         B是A對象的創(chuàng)建者

如果以上條件中不止一條成立的話，那么最好讓B聚集或包含A

通俗點(diǎn)就是：我要用你所以我來創(chuàng)建你，請不要讓別人創(chuàng)建你

這個(gè)模式是支持低耦合度原則的一個(gè)體現(xiàn)

3)  高聚合度或高內(nèi)聚(High Cohesion)

解決方案：分配一個(gè)職責(zé)的時(shí)候要保持類的高聚合度

聚合度或內(nèi)聚度(cohesion)是一個(gè)類中的各個(gè)職責(zé)之間相關(guān)程度和集中程度的度量。一個(gè)具有高度相關(guān)職責(zé)的類并且這個(gè)類所能完成的工作量不是特別巨大，那么他就是具有高聚合度。

4)  低耦合度或低耦合(Low Coupling)

解決方案：在分配一個(gè)職責(zé)時(shí)要使保持低耦合度。

耦合度(coupling)是一個(gè)類與其它類關(guān)聯(lián)、知道其他類的信息或者依賴其他類的強(qiáng)弱程度的度量。一個(gè)具有低(弱)耦合度的類不依賴于太多的其他類。

5)  控制者(Controller)

解決方案：將處理系統(tǒng)事件消息的職責(zé)分派給代表下列事物的類：

a)         代表整個(gè)“系統(tǒng)”的類（虛包控制者）

b)        代表整個(gè)企業(yè)或組織的類（虛包控制者）

c)        代表真實(shí)世界中參與職責(zé)（角色控制者）的主動(dòng)對象類（例，一個(gè)人的角色）

d)        代表一個(gè)用況中所有事件的人工處理者類，通常用“<用例名>處理者”的方式命名（用例控制者）

這是一個(gè)控制者角色職責(zé)分配的原則，就是哪些控制應(yīng)該分派給哪個(gè)角色。

6)多態(tài)

當(dāng)相關(guān)的可選擇的方法或行為隨著類型變化時(shí)，將行為的職責(zé)-使用多態(tài)的操作-分配給那些行為變化的類型

也就是說盡量對抽象層編程，用多態(tài)的方法來判斷具體應(yīng)該使用那個(gè)類，而不是用if instanceof 來判斷該類是什么接來執(zhí)行什么。

7)純虛構(gòu)

一個(gè)純虛構(gòu)意味著虛構(gòu)某些事物，而不是到了迫不得已我們才這樣做。

例，我們的Sale類的數(shù)據(jù)要存入數(shù)據(jù)庫，但是他必須和數(shù)據(jù)庫接口相連接，如果將接口連接放入Sale類中勢必增加該類的耦合度，所以我們可以虛構(gòu)一個(gè)類來處理與數(shù)據(jù)庫接口連接的問題。這個(gè)類就是我們虛構(gòu)出來的一個(gè)事物。

8)中介者

將職責(zé)分配給一個(gè)中間對象以便在其他構(gòu)件或服務(wù)之間仲裁，這樣這些構(gòu)件或服務(wù)沒有被直接耦合。這個(gè)中間對象(intermediary)在其他構(gòu)件或服務(wù)間創(chuàng)建一個(gè)中介者(Indirection)。這個(gè)中間對象也就事7)中的純虛構(gòu)。

9)不要和陌生人講話

分配職責(zé)給一個(gè)客戶端的直接對象以使它與一個(gè)間接對象進(jìn)行協(xié)作，這樣客戶端無需知道這個(gè)間接對象。

這個(gè)模式-也被叫做(Demeter)準(zhǔn)則。

       通俗點(diǎn)就是：只與你直接的朋友們通信

                            不要跟“陌生人”說話

每個(gè)軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關(guān)的軟件單位

2.         其他設(shè)計(jì)原則

1)“開-閉”原則（Open-Closed Principle，或者OCP）

一個(gè)軟件實(shí)體應(yīng)當(dāng)對擴(kuò)展開放，對修改關(guān)閉。

意思就是在設(shè)計(jì)一個(gè)模塊的時(shí)候，應(yīng)當(dāng)使這個(gè)模塊在不被修改的前提下被擴(kuò)展。換言之，應(yīng)當(dāng)可以在不修改代碼的情況下改變這個(gè)模塊的行為。

2)里氏代換原則（Liskov Substitution Principle, 或者LSP）

這個(gè)就是盡量用多態(tài)的方法編程，也就是GRASP模式中的多態(tài)。

3)依賴倒轉(zhuǎn)原則（Dependency Inversion Principle, 或者DIP）

依賴倒轉(zhuǎn)原則講的是：要依賴于抽象，不要依賴于具體

就是說我們盡量在抽象層進(jìn)行控制編程，要針對接口編程，不要針對實(shí)現(xiàn)編程。

4)接口隔離原則（Interface Segregation Principle, 或者ISP）

使用多個(gè)專門的接口比使用單一的總接口要好。也就是，從一個(gè)客戶類的角度來講：一個(gè)類對另外一個(gè)類的依賴性應(yīng)當(dāng)是建立在最小的接口上的。

5)組合/聚合復(fù)用原則（Composition/Aggregation Principle, 或者CARP）

又叫合成復(fù)用原則。原則就是在一個(gè)新的對象里面使用一些已有的對象，使之成為新對象的一部分：新的對象通過向這些對象的委派達(dá)到復(fù)用已有功能的目的。也就是，要盡量使用類的合成復(fù)用，盡量不要使用繼承

6)變與不變的分離
    更擴(kuò)展一步,就是將不同變化的組件進(jìn)行隔離.最簡單的例子就是javabean中的存取器。它隔離了不變的接口和變化的內(nèi)部屬性。這方面體現(xiàn)最好的個(gè)人覺得就是eclipse，通過變化的插件，eclipse可以用來實(shí)現(xiàn)任何功能。