【推薦】再說OO設計原則

1.為什麼我們過早的糾纏於細節？問題的本質是什嗎？
         做設計時過早的關注細節幾乎是多數程式員的泥沼，也是我自己的頑疾。就像我剛開始工作不久要做一個自動更新的系統，設計會議上開發組老大定了使用FTP協議完成，你知道我腦袋裡面想的是什嗎？--“Indy組件好像不支援中文”…...

      過早的關注細節，大體上可能有兩種原因：1.經驗豐富，舉一反三，綱舉目張，各種技術玄妙如數家珍 2.沒有什麼經驗，只知道點技術細節，難以跳出思維桎梏；我知道我是後者，以前是現在也是。

       人是有惰性的，人們習慣性的做自己熟練精通的事情。所以做設計的時候，當對大架構缺少把握能力的時候，潛意識裡我更願意去思考那些細節。這是在偷懶，所有的技術細節、問題都是沒有疑問的(我們不是做科研)，或者是有疑問你可以很容易獲得解答無論是開發文檔還是在社區。細節的解決方案總是顯而易見，但並非肯定是最好的入手點。

       有時候我真的要做設計了，我想要避免陷入“細節泥沼”可是我還是無意中把細節扯進來，這是為什嗎？剖析自己，我知道這是因為我的思考是平鋪的，是沒有層次的，所有的問題攪在一起，做設計的時候難免拖泥帶水，泥沙俱下。

       思考沒有層次這就是問題本質所在，我要做好設計，而思維方式上的缺陷成為我的命門所在，我該怎麼辦？說實話我一直在走彎路，而且不知道現在的這條路是否對頭。
        “善良的人在追求的中縱然迷茫，卻終將意識到有一條正途.”-----《浮士德》

 

2.    .2.救命稻草--Martin Fowler的三層視角理論

     Martin Fowler在他的著作 《UML Distilled》中提到了三層視角（perspective）：概念視角，規約視角，實現視角。

使用三種視角看軟體開發，我們可以得到這樣的描述：

概念視角：呈現所研究領域中的各種概念，得出概念性模型的時候應該盡量少德或者不考慮它的實現，這個視角要回答的問題是：軟體要負責什嗎？是策略性的結論

規約視角：我們現在考慮的是軟體，但是我們關注的是軟體的介面而不是實現。規約視角要回答的問題是：怎麼使用軟體？這個層次關注的是軟體各部分的交流。

實現：這時我們考慮的是代碼本身但是許多方面我們使用規約視角可能會更好，軟體在規約層交流在實現層執行。

視角協助我們將問題劃分層次，隔離

        從上面的描述我們很明顯得看到“軟體開發”所設計牽扯的問題已經被劃分到三個不同的層次，在每一個層次我們都要有特定的思考成果。在高層沒有思考成熟的時候我們不往下一個層次進行，按照這樣一個原則，細節被隔離在思維的圍牆之外。
       下面一個問題就是，在設計中過程，三種視角對問題進行層次劃分能起到什麼作用？

 

3.     3.三層視角--回頭再說OO設計原則
       概念視角，我們得到了領域的各種概念，對象要負責什嗎？這是一個高層策略，它通常是高度抽象的，是一個策略性的結論，關鍵一點：它是穩定的。只要概念不變要求者就和細節的變化隔離開了；細節問題的處理應該儘可能的往後延遲。關注對象要做什麼,而不是怎麼做，將這些細節實現隱藏起來協助我們免於過早的介入細節。關注對象要做什麼，就是在定義對象的責任，理解對象的最佳方式就是把它看作有責任的東西。

       規約視角，對象是一組可以被其它對象或對象自己調用的方法（也就是行為，怎麼使用軟體?）；對象是有責任的我只需要關注對象的公用介面-這是我要求對象完成某些工作的交流渠道。只要對象的介面告訴我們它可以完成某項職責，不關注對象是怎樣啟動並執行。關注動機而非實現，是基本的OO設計原則，將實現隱藏在介面之後實際上是將對象的實現與它們的對象解耦了。

      實現視角，對象是代碼和資料，以及它們之間的計算互動(軟體怎麼履行自己的責任?)；走到這裡我們才開始討論實現細節。

      總結一下，從Martin Fowler的三個視角來看對象：

在概念層次上，對象是一組責任

規約層次上，對象是一組可以被其他對象或者對象自己調用的方法

在實現層次上對象是代碼和資料，以及它們的計算互動

到這裡我們需要對OO基本原則做一個再思考了：

        從概念層到規約層我們的思考成果都是抽象的，他們是一個個抽象的概念，是一個個的行為；我們在概念層是對象的責任清晰化，在規約層我們看擁有不同責任的對象之間是怎樣協作的。協作方式就是一種對象與對象之間的契約。對象的責任怎麼劃分？對象應該對自己負責，對象的責任應該盡量單一，這就是SRP原則。規約層我們定義的是對象間的互動契約，也就是介面，關注介面而非實現，我們做到了。

       概念層是最穩定的，規約層次之，實現是最不穩定的。所以高層模組不應該依賴低層模組，兩者都應該依賴於抽象。細節應該依賴於抽象，這就是DIP原則。這個原則隱含的意思是：對象之間只在概念層次存在耦合，在實現層次不能耦合！

       我們定義的所有互動都是使用基類，那如果實現的時候某一個子類不能完全代替基類呢？那是不是所有的互動契約都出現問題了？一個從基類派生的子類應該支援基類的所有行為，子類必能替換基類，這就是LSP原則。

        可以看出對象的責任和互動被儘早的定義出來，這個過程中我們沒有考慮具體對象在什麼時期建立，映射到我們的設計過程中，建立型設計模式的應用往往是在設計的後期。

 

4.結論：

· 《OO設計原則總結》一文中我提出了一個問題：

  如何更好的使用這些原則？怎樣在實踐中遵守這些原則，使用三種視角思考問題就是答案之一；

· 做設計時，注意力首先要放在高層關係上；

· 在面對對象設計開發過程中以概念 規約 實現三個視角類思考問題能提高我們的設計能力，避免過早陷入細節泥沼。