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

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

1.         GRASP模式

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

1)  專家模式(Expert)

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

通俗點就是：該干嘛干嘛去，別管別人的閑事或者我的職責就是搞這個，別的事不管。

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

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

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

a)         B聚合了A對象

b)        B包含了A對象

c)        B紀錄了A對象的實例

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

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

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

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

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

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

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

解決方案：分配一個職責的時候要保持類的高聚合度

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

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

解決方案：在分配一個職責時要使保持低耦合度。

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

5)  控制者(Controller)

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

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

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

c)        代表真實世界中參與職責（角色控制者）的主動對象類（例，一個人的角色）

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

這是一個控制者角色職責分配的原則，就是哪些控制應該分派給哪個角色。

6)多態(tài)

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

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

7)純虛構(gòu)

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

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

8)中介者

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

9)不要和陌生人講話

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

這個模式-也被叫做(Demeter)準則。

       通俗點就是：只與你直接的朋友們通信

                            不要跟“陌生人”說話

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

2.         其他設計原則

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

一個軟件實體應當對擴展開放，對修改關(guān)閉。

意思就是在設計一個模塊的時候，應當使這個模塊在不被修改的前提下被擴展。換言之，應當可以在不修改代碼的情況下改變這個模塊的行為。

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

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

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

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

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

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

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

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

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

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