java設計模式

在學習設計模式之前，為了不讓設計模式顯得很模式，我們還必須了解乙個東西，那就是程式設計六大原則。

這些原則是指導模式的規則，我會給一些原則附上乙個例子，來說明這個原則所要表達的意思，注意，原則是死的，人是活的，所以並不是要你完完全全遵守這些規則，否則為何資料庫會有逆正規化，只是在可能的情況下，請盡量遵守。

單一職責原則（六大規則中的小蘿莉，人見人愛）：描述的意思是每個類都只負責單一的功能，切不可太多，並且乙個類應當盡量的把乙個功能做到極致。

單一職責原則是我覺得六大原則當中最應該遵守的原則，因為我在實踐過程中發現，當你在專案的開發過程中遵循它，幾乎完全不會給你的系統造成任何多餘的複雜性，反而會令你的程式看起來井然有序。

那麼翻譯成比較容易理解的話，就是說，子類一般不該重寫父類的方法，因為父類的方法一般都是對外公布的介面，是具有不可變性的，你不該將一些不該變化的東西給修改掉。

介面隔離原則（六大原則當中最挑三揀四的挑剔女，胸部極小）：也稱介面最小化原則，強調的是乙個介面擁有的行為應該盡可能的小。

如果你做不到這一點你經常會發現這樣的狀況，乙個類實現了乙個介面，裡面很多方法都是空著的，只有個別幾個方法實現了。

這樣做不僅會強制實現的人不得不實現本來不該實現的方法，最嚴重的是會給使用者造成假象，即這個實現類擁有介面中所有的行為，結果呼叫方法時卻沒收穫到想要的結果。

比如我們設計乙個手機的介面時，就要手機哪些行為是必須的，要讓這個介面盡量的小，或者通俗點講，就是裡面的行為應該都是這樣一種行為，就是說只要是手機，你就必須可以做到的。

依賴倒置原則（六大原則中最小鳥依人的姑娘，對抽象的東西非常依賴）：這個原則描述的是高層模組不該依賴於低層模組，二者都應該依賴於抽象，抽象不應該依賴於細節，細節應該依賴於抽象。

上面黑色加粗這句話是這個原則的原版描述，我來解釋下我自己的理解，這個原則描述的是乙個現實當中的事實，即實現都是易變的，而只有抽象是穩定的，所以當依賴於抽象時，實現的變化並不會影響客戶端的呼叫。

迪公尺特原則（六大原則中最害羞的姑娘，不太愛和陌生人說話）：也稱最小知道原則，即乙個類應該盡量不要知道其他類太多的東西，不要和陌生的類有太多接觸。

這個原則的制定，是因為如果乙個類知道或者說是依賴於另外乙個類太多細節，這樣會導致耦合度過高，應該將細節全部高內聚於類的內部，其他的類只需要知道這個類主要提供的功能即可。

所謂高內聚就是盡可能將乙個類的細節全部寫在這個類的內部，不要漏出來給其他類知道，否則其他類就很容易會依賴於這些細節，這樣類之間的耦合度就會急速上公升，這樣做的後果往往是乙個類隨便改點東西，依賴於它的類全部都要改。

開-閉原則（六大原則中絕對的大姐大，另外五姐妹心甘情願臣服）：最後乙個原則，一句話，對修改關閉，對擴充套件開放。

就是說我任何的改變都不需要修改原有的**，而只需要加入一些新的實現，就可以達到我的目的，這是系統設計的理想境界，但是沒有任何乙個系統可以做到這一點，哪怕我一直最欣賞的spring框架也做不到，雖說它的擴充套件性已經強到**。

這個原則更像是前五個原則的總綱，前五個原則就是圍著它轉的，只要我們盡量的遵守前五個原則，那麼設計出來的系統應該就比較符合開閉原則了，相反，如果你違背了太多，那麼你的系統或許也不太遵循開閉原則。