《OO設計原則總結(jié)》一文中我提出了一個問題：如何更好的使用這些原則？怎樣在實踐中遵守這些原則，使用三種視角思考問題就是答案之一；

 

本文內(nèi)容包括：

1.為什么我們過早的糾纏于細節(jié)？問題的本質(zhì)是什么？

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

3.三層視角--回頭再說OO設計原則

 

1. 為什么我們過早的糾纏于細節(jié)？問題的本質(zhì)是什么？
            做設計時過早的關注細節(jié)幾乎是多數(shù)程序員的泥沼，也是我自己的頑疾。就像我剛開始工作不久要做一個自動更新的系統(tǒng)，設計會議上開發(fā)組老大定了使用FTP協(xié)議完成，你知道我腦袋里面想的是什么？--“Indy組件好像不支持中文”…...

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

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

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

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

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

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

   使用三種視角看軟件開發(fā)，我們可以得到這樣的描述：

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

   規(guī)約視角：我們現(xiàn)在考慮的是軟件，但是我們關注的是軟件的接口而不是實現(xiàn)。規(guī)約視角要回答的問題是：怎么使用軟件？這個層次關注的是軟件各部分的交流。

   實現(xiàn)：這時我們考慮的是代碼本身但是許多方面我們使用規(guī)約視角可能會更好，軟件在規(guī)約層交流在實現(xiàn)層執(zhí)行。

    

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

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

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

          規(guī)約視角，對象是一組可以被其它對象或?qū)ο笞约赫{(diào)用的方法（也就是行為，怎么使用軟件?）；對象是有責任的我只需要關注對象的公共接口-這是我要求對象完成某些工作的交流渠道。只要對象的接口告訴我們它可以完成某項職責，不關注對象是怎樣運行的。關注動機而非實現(xiàn)，是基本的OO設計原則，將實現(xiàn)隱藏在接口之后實際上是將對象的實現(xiàn)與它們的對象解耦了。

         實現(xiàn)視角，對象是代碼和數(shù)據(jù)，以及它們之間的計算交互(軟件怎么履行自己的責任?)；走到這里我們才開始討論實現(xiàn)細節(jié)。

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

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

   規(guī)約層次上，對象是一組可以被其他對象或者對象自己調(diào)用的方法

   在實現(xiàn)層次上對象是代碼和數(shù)據(jù)，以及它們的計算交互

    

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

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

          概念層是最穩(wěn)定的，規(guī)約層次之，實現(xiàn)是最不穩(wěn)定的。所以高層模塊不應該依賴低層模塊，兩者都應該依賴于抽象。細節(jié)應該依賴于抽象，這就是DIP原則。這個原則隱含的意思是：對象之間只在概念層次存在耦合，在實現(xiàn)層次不能耦合！

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

           可以看出對象的責任和交互被盡早的定義出來，這個過程中我們沒有考慮具體對象在什么時期創(chuàng)建，映射到我們的設計過程中，創(chuàng)建型設計模式的應用往往是在設計的后期。

    

          結(jié)論：

4. 《OO設計原則總結(jié)》一文中我提出了一個問題：如何更好的使用這些原則？怎樣在實踐中遵守這些原則，使用三種視角思考問題就是答案之一；
5. 做設計時，注意力首先要放在高層關系上；
6.  在面對對象設計開發(fā)過程中以概念 規(guī)約 實現(xiàn)三個視角類思考問題能提高我們的設計能力，避免過早陷入細節(jié)泥沼。

    

   附： Martin Fowler著作 《UML Distilled》提到三種視角（perspective）的段落：
    

   Following the lead of Steve Cook and John Daniels (1994), I say that there are three perspectives you can use in drawing class diagrams- or indeed any model, but this breakdown is most noticeable in connection with class diagrams.

   • Conceptual. 
     If you take the conceptual perspective, you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them, but there is often no direct mapping. Indeed, a conceptual model should be drawn with little or no regard for the software that might implement it, so it can be considered language-independent. (Cook and Daniels call this the essential perspective.)
   • Specification. 
     Now we are looking at software, but we are looking at the interfaces of the software, not the implementation. Object-oriented development puts a great emphasis on the difference between interface and implementation, but this is often overlooked in practice because the notion of class in an OO language combines both interface and implementation. This is a shame, because the key to effective OO programming is to program to a class's interface rather than to its implementation. There is a good discussion of this in the first chapter of Gamma, Helm, Johnson, and Vlissides (1995). You often hear the word "type" used to talk about an interface of a class; a type can have many classes that implement it, and a class can implement many types.
   • Implementation. 
     In this view, we really do have classes and we are laying the implementation bare. This is probably the perspective used most often, but in many ways the specification perspective is often a better one to take.

   Understanding perspective is crucial to both drawing and reading class diagrams. Unfortunately, the lines between the perspectives are not sharp, and most modelers do not take care to get their perspective sorted out when they are drawing. Although I've found that this often does not matter too much between the conceptual perspective and the specification perspective, it is very important to separate the specification perspective and the implementation perspective.

   As I talk about class diagrams further, I will stress how each element of the technique depends heavily on the perspective.

   Perspective is not part of the formal UML, but I have found it extremely valuable when modeling and when reviewing models. The UML can be used with all three perspectives. By tagging classes with a stereotype (see page 79), you can provide an indication of the perspective. You mark classes with <> to show the implementation perspective, and with <> for the specification and conceptual perspectives.

    

   《UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language》

   Martin Fowler   Kendall Scott

   Publisher: Addison Wesley

                   Second Edition August 18, 1999

                   ISBN: 0-201-65783-X, 224 pages

    

NET技術：視角的力量--再說OO設計原則，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。