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

 

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

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

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

3.三層視角--回頭再說(shuō)OO設(shè)計(jì)原則

 

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

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

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

          有時(shí)候我真的要做設(shè)計(jì)了，我想要避免陷入“細(xì)節(jié)泥沼”可是我還是無(wú)意中把細(xì)節(jié)扯進(jìn)來(lái)，這是為什么？剖析自己，我知道這是因?yàn)槲业乃伎际瞧戒伒模菦](méi)有層次的，所有的問(wèn)題攪在一起，做設(shè)計(jì)的時(shí)候難免拖泥帶水，泥沙俱下。

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

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

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

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

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

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

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

    

   視角幫助我們將問(wèn)題劃分層次，隔離

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

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

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

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

         總結(jié)一下，從Martin Fowler的三個(gè)視角來(lái)看對(duì)象：

   在概念層次上，對(duì)象是一組責(zé)任

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

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

    

   到這里我們需要對(duì)OO基本原則做一個(gè)再思考了：

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

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

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

           可以看出對(duì)象的責(zé)任和交互被盡早的定義出來(lái)，這個(gè)過(guò)程中我們沒(méi)有考慮具體對(duì)象在什么時(shí)期創(chuàng)建，映射到我們的設(shè)計(jì)過(guò)程中，創(chuàng)建型設(shè)計(jì)模式的應(yīng)用往往是在設(shè)計(jì)的后期。

    

          結(jié)論：

4. 《OO設(shè)計(jì)原則總結(jié)》一文中我提出了一個(gè)問(wèn)題：如何更好的使用這些原則？怎樣在實(shí)踐中遵守這些原則，使用三種視角思考問(wèn)題就是答案之一；
5. 做設(shè)計(jì)時(shí)，注意力首先要放在高層關(guān)系上；
6.  在面對(duì)對(duì)象設(shè)計(jì)開(kāi)發(fā)過(guò)程中以概念 規(guī)約 實(shí)現(xiàn)三個(gè)視角類思考問(wèn)題能提高我們的設(shè)計(jì)能力，避免過(guò)早陷入細(xì)節(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技術(shù)：視角的力量--再說(shuō)OO設(shè)計(jì)原則，轉(zhuǎn)載需保留來(lái)源！

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