從設計原則談軟體開發（四）

        上一次說LSP（李氏代換原則），寫的有些著急。很多東西都沒有寫出來，這次首先來補充一下。

        其實就是補充一個例子。這是《JAVA與模式》中的一個例子，是說正方形是否可以繼承自矩形。我相信基本任何一個讀過小學的人幾乎都不會不假思索地（包括我）說，正方形就是特殊的矩形，當然可以繼承了。但是卻恰恰相反。理由如下：在矩形中應該有這樣一個方法，是改變矩形的長和寬，這個時候假設有一個方法是void Change(double 長,double 寬)，但是這個方法換到正方形中卻應該是void Change(double 邊)，也就是說此時間長度方形作為正方形的父類卻不能替換掉子類，於是也就是說不符合LSP。其實我認為這個理由有些過於牽強，如果這樣說的話，我也是同樣把正方形中的方便變為void Change(double 邊，double 邊)也未嘗不可。但是通過這個例子，我們應該認識到在LSP在不同的情況下，會產生不同的結果。還是上次舉到的企鵝是不是鳥的問題。如果鳥這個類中有著Fly()的方法，那麼企鵝就不是鳥，但是如果鳥這個類我現在並不需要鳥的Fly()的行為，而只是需要他Eat()之類的方法，那麼讓企鵝來繼承鳥類也未嘗不可。

         總之，設計模式的目的本來就是為了可擴充，可維護。所以封裝變化封裝的其實就是變化點。在不同的系統中，變化點一定是不同的，打個比方，在學生管理系統中，有一個學校的學號位元是4位，隨著這個學校的壯大，四位肯定是不夠的，那麼這個學號的位元很可能成為一個變化點。但是如果一個學校的學號是24位，那麼我想我們就沒有必要把這個做為一個變化點來處理了。

         接下來，來說一下DIP(依賴倒轉原則).DIP的內容是應該依賴於介面，而不是實現編程。這個是設計模式中一個最典型的現象，幾乎每個設計模式都會典型地滿足這個原則。其中，我們來看一下最典型的Facade（面板模式）。

         面板模式的意圖是為一個子系統或者子模組提供一個統一的介面，然後讓高層模組來調用這個介面，而不需要知道子系統中實現的細節。

         結構圖如下：（引用自http://terrylee.cnblogs.com/archive/2006/03/17/352349.html）：

        

        園子裡有很多設計模式的文章，如果朋友們有哪裡不大清楚可以去看一下那些文章，在這裡，我不具體講這個模式的內容。我來主要談下他的應用。

        您如果有過工作帶實習生的經曆，一定有過這樣的經曆。很多實習生沒有經驗，編程水品又差。當你分配給他一個模組的時候，他就做的亂七八糟。寫了一大堆類，一大堆方法，沒有注釋，也沒有什麼命名規範。然後給你。這個時候，你就得需要一點點地分析他的類，分析他的方法。結果最後下來，比你自己寫一個模組還要耽誤時間。於是，你可以採用這樣的方法。給他規定幾個介面，然後讓他去實現這些介面，然後把它寫的那些類通通封裝到一個程式集中，這樣，你就不需要知道他的內部實現細節，只需要引用他的dll，然後調用它的對外介面就可以了。

        其實，這個模式在很多地方都有應用，您如果有過軟體開發經驗，最熟悉的莫過於三層架構或者是N層架構，每層與每層之間其實不都是通過一個介面來完成互動的麼！這其實就是面板模式的典型應用。

        總結一下我對面板模式的理解：

        1.為子模組或子系統提供一個統一介面，方便其他模組調用。

        2.增加了子模組的系統獨立性，方便其他類的調用。如中的ClientA,ClientB,ClientC。

        3.易修改，我需要的只是你的對外介面，你的介面不改，我就不需要管你內部的實現邏輯。每個人維護自己的模組，升級時互不干涉。

        回到主題，DIP，還是說三層架構的例子。DIP也有這樣一種說法，是高層依賴於底層，而底層不能反過來依賴高層模組。無論是哪種說法，我們都來解釋一下。還是說那個經典的三層架構。資料訪問層，無非是整個系統的最底層模組，這個模組提供了一系列介面，供他的上一層商務邏輯層調用，而商務邏輯層只需要知道資料訪問層的對外介面，資料訪問層也根本不知道商務邏輯層的存在。商務邏輯層與使用者介面層也是一樣的關係。這其實就是模組的系統獨立性。

        今天把這個系列寫完，最後一個設計原則，ISP(介面獨立原則),這個原則的目的就是一點，如果使用者不需要一個功能，那麼就不要強迫使用者實現這個功能。

        這個其實我認為和SRP的方法是差不多的，就是分割。在SRP中，我們把一個類分離，讓一個類只有一個能夠引起他變化的原因，而在ISP中，我們是把一個介面分離，使他不會被一個使用者強迫實現，這也就是我之前說過的分離介面的藝術。介面裡的方法太多，這個介面中註定要有方法被強迫實現；介面中方法太少，就會產生很多碎介面，影響程式的運行效率。而介面其實本質上就是一個類罷了，因此我實在不覺得ISP和SRP有著什麼樣的區別。所以，在這裡就不太重複一些廢話了。

        這個系列結束了，我做個總結吧。首先，還是先聲明，我也只是個學生，沒有過大的項目經驗，所以，很多也只是自己的感性之談，各位如果有什麼看法，希望可以多多指教。

        其實，第一次看設計模式時，覺得很深奧，23種模式實在背不下來，然後就開始一遍遍地看，在做東西的時候強迫自己去應用。當看到第五遍第六遍的時候，開始發現幾乎設計模式其實都是差不多的，於是開始反過來看設計原則。然後發現，其實不同的模式，只是應用設計模式，針對各種變化點，採用不同的封裝模式，封裝不同的變化點罷了。然後開始反覆的看設計原則，一點點地理解設計原則，然後再開始看設計模式，就覺得容易了很多。在軟體中也可以比較容易地應用設計模式了。

        這個系列結束了，謝謝大家一直的關注。無論是無意點進的，還是點擊觀看的，呵呵。看到瀏覽量的增長就是我學習，和寫下去的最大的動力。就像我首頁上寫的，我學習軟體的目的就是希望自己能夠為中國IT貢獻自己的一份微薄之力。我會更加努力，希望可以像那些MVP一樣，提高自己的水平，為中國的IT真的貢獻自己的一份力量。

    

        系列參考資料：

        TerryLee:http://www.cnblogs.com/Terrylee/archive/2006/07/17/334911.html

        《大話設計模式》

        《你所必須知道的.net》

        《Head First 設計模式》