建站
咨詢
售后
建站咨詢
新聞中心
作者 | 不拔
1.面向?qū)ο笫欠先苏J(rèn)識事物的基本方法
（1）人是怎么認(rèn)識事物的
在面向?qū)ο蟪霈F(xiàn)之前，已有面向過程的分析方法，為什么面向?qū)ο蟊惶岢隽四?？究其本質(zhì)原因，人們發(fā)現(xiàn)面向過程并不是按照人正常認(rèn)識事物的方式去分析軟件，那么人究竟是怎么認(rèn)識事物的呢，Yourdon 在《面向?qū)ο蟮姆治觥芬粫刑岬?，人類認(rèn)識事物是遵循分類學(xué)的原理，分類學(xué)主要包含三點(diǎn)：區(qū)分對象及其屬性；區(qū)分整體對象及其組成部分；不同對象類的形成及區(qū)分。我們現(xiàn)在可以回想下我們認(rèn)識事物的過程，是不是和分類學(xué)所提到的 3 個要點(diǎn)很相似，看到一個事物，大概會感知到它的組成結(jié)構(gòu)是怎樣的，形狀是怎樣的，屬于什么分類。所以，人認(rèn)識事物是以對象的視角切入的，然后賦于對象具體的概念，比如蘋果、梨子、汽車等等概念名稱。
（2）分類與分層的兩種思維
我們面對的現(xiàn)實(shí)世界是非常復(fù)雜的，應(yīng)對復(fù)雜事物的有一個重要的方法即是抽象，抽象在實(shí)際應(yīng)用過程中，又體現(xiàn)在兩種方法上：分層和分類。分類即是將有差異的事物歸類到不同的分組中，正如我們常聽到的"物以類聚、人以群分"的道理一樣，產(chǎn)生分類的原因有兩點(diǎn)：一點(diǎn)是事物間的關(guān)聯(lián)緊密程度，不需要將所有的事物都耦合在一起；另一點(diǎn)是人掌握事物是有局限的，只能掌握少量的要點(diǎn)，比如 5~7 個要點(diǎn)，超過了容易忘記。
分層是通過不同的視角看事物，每一層的關(guān)注點(diǎn)是不一樣的，這種關(guān)注點(diǎn)不同是由自己的視角造成的，比如我們理解計(jì)算機(jī)，并不需要深入到二進(jìn)制電信號去理解計(jì)算機(jī)。層次特性在軟件設(shè)計(jì)中我們經(jīng)常遇到，比如計(jì)算機(jī)體系結(jié)構(gòu)、TCP 七層協(xié)議等，層次特性有一個特點(diǎn)：越往上越具體、越往下越抽象，越往上的內(nèi)容越不穩(wěn)定，也即是容易變化。
（3）問題域到解空間的映射
我們把需要解決的問題稱之為問題域，或者問題空間，把解決方案稱之為解空間。正向上一小節(jié)中提到的事物有層次特性，不同的人理解的事物是站在各自理解的視角，這樣大家的理解、溝通并不一致的。如果我們看到的問題空間是表層的，那么基于淺層次理解設(shè)計(jì)出來的方案就會不穩(wěn)定，可能下次有一個小變化導(dǎo)致方案需要重新設(shè)計(jì)。
我們可以把一個軟件劃分成三層：場景、功能和實(shí)體，場景層是經(jīng)常會變的，比如發(fā)放優(yōu)惠券場景就非常多，比如有天降紅包領(lǐng)取優(yōu)惠、分享有禮領(lǐng)取優(yōu)惠券、新人注冊領(lǐng)取優(yōu)惠券等，這種場景的更迭隨著業(yè)務(wù)的調(diào)整變化得非?？?，因此場景層是不穩(wěn)定的。功能支撐某一些的場景集合，對比場景，功能相對而言穩(wěn)定些，就像前面提到的發(fā)放優(yōu)惠券場景，本質(zhì)就是給用戶發(fā)放優(yōu)惠券，只需要提供發(fā)放優(yōu)惠券的功能即可，至于哪些場景來調(diào)用它并不關(guān)注，但功能還是基于場景的集合抽象出來的，如果場景場景類型變化了，功能也就隨之變化，比如擔(dān)保交易和預(yù)售交易就不一樣。實(shí)體是穩(wěn)定的，以擔(dān)保交易和預(yù)售交易為例，它的訂單模型大致是一樣的，只是新增加了一些信息而已。
因此，我們希望從問題空間到解空間，大家看到的、理解的是一致的，而且看到的是問題的本質(zhì)而非表象，往往場景、功能是不穩(wěn)定的，而面向過程又是以功能驅(qū)動的，所以在易變化的場景下，它面臨的問題就比較多。比較穩(wěn)定的是問題空間中的實(shí)體對象，所以面向?qū)ο蠓治鍪乾F(xiàn)實(shí)的需要。面向過程和面向?qū)ο笫莾蓚€不同的視角的分析方法：面向過程是一種歸納的分析方法，由外到內(nèi)的過程；面向?qū)ο笫且环N演繹的分析方法，由內(nèi)到外的過程。
（4）三個一致性
軟件開發(fā)會經(jīng)歷需要分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測試、上線主要階段，我們不希望每塊是割裂的，比如分析做完之后，做設(shè)計(jì)階段又要重新去做分析的工作，那么這里面就涉及到一致性的問題，即需求到分析的一致性、分析到設(shè)計(jì)的一致性、設(shè)計(jì)到編碼的一致性。這樣做的好處可以保證無信息失真，因此我們急需求一種分析設(shè)計(jì)方法能做到這一點(diǎn)，面向?qū)ο蠓治雠c設(shè)計(jì)就能做到，因此全流程是以對象作為分析與設(shè)計(jì)的目標(biāo)，在最終編碼中也都是對象。
（5）面向?qū)ο蟮牡讓舆壿?/h4>
提到面向?qū)ο?，有部分人會提到封裝、繼承、多態(tài)等特性，然后這些并不是面向?qū)ο蟮谋举|(zhì)特性，比如封裝，面向過程中也有封裝，多態(tài)面向過程也有體現(xiàn)，這些特性算不上面向?qū)ο筇赜械奶匦?。面向?qū)ο蟮牡讓舆壿嬍腔诂F(xiàn)實(shí)事物做的抽象映射：現(xiàn)實(shí)事物對應(yīng)軟件中的對象，我們討論解空間能對應(yīng)到問題空間中的對象，兩者是一一直接映射的，其它的分析方法是問題空間到解空間的間接映射。
2.面向?qū)ο蠓治雠c設(shè)計(jì)的全景圖
（1）我們面臨的問題是什么
從頂層看，我們要完成需求到編碼的工作，然而從需求到編碼又會經(jīng)過多個階段，如需求分析、方案設(shè)計(jì)等，從大的層面講，我們主要遇到三個問題：
1）做什么的問題
看似這是一個簡單的問題，但在復(fù)雜的業(yè)務(wù)場景下，對做什么的理解太重要了，因?yàn)椴煌娜藢π枨蟮睦斫馐遣煌?，比如最近做了一個項(xiàng)目，有一個業(yè)務(wù)判斷規(guī)則是只針對跨境訂單計(jì)稅，最開始開發(fā)同學(xué)的理解是判斷賣家類型是否是跨境賣家，然而到了測試階段，發(fā)現(xiàn)大家對這個業(yè)務(wù)規(guī)則判斷理解是不一致的，跨境訂單跟賣家類型是沒有關(guān)系的，真正的跨境訂單計(jì)稅場景是 shipTo（收貨地址）和 shipFrom（發(fā)貨地址）國家地址是不一樣的。在大項(xiàng)項(xiàng)目中，涉及到多個團(tuán)隊(duì)之間的協(xié)同，這樣的問題異常突出。而且從業(yè)務(wù)訴求到產(chǎn)品需求，再到技術(shù)方案，這其中是經(jīng)過了 2 次變換，每次變換是不同的角色在里面，大家的認(rèn)識也會不一樣。
2）怎么做的問題
落實(shí)到事情具體要怎么做時，往往大家并不會出大的問題，怎么做偏具體執(zhí)行階段，程序員往往在邏輯嚴(yán)密性上沒多大的問題，往往出問題是在第一個問題上，相當(dāng)于方向弄錯了，所做的工作也是無用的。
3)方法指導(dǎo)的問題
我們往往希望不勞而獲得到一種萬能的方法，能夠應(yīng)對所有的問題，同時又看不起低級的方法，比如大部分人對用例分析方法嗤之以鼻，想要能體現(xiàn)技術(shù)水平高大上的方法。其實(shí)自上世紀(jì) 70、80 年代，軟件的分析設(shè)計(jì)方法并沒有太大的變化，而且在我們大學(xué)期間都學(xué)過，只是大家并不認(rèn)為它是一種高大上的方法而已。
（2）分析到設(shè)計(jì)的過程
在本節(jié)中，我們推導(dǎo)軟件分析到設(shè)計(jì)的過程，由粗到細(xì)，最終落實(shí)到我們接觸到的 UML 知識上。從需求提出到編碼實(shí)現(xiàn)，這中間有兩個關(guān)鍵問題：一是界定目標(biāo)，即是定義清楚要做什么的問題，相當(dāng)于是我們做事的方向、目標(biāo)；二是具體如何做的問題，即通過怎樣具體的方案支撐需求目標(biāo)實(shí)現(xiàn)。因此，我們需要一種方法能夠幫助我們界定目標(biāo)和表示具體方案，而且是大家互認(rèn)的一種通用的方法。
通過用例圖可以幫我們界定目標(biāo)，用例中有三個關(guān)鍵要素：用戶、場景和目標(biāo)。比如交易下單是一個用例，它的用戶是買家，場景包含下單成功和下單失敗兩個場景，用例的目標(biāo)是買家可以購買心儀的商品。當(dāng)用例目標(biāo)確定了，相當(dāng)于界定了目標(biāo)，知道需求要做什么，這個過程要反復(fù)和業(yè)務(wù)方確認(rèn)好，至到最終大家對目標(biāo)的理解是一致的，方向?qū)α?，具體怎么做就好辦了。具體怎么做用時序圖表示，畫時序圖需要注意的一點(diǎn)是頂層的對象層次要一致，不能有的對象表示具體的實(shí)體對象，有的表示系統(tǒng)對象，即對象的層級是一致的，要么大家都是系統(tǒng)，比如導(dǎo)購系統(tǒng)調(diào)用交易系統(tǒng)，交易系統(tǒng)調(diào)用支付系統(tǒng)，要么大家都是對象，比如商品、訂單等。通過時序圖可以看到一個完整功能的執(zhí)行步驟，它就包含具體執(zhí)行的細(xì)節(jié)，如正常流程、異常流程。
其實(shí)在上面有一個問題，在畫時序圖時要確定好對象，那么這個對象是怎么來的呢？它是由健壯性圖分析出來的，它里面有三個關(guān)鍵的對象：一個是邊界對象，這個比較好理解，比如UI界面就是邊界對象；另一個是控制對象，即是控制業(yè)務(wù)流程的對象，如下單服務(wù)就可以看作是控制對象；實(shí)體對象即是問題空間中的業(yè)務(wù)對象，比如訂單。畫健壯性圖是有規(guī)則的，一般是邊界對象調(diào)用控制對象，控制對象產(chǎn)生實(shí)體對象，比如用戶下單界面是邊界對象，下單服務(wù)是控制對象，訂單就是實(shí)體對象。
3.尋找對象之路
（1）對象從哪里來
在本文第一部分第三小節(jié)中已經(jīng)提到，問題空間到解空間是一一映射，我們討論解空間中的對象時，其實(shí)它映射到問題空間中的對象，而問題空間中的對象主要來源于業(yè)務(wù)概念、業(yè)務(wù)規(guī)則、關(guān)鍵事件。大部分的對象是顯現(xiàn)的，我們通過理解業(yè)務(wù)能發(fā)現(xiàn)，有的對象是隱性的，需要我們持續(xù)對業(yè)務(wù)有更深的理解才能發(fā)掘出來。好的對象模型是需要經(jīng)過多次迭代打磨出來的，并非一次就能設(shè)計(jì)得十全十美。
（2）發(fā)現(xiàn)對象的方法
在本節(jié)中主要講述完整對象發(fā)現(xiàn)的方法，主要方法分成四個步驟：
1. 通過健壯性圖找到關(guān)鍵的實(shí)體對象；
2. 通過結(jié)構(gòu)分析方法找出更多的實(shí)體對象；
3. 將對象組成有機(jī)的對象模型；
4. 最后通過用例走查對象模型是否完備。
這里以一個案例來說明發(fā)現(xiàn)對象的過程，案例是用戶在下單時，在訂單上展示稅的金額。首先畫出健壯性圖，這里的邊界對象是下單界面，控制對象有兩個，一個是下單服務(wù)，另一個是計(jì)稅服務(wù)，實(shí)體對象也有兩個，一個是計(jì)稅單，一個是訂單。有了計(jì)稅單和訂單這兩個實(shí)體對象后，接下來通過結(jié)構(gòu)分析方法，分析出更多的對象。
對象都是有結(jié)構(gòu)的，只要我們掌握了對象的結(jié)構(gòu)，基本上就能掌握對象的概貌，因此我們從對象的結(jié)構(gòu)入手，去分析對象內(nèi)部的結(jié)構(gòu)、對象關(guān)聯(lián)的結(jié)構(gòu)，實(shí)質(zhì)上是從兩個維度出發(fā)：一是從自身的角度出發(fā)，看自己內(nèi)部還包含了哪些對象，如主訂單包含了子訂單；另一個是從外部的角度出發(fā)，看自己還與哪些對象相關(guān)聯(lián)，如計(jì)稅單與訂單是有關(guān)聯(lián)的。這種找對象的方法我稱之為結(jié)構(gòu)分析方法，因?yàn)楸旧斫Y(jié)構(gòu)又是事物本質(zhì)的一種表達(dá)方式，比如化學(xué)分子結(jié)構(gòu)決定化學(xué)現(xiàn)象。
為了更好地表達(dá)出對象的結(jié)構(gòu)，我的一個經(jīng)驗(yàn)是給對象下好定義，下定義可以從不同的維度，比如功能性維度、價(jià)值性維度、目的性維度、結(jié)構(gòu)性維度等，這里可以從結(jié)構(gòu)性的維度去給對象下定義。以計(jì)稅單為例，可以給它下一個定義：計(jì)稅單是將訂單金額信息轉(zhuǎn)成若干個標(biāo)的物計(jì)稅的單據(jù)模型，從這個定義中，我們可以看到計(jì)稅單是與訂單有關(guān)聯(lián)關(guān)系的，另一個是計(jì)稅單是包含了若干個標(biāo)的物，我們可以畫出計(jì)稅單的對象模型。
當(dāng)對象模型畫出來后，后續(xù)我們討論業(yè)務(wù)基本上圍繞這個對象模型去討論業(yè)務(wù)問題的，比如商品標(biāo)的物哪些金額要參與計(jì)稅、計(jì)稅金額的計(jì)算口徑是怎樣的，到這里，大家再體會下"問題空間到解空間一一直接映射"這句話，業(yè)務(wù)上的訴求也無非是哪些訂單費(fèi)用項(xiàng)要計(jì)稅，計(jì)稅的邏輯是怎樣的，有可能在這個場景下要扣減金本位優(yōu)惠，在另外一種場景下金本位優(yōu)惠不需要扣減，基于對象模型與產(chǎn)品、測試同學(xué)討論問題，大家都是處于同一個維度的視角看問題，溝通理解成本會少很多。對象模型是一種可視化的表達(dá)，我們大部分的溝通問題是缺乏顯性表達(dá)造成的，這句話可以這樣理解，也可以那樣理解，導(dǎo)致大家理解有偏差，現(xiàn)在用模型的形式溝通問題，很多偏差、歧義就消除了。
（3）組織對象結(jié)構(gòu)
當(dāng)我們分析出一堆的對象后，還需要經(jīng)過一定的組織，正如前面提到，人對事物理解是有局限的，不能一下子接受太多的事物，因此可以將它們分成一個個小的域，比如商品域、訂單域、稅務(wù)域等，這樣當(dāng)聚集一個問題時，可以只看某個子域里的對象模型即可。
4.如何分配職責(zé)
（1）職責(zé)是怎么來的
面向?qū)ο笞铍y的點(diǎn)有兩個：一個是找出對象；另一個是分配職責(zé)。UML 把職責(zé)定義為"類元的契約或義務(wù)"，因此職責(zé)的劃分從本質(zhì)來講還是類元本身決定的，比如訂單，它要提供訂單渲染、訂單創(chuàng)建、訂單修改、訂單查詢的義務(wù)。職責(zé)分為兩類：一類是認(rèn)知職責(zé)；另一類是行為職責(zé)。
認(rèn)知職責(zé)包含：
- 對私有數(shù)據(jù)封裝的認(rèn)知。
- 對相關(guān)對象的認(rèn)知。
- 對其能夠?qū)С龌蛴?jì)算的事物的認(rèn)識。
行為職責(zé)包含：
- 自己執(zhí)行的行為，包括創(chuàng)建對象或計(jì)算。
- 初始化其它對象的動作。
- 控制或協(xié)調(diào)其它對象的活動。
（2）分配職責(zé)的邏輯
上一小節(jié)中提到的職責(zé)有兩類，認(rèn)知職責(zé)是對象自身的認(rèn)知范圍，即它只能基于自身屬性完成相應(yīng)的職責(zé)，舉一個例子，假如一主多子的訂單，要計(jì)算總的訂單金額，怎么分配職責(zé)呢？首先商品只能查到自身價(jià)格的信息，它的認(rèn)識是基于商品 price 屬性，一個子訂單可以有多個商品，那么它也只能計(jì)算出子訂單的金額信息，它的認(rèn)知是基于 item 和 quantity兩個屬性，主訂單包含所有子訂單的信息，那么就可以計(jì)算出總的訂單金額。
從上面的例子中我們可以看出，認(rèn)知職責(zé)是基于對象屬性的，正所謂"不在其位、不謀其政"，認(rèn)知職責(zé)一定不會超過它的認(rèn)識范圍的。行為職責(zé)是偏領(lǐng)域服務(wù)的，有的時候一個職責(zé)不屬于某一個對象，比如轉(zhuǎn)賬，就是一個行為，讓其它的職責(zé)承擔(dān)并不合適，這類行為職責(zé)往往是一個顯著的業(yè)務(wù)活動，比如訂單渲染、訂單創(chuàng)建就是行為職責(zé)而非認(rèn)知職責(zé)。分配職責(zé)一定要遵循"信息專家"模式，它的含義是將職責(zé)分配給具有完成該職責(zé)所需要信息的那個類，也即上面提到的認(rèn)識產(chǎn)生職責(zé)。
（3）驗(yàn)證職責(zé)分配的合理性
我們期望分配的職責(zé)滿足"高內(nèi)聚、低耦合"，怎么檢驗(yàn)?zāi)?？我們再回過頭來思考職責(zé)的定義：類元的契約或義務(wù)，換句話講，職責(zé)是滿足其它對象來調(diào)用的，這個就與我們畫時序圖的目的是一致的，每次發(fā)生一次調(diào)用，即意味著其它的對象要提供一個職責(zé)出來，因此我們可以在時序圖中看對象間的調(diào)用頻次，如果一個對象被調(diào)用得非常頻繁，有可能這個對象承擔(dān)了太多的職責(zé)，是不是可以對其拆分，把職責(zé)分配一部分出去。因此，對象職責(zé)分配并不是一蹴而就的，需要不斷審視、檢驗(yàn)。分配職責(zé)是要遵循一定的原則，如創(chuàng)建者模式、信息專家模式、純虛構(gòu)模式等，這些原則會在下一篇中單獨(dú)去講。
5.案例
（1）案例背景
這里舉一個例子，說明面向過程和面向?qū)ο笤诜治?、編寫代碼的差異性，計(jì)稅需要判斷是否滿足計(jì)稅規(guī)則，比如虛擬商品不計(jì)稅（手機(jī)充值之類）、有些免稅地址不計(jì)稅、小 B 買家也不計(jì)稅等，因此需要提供一個計(jì)稅過濾判斷邏輯。
（2）常規(guī)面向過程實(shí)現(xiàn)
面向過程的思路很簡單，提供一個過濾方法依次處理下面邏輯：過濾虛擬商品計(jì)稅請求、過濾免稅地址計(jì)稅請求、過濾小 B 買家計(jì)稅請求。
public void filter(Listrequest){
// 過濾虛擬商品計(jì)稅請求
filterVirtualItem(request);
// 過濾免稅地址計(jì)稅請求(即外島)
filterOuterIsland(request);
// 過濾小B買家計(jì)稅請求
filterPurchaseType(reqeust);
}
（3）面向?qū)ο髮?shí)現(xiàn)
面向過程是從過程視角或者是功能視角分析問題，而面向?qū)ο笫菑膶ο蟮囊暯欠治鰡栴}，過濾計(jì)稅請求是計(jì)稅過濾器判斷計(jì)稅請求是否滿足計(jì)稅規(guī)則，這里就包含了兩個對象：計(jì)稅過濾器和計(jì)稅規(guī)則，判斷是否滿足計(jì)稅要求這個職責(zé)應(yīng)該是在具體的計(jì)稅規(guī)則處理器中，比如是否是小 B 買家等，因此我們可以畫出對象模型。
關(guān)鍵代碼如下：
public abstract class AbstractRuleHandler {
/**
* 抽象的業(yè)務(wù)規(guī)則處理
*
* @param request
*/
public abstract void handler(TaxCalculateRequest request);
/**
* 構(gòu)造函數(shù)里完成注冊
*/
public AbstractRuleHandler() {
TaxCaluclateFilter.register(this);
}
}
6.總結(jié)
在文章中提到，面向?qū)ο蟮牡讓舆壿嬍腔诂F(xiàn)實(shí)事物做的抽象映射，重要的不是要面向?qū)ο缶唧w技術(shù)的使用上，而是分析問題的思維上，這是最難的，它最大的好處是問題空間到解空間是一一直接映射的，請注意是一一直接映射，它意味著我們在討論方案的時候，完全可以映射到問題空間，如果是間接映射，也就意味著設(shè)計(jì)的方案后面會面臨重新設(shè)計(jì)的可能性，因?yàn)樗腔趫鼍盎蚬δ茏龀龅臍w納設(shè)計(jì)，而且是表層的設(shè)計(jì)。真正掌握了面向?qū)ο蠓治龊驮O(shè)計(jì)的方法，也體會到其中的益處，對理解業(yè)務(wù)、方案設(shè)計(jì)、編碼開發(fā)都有好處。
文章標(biāo)題：面向?qū)ο蠓治雠c設(shè)計(jì)的底層邏輯
文章URL：http://fisionsoft.com.cn/article/djcdisg.html
