自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

面向?qū)ο蠓治雠c設(shè)計(jì)的底層邏輯

開發(fā) 項(xiàng)目管理
我們現(xiàn)在可以回想下我們認(rèn)識(shí)事物的過程,是不是和分類學(xué)所提到的 3 個(gè)要點(diǎn)很相似,看到一個(gè)事物,大概會(huì)感知到它的組成結(jié)構(gòu)是怎樣的,形狀是怎樣的,屬于什么分類。所以,人認(rèn)識(shí)事物是以對(duì)象的視角切入的,然后賦于對(duì)象具體的概念,比如蘋果、梨子、汽車等等概念名稱。

作者 |  不拔

1.面向?qū)ο笫欠先苏J(rèn)識(shí)事物的基本方法

(1)人是怎么認(rèn)識(shí)事物的

在面向?qū)ο蟪霈F(xiàn)之前,已有面向過程的分析方法,為什么面向?qū)ο蟊惶岢隽四??究其本質(zhì)原因,人們發(fā)現(xiàn)面向過程并不是按照人正常認(rèn)識(shí)事物的方式去分析軟件,那么人究竟是怎么認(rèn)識(shí)事物的呢,Yourdon 在《面向?qū)ο蟮姆治觥芬粫刑岬剑祟愓J(rèn)識(shí)事物是遵循分類學(xué)的原理,分類學(xué)主要包含三點(diǎn):區(qū)分對(duì)象及其屬性;區(qū)分整體對(duì)象及其組成部分;不同對(duì)象類的形成及區(qū)分。我們現(xiàn)在可以回想下我們認(rèn)識(shí)事物的過程,是不是和分類學(xué)所提到的 3 個(gè)要點(diǎn)很相似,看到一個(gè)事物,大概會(huì)感知到它的組成結(jié)構(gòu)是怎樣的,形狀是怎樣的,屬于什么分類。所以,人認(rèn)識(shí)事物是以對(duì)象的視角切入的,然后賦于對(duì)象具體的概念,比如蘋果、梨子、汽車等等概念名稱。

圖片

(2)分類與分層的兩種思維

我們面對(duì)的現(xiàn)實(shí)世界是非常復(fù)雜的,應(yīng)對(duì)復(fù)雜事物的有一個(gè)重要的方法即是抽象,抽象在實(shí)際應(yīng)用過程中,又體現(xiàn)在兩種方法上:分層和分類。分類即是將有差異的事物歸類到不同的分組中,正如我們常聽到的"物以類聚、人以群分"的道理一樣,產(chǎn)生分類的原因有兩點(diǎn):一點(diǎn)是事物間的關(guān)聯(lián)緊密程度,不需要將所有的事物都耦合在一起;另一點(diǎn)是人掌握事物是有局限的,只能掌握少量的要點(diǎn),比如 5~7 個(gè)要點(diǎn),超過了容易忘記。

圖片

分層是通過不同的視角看事物,每一層的關(guān)注點(diǎn)是不一樣的,這種關(guān)注點(diǎn)不同是由自己的視角造成的,比如我們理解計(jì)算機(jī),并不需要深入到二進(jìn)制電信號(hào)去理解計(jì)算機(jī)。層次特性在軟件設(shè)計(jì)中我們經(jīng)常遇到,比如計(jì)算機(jī)體系結(jié)構(gòu)、TCP 七層協(xié)議等,層次特性有一個(gè)特點(diǎn):越往上越具體、越往下越抽象,越往上的內(nèi)容越不穩(wěn)定,也即是容易變化。

圖片

(3)問題域到解空間的映射

我們把需要解決的問題稱之為問題域,或者問題空間,把解決方案稱之為解空間。正向上一小節(jié)中提到的事物有層次特性,不同的人理解的事物是站在各自理解的視角,這樣大家的理解、溝通并不一致的。如果我們看到的問題空間是表層的,那么基于淺層次理解設(shè)計(jì)出來(lái)的方案就會(huì)不穩(wěn)定,可能下次有一個(gè)小變化導(dǎo)致方案需要重新設(shè)計(jì)。

圖片

我們可以把一個(gè)軟件劃分成三層:場(chǎng)景、功能和實(shí)體,場(chǎng)景層是經(jīng)常會(huì)變的,比如發(fā)放優(yōu)惠券場(chǎng)景就非常多,比如有天降紅包領(lǐng)取優(yōu)惠、分享有禮領(lǐng)取優(yōu)惠券、新人注冊(cè)領(lǐng)取優(yōu)惠券等,這種場(chǎng)景的更迭隨著業(yè)務(wù)的調(diào)整變化得非常快,因此場(chǎng)景層是不穩(wěn)定的。功能支撐某一些的場(chǎng)景集合,對(duì)比場(chǎng)景,功能相對(duì)而言穩(wěn)定些,就像前面提到的發(fā)放優(yōu)惠券場(chǎng)景,本質(zhì)就是給用戶發(fā)放優(yōu)惠券,只需要提供發(fā)放優(yōu)惠券的功能即可,至于哪些場(chǎng)景來(lái)調(diào)用它并不關(guān)注,但功能還是基于場(chǎng)景的集合抽象出來(lái)的,如果場(chǎng)景場(chǎng)景類型變化了,功能也就隨之變化,比如擔(dān)保交易和預(yù)售交易就不一樣。實(shí)體是穩(wěn)定的,以擔(dān)保交易和預(yù)售交易為例,它的訂單模型大致是一樣的,只是新增加了一些信息而已。

圖片

因此,我們希望從問題空間到解空間,大家看到的、理解的是一致的,而且看到的是問題的本質(zhì)而非表象,往往場(chǎng)景、功能是不穩(wěn)定的,而面向過程又是以功能驅(qū)動(dòng)的,所以在易變化的場(chǎng)景下,它面臨的問題就比較多。比較穩(wěn)定的是問題空間中的實(shí)體對(duì)象,所以面向?qū)ο蠓治鍪乾F(xiàn)實(shí)的需要。面向過程和面向?qū)ο笫莾蓚€(gè)不同的視角的分析方法:面向過程是一種歸納的分析方法,由外到內(nèi)的過程;面向?qū)ο笫且环N演繹的分析方法,由內(nèi)到外的過程。

(4)三個(gè)一致性

軟件開發(fā)會(huì)經(jīng)歷需要分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測(cè)試、上線主要階段,我們不希望每塊是割裂的,比如分析做完之后,做設(shè)計(jì)階段又要重新去做分析的工作,那么這里面就涉及到一致性的問題,即需求到分析的一致性、分析到設(shè)計(jì)的一致性、設(shè)計(jì)到編碼的一致性。這樣做的好處可以保證無(wú)信息失真,因此我們急需求一種分析設(shè)計(jì)方法能做到這一點(diǎn),面向?qū)ο蠓治雠c設(shè)計(jì)就能做到,因此全流程是以對(duì)象作為分析與設(shè)計(jì)的目標(biāo),在最終編碼中也都是對(duì)象。

圖片

(5)面向?qū)ο蟮牡讓舆壿?/h4>

提到面向?qū)ο?,有部分人?huì)提到封裝、繼承、多態(tài)等特性,然后這些并不是面向?qū)ο蟮谋举|(zhì)特性,比如封裝,面向過程中也有封裝,多態(tài)面向過程也有體現(xiàn),這些特性算不上面向?qū)ο筇赜械奶匦?。面向?qū)ο蟮牡讓舆壿嬍腔诂F(xiàn)實(shí)事物做的抽象映射:現(xiàn)實(shí)事物對(duì)應(yīng)軟件中的對(duì)象,我們討論解空間能對(duì)應(yīng)到問題空間中的對(duì)象,兩者是一一直接映射的,其它的分析方法是問題空間到解空間的間接映射。

圖片

2.面向?qū)ο蠓治雠c設(shè)計(jì)的全景圖

(1)我們面臨的問題是什么

從頂層看,我們要完成需求到編碼的工作,然而從需求到編碼又會(huì)經(jīng)過多個(gè)階段,如需求分析、方案設(shè)計(jì)等,從大的層面講,我們主要遇到三個(gè)問題:

1)做什么的問題

看似這是一個(gè)簡(jiǎn)單的問題,但在復(fù)雜的業(yè)務(wù)場(chǎng)景下,對(duì)做什么的理解太重要了,因?yàn)椴煌娜藢?duì)需求的理解是不同的,比如最近做了一個(gè)項(xiàng)目,有一個(gè)業(yè)務(wù)判斷規(guī)則是只針對(duì)跨境訂單計(jì)稅,最開始開發(fā)同學(xué)的理解是判斷賣家類型是否是跨境賣家,然而到了測(cè)試階段,發(fā)現(xiàn)大家對(duì)這個(gè)業(yè)務(wù)規(guī)則判斷理解是不一致的,跨境訂單跟賣家類型是沒有關(guān)系的,真正的跨境訂單計(jì)稅場(chǎng)景是 shipTo(收貨地址)和 shipFrom(發(fā)貨地址)國(guó)家地址是不一樣的。在大項(xiàng)項(xiàng)目中,涉及到多個(gè)團(tuán)隊(duì)之間的協(xié)同,這樣的問題異常突出。而且從業(yè)務(wù)訴求到產(chǎn)品需求,再到技術(shù)方案,這其中是經(jīng)過了 2 次變換,每次變換是不同的角色在里面,大家的認(rèn)識(shí)也會(huì)不一樣。

2)怎么做的問題

落實(shí)到事情具體要怎么做時(shí),往往大家并不會(huì)出大的問題,怎么做偏具體執(zhí)行階段,程序員往往在邏輯嚴(yán)密性上沒多大的問題,往往出問題是在第一個(gè)問題上,相當(dāng)于方向弄錯(cuò)了,所做的工作也是無(wú)用的。

3)方法指導(dǎo)的問題

我們往往希望不勞而獲得到一種萬(wàn)能的方法,能夠應(yīng)對(duì)所有的問題,同時(shí)又看不起低級(jí)的方法,比如大部分人對(duì)用例分析方法嗤之以鼻,想要能體現(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í)上。從需求提出到編碼實(shí)現(xiàn),這中間有兩個(gè)關(guān)鍵問題:一是界定目標(biāo),即是定義清楚要做什么的問題,相當(dāng)于是我們做事的方向、目標(biāo);二是具體如何做的問題,即通過怎樣具體的方案支撐需求目標(biāo)實(shí)現(xiàn)。因此,我們需要一種方法能夠幫助我們界定目標(biāo)和表示具體方案,而且是大家互認(rèn)的一種通用的方法。

圖片

通過用例圖可以幫我們界定目標(biāo),用例中有三個(gè)關(guān)鍵要素:用戶、場(chǎng)景和目標(biāo)。比如交易下單是一個(gè)用例,它的用戶是買家,場(chǎng)景包含下單成功和下單失敗兩個(gè)場(chǎng)景,用例的目標(biāo)是買家可以購(gòu)買心儀的商品。當(dāng)用例目標(biāo)確定了,相當(dāng)于界定了目標(biāo),知道需求要做什么,這個(gè)過程要反復(fù)和業(yè)務(wù)方確認(rèn)好,至到最終大家對(duì)目標(biāo)的理解是一致的,方向?qū)α?,具體怎么做就好辦了。具體怎么做用時(shí)序圖表示,畫時(shí)序圖需要注意的一點(diǎn)是頂層的對(duì)象層次要一致,不能有的對(duì)象表示具體的實(shí)體對(duì)象,有的表示系統(tǒng)對(duì)象,即對(duì)象的層級(jí)是一致的,要么大家都是系統(tǒng),比如導(dǎo)購(gòu)系統(tǒng)調(diào)用交易系統(tǒng),交易系統(tǒng)調(diào)用支付系統(tǒng),要么大家都是對(duì)象,比如商品、訂單等。通過時(shí)序圖可以看到一個(gè)完整功能的執(zhí)行步驟,它就包含具體執(zhí)行的細(xì)節(jié),如正常流程、異常流程。

圖片

其實(shí)在上面有一個(gè)問題,在畫時(shí)序圖時(shí)要確定好對(duì)象,那么這個(gè)對(duì)象是怎么來(lái)的呢?它是由健壯性圖分析出來(lái)的,它里面有三個(gè)關(guān)鍵的對(duì)象:一個(gè)是邊界對(duì)象,這個(gè)比較好理解,比如UI界面就是邊界對(duì)象;另一個(gè)是控制對(duì)象,即是控制業(yè)務(wù)流程的對(duì)象,如下單服務(wù)就可以看作是控制對(duì)象;實(shí)體對(duì)象即是問題空間中的業(yè)務(wù)對(duì)象,比如訂單。畫健壯性圖是有規(guī)則的,一般是邊界對(duì)象調(diào)用控制對(duì)象,控制對(duì)象產(chǎn)生實(shí)體對(duì)象,比如用戶下單界面是邊界對(duì)象,下單服務(wù)是控制對(duì)象,訂單就是實(shí)體對(duì)象。

圖片

3.尋找對(duì)象之路

(1)對(duì)象從哪里來(lái)

在本文第一部分第三小節(jié)中已經(jīng)提到,問題空間到解空間是一一映射,我們討論解空間中的對(duì)象時(shí),其實(shí)它映射到問題空間中的對(duì)象,而問題空間中的對(duì)象主要來(lái)源于業(yè)務(wù)概念、業(yè)務(wù)規(guī)則、關(guān)鍵事件。大部分的對(duì)象是顯現(xiàn)的,我們通過理解業(yè)務(wù)能發(fā)現(xiàn),有的對(duì)象是隱性的,需要我們持續(xù)對(duì)業(yè)務(wù)有更深的理解才能發(fā)掘出來(lái)。好的對(duì)象模型是需要經(jīng)過多次迭代打磨出來(lái)的,并非一次就能設(shè)計(jì)得十全十美。

(2)發(fā)現(xiàn)對(duì)象的方法

在本節(jié)中主要講述完整對(duì)象發(fā)現(xiàn)的方法,主要方法分成四個(gè)步驟:

1. 通過健壯性圖找到關(guān)鍵的實(shí)體對(duì)象;

2. 通過結(jié)構(gòu)分析方法找出更多的實(shí)體對(duì)象;

3. 將對(duì)象組成有機(jī)的對(duì)象模型;

4. 最后通過用例走查對(duì)象模型是否完備。

圖片

這里以一個(gè)案例來(lái)說(shuō)明發(fā)現(xiàn)對(duì)象的過程,案例是用戶在下單時(shí),在訂單上展示稅的金額。首先畫出健壯性圖,這里的邊界對(duì)象是下單界面,控制對(duì)象有兩個(gè),一個(gè)是下單服務(wù),另一個(gè)是計(jì)稅服務(wù),實(shí)體對(duì)象也有兩個(gè),一個(gè)是計(jì)稅單,一個(gè)是訂單。有了計(jì)稅單和訂單這兩個(gè)實(shí)體對(duì)象后,接下來(lái)通過結(jié)構(gòu)分析方法,分析出更多的對(duì)象。

圖片

對(duì)象都是有結(jié)構(gòu)的,只要我們掌握了對(duì)象的結(jié)構(gòu),基本上就能掌握對(duì)象的概貌,因此我們從對(duì)象的結(jié)構(gòu)入手,去分析對(duì)象內(nèi)部的結(jié)構(gòu)、對(duì)象關(guān)聯(lián)的結(jié)構(gòu),實(shí)質(zhì)上是從兩個(gè)維度出發(fā):一是從自身的角度出發(fā),看自己內(nèi)部還包含了哪些對(duì)象,如主訂單包含了子訂單;另一個(gè)是從外部的角度出發(fā),看自己還與哪些對(duì)象相關(guān)聯(lián),如計(jì)稅單與訂單是有關(guān)聯(lián)的。這種找對(duì)象的方法我稱之為結(jié)構(gòu)分析方法,因?yàn)楸旧斫Y(jié)構(gòu)又是事物本質(zhì)的一種表達(dá)方式,比如化學(xué)分子結(jié)構(gòu)決定化學(xué)現(xiàn)象。

為了更好地表達(dá)出對(duì)象的結(jié)構(gòu),我的一個(gè)經(jīng)驗(yàn)是給對(duì)象下好定義,下定義可以從不同的維度,比如功能性維度、價(jià)值性維度、目的性維度、結(jié)構(gòu)性維度等,這里可以從結(jié)構(gòu)性的維度去給對(duì)象下定義。以計(jì)稅單為例,可以給它下一個(gè)定義:計(jì)稅單是將訂單金額信息轉(zhuǎn)成若干個(gè)標(biāo)的物計(jì)稅的單據(jù)模型,從這個(gè)定義中,我們可以看到計(jì)稅單是與訂單有關(guān)聯(lián)關(guān)系的,另一個(gè)是計(jì)稅單是包含了若干個(gè)標(biāo)的物,我們可以畫出計(jì)稅單的對(duì)象模型。

圖片

當(dāng)對(duì)象模型畫出來(lái)后,后續(xù)我們討論業(yè)務(wù)基本上圍繞這個(gè)對(duì)象模型去討論業(yè)務(wù)問題的,比如商品標(biāo)的物哪些金額要參與計(jì)稅、計(jì)稅金額的計(jì)算口徑是怎樣的,到這里,大家再體會(huì)下"問題空間到解空間一一直接映射"這句話,業(yè)務(wù)上的訴求也無(wú)非是哪些訂單費(fèi)用項(xiàng)要計(jì)稅,計(jì)稅的邏輯是怎樣的,有可能在這個(gè)場(chǎng)景下要扣減金本位優(yōu)惠,在另外一種場(chǎng)景下金本位優(yōu)惠不需要扣減,基于對(duì)象模型與產(chǎn)品、測(cè)試同學(xué)討論問題,大家都是處于同一個(gè)維度的視角看問題,溝通理解成本會(huì)少很多。對(duì)象模型是一種可視化的表達(dá),我們大部分的溝通問題是缺乏顯性表達(dá)造成的,這句話可以這樣理解,也可以那樣理解,導(dǎo)致大家理解有偏差,現(xiàn)在用模型的形式溝通問題,很多偏差、歧義就消除了。

(3)組織對(duì)象結(jié)構(gòu)

當(dāng)我們分析出一堆的對(duì)象后,還需要經(jīng)過一定的組織,正如前面提到,人對(duì)事物理解是有局限的,不能一下子接受太多的事物,因此可以將它們分成一個(gè)個(gè)小的域,比如商品域、訂單域、稅務(wù)域等,這樣當(dāng)聚集一個(gè)問題時(shí),可以只看某個(gè)子域里的對(duì)象模型即可。

圖片

4.如何分配職責(zé)

(1)職責(zé)是怎么來(lái)的

面向?qū)ο笞铍y的點(diǎn)有兩個(gè):一個(gè)是找出對(duì)象;另一個(gè)是分配職責(zé)。UML 把職責(zé)定義為"類元的契約或義務(wù)",因此職責(zé)的劃分從本質(zhì)來(lái)講還是類元本身決定的,比如訂單,它要提供訂單渲染、訂單創(chuàng)建、訂單修改、訂單查詢的義務(wù)。職責(zé)分為兩類:一類是認(rèn)知職責(zé);另一類是行為職責(zé)。

認(rèn)知職責(zé)包含:

  • 對(duì)私有數(shù)據(jù)封裝的認(rèn)知。
  • 對(duì)相關(guān)對(duì)象的認(rèn)知。
  • 對(duì)其能夠?qū)С龌蛴?jì)算的事物的認(rèn)識(shí)。

行為職責(zé)包含:

  • 自己執(zhí)行的行為,包括創(chuàng)建對(duì)象或計(jì)算。
  • 初始化其它對(duì)象的動(dòng)作。
  • 控制或協(xié)調(diào)其它對(duì)象的活動(dòng)。

(2)分配職責(zé)的邏輯

上一小節(jié)中提到的職責(zé)有兩類,認(rèn)知職責(zé)是對(duì)象自身的認(rèn)知范圍,即它只能基于自身屬性完成相應(yīng)的職責(zé),舉一個(gè)例子,假如一主多子的訂單,要計(jì)算總的訂單金額,怎么分配職責(zé)呢?首先商品只能查到自身價(jià)格的信息,它的認(rèn)識(shí)是基于商品 price 屬性,一個(gè)子訂單可以有多個(gè)商品,那么它也只能計(jì)算出子訂單的金額信息,它的認(rèn)知是基于 item 和 quantity兩個(gè)屬性,主訂單包含所有子訂單的信息,那么就可以計(jì)算出總的訂單金額。

圖片

從上面的例子中我們可以看出,認(rèn)知職責(zé)是基于對(duì)象屬性的,正所謂"不在其位、不謀其政",認(rèn)知職責(zé)一定不會(huì)超過它的認(rèn)識(shí)范圍的。行為職責(zé)是偏領(lǐng)域服務(wù)的,有的時(shí)候一個(gè)職責(zé)不屬于某一個(gè)對(duì)象,比如轉(zhuǎn)賬,就是一個(gè)行為,讓其它的職責(zé)承擔(dān)并不合適,這類行為職責(zé)往往是一個(gè)顯著的業(yè)務(wù)活動(dòng),比如訂單渲染、訂單創(chuàng)建就是行為職責(zé)而非認(rèn)知職責(zé)。分配職責(zé)一定要遵循"信息專家"模式,它的含義是將職責(zé)分配給具有完成該職責(zé)所需要信息的那個(gè)類,也即上面提到的認(rèn)識(shí)產(chǎn)生職責(zé)。

(3)驗(yàn)證職責(zé)分配的合理性

我們期望分配的職責(zé)滿足"高內(nèi)聚、低耦合",怎么檢驗(yàn)?zāi)兀课覀冊(cè)倩剡^頭來(lái)思考職責(zé)的定義:類元的契約或義務(wù),換句話講,職責(zé)是滿足其它對(duì)象來(lái)調(diào)用的,這個(gè)就與我們畫時(shí)序圖的目的是一致的,每次發(fā)生一次調(diào)用,即意味著其它的對(duì)象要提供一個(gè)職責(zé)出來(lái),因此我們可以在時(shí)序圖中看對(duì)象間的調(diào)用頻次,如果一個(gè)對(duì)象被調(diào)用得非常頻繁,有可能這個(gè)對(duì)象承擔(dān)了太多的職責(zé),是不是可以對(duì)其拆分,把職責(zé)分配一部分出去。因此,對(duì)象職責(zé)分配并不是一蹴而就的,需要不斷審視、檢驗(yàn)。分配職責(zé)是要遵循一定的原則,如創(chuàng)建者模式、信息專家模式、純虛構(gòu)模式等,這些原則會(huì)在下一篇中單獨(dú)去講。

5.案例

(1)案例背景

這里舉一個(gè)例子,說(shuō)明面向過程和面向?qū)ο笤诜治?、編寫代碼的差異性,計(jì)稅需要判斷是否滿足計(jì)稅規(guī)則,比如虛擬商品不計(jì)稅(手機(jī)充值之類)、有些免稅地址不計(jì)稅、小 B 買家也不計(jì)稅等,因此需要提供一個(gè)計(jì)稅過濾判斷邏輯。

(2)常規(guī)面向過程實(shí)現(xiàn)

面向過程的思路很簡(jiǎn)單,提供一個(gè)過濾方法依次處理下面邏輯:過濾虛擬商品計(jì)稅請(qǐng)求、過濾免稅地址計(jì)稅請(qǐng)求、過濾小 B 買家計(jì)稅請(qǐng)求。

圖片

public void filter(List<TaxCalculateRequest> request){

// 過濾虛擬商品計(jì)稅請(qǐng)求
filterVirtualItem(request);

// 過濾免稅地址計(jì)稅請(qǐng)求(即外島)
filterOuterIsland(request);

// 過濾小B買家計(jì)稅請(qǐng)求
filterPurchaseType(reqeust);

}

(3)面向?qū)ο髮?shí)現(xiàn)

面向過程是從過程視角或者是功能視角分析問題,而面向?qū)ο笫菑膶?duì)象的視角分析問題,過濾計(jì)稅請(qǐng)求是計(jì)稅過濾器判斷計(jì)稅請(qǐng)求是否滿足計(jì)稅規(guī)則,這里就包含了兩個(gè)對(duì)象:計(jì)稅過濾器和計(jì)稅規(guī)則,判斷是否滿足計(jì)稅要求這個(gè)職責(zé)應(yīng)該是在具體的計(jì)稅規(guī)則處理器中,比如是否是小 B 買家等,因此我們可以畫出對(duì)象模型。

圖片

關(guān)鍵代碼如下:

public abstract class AbstractRuleHandler {

/**
* 抽象的業(yè)務(wù)規(guī)則處理
*
* @param request
*/
public abstract void handler(TaxCalculateRequest request);

/**
* 構(gòu)造函數(shù)里完成注冊(cè)
*/
public AbstractRuleHandler() {
TaxCaluclateFilter.register(this);
}
}

6.總結(jié)

在文章中提到,面向?qū)ο蟮牡讓舆壿嬍腔诂F(xiàn)實(shí)事物做的抽象映射,重要的不是要面向?qū)ο缶唧w技術(shù)的使用上,而是分析問題的思維上,這是最難的,它最大的好處是問題空間到解空間是一一直接映射的,請(qǐng)注意是一一直接映射,它意味著我們?cè)谟懻摲桨傅臅r(shí)候,完全可以映射到問題空間,如果是間接映射,也就意味著設(shè)計(jì)的方案后面會(huì)面臨重新設(shè)計(jì)的可能性,因?yàn)樗腔趫?chǎng)景或功能做出的歸納設(shè)計(jì),而且是表層的設(shè)計(jì)。真正掌握了面向?qū)ο蠓治龊驮O(shè)計(jì)的方法,也體會(huì)到其中的益處,對(duì)理解業(yè)務(wù)、方案設(shè)計(jì)、編碼開發(fā)都有好處。

責(zé)任編輯:武曉燕 來(lái)源: 阿里巴巴中間件
相關(guān)推薦

2010-06-17 17:57:10

UML面向?qū)ο蠓治雠c設(shè)

2009-06-26 13:38:46

UML面向?qū)ο?/a>

2010-06-18 11:28:14

2010-07-08 13:35:39

UML面向?qū)ο?/a>

2011-07-12 17:53:21

PHP

2010-06-17 09:22:48

UML面向?qū)ο蠓治雠c建

2010-07-08 10:47:42

UML面向?qū)ο?/a>

2010-07-09 09:51:26

UML面向?qū)ο?/a>

2010-07-06 17:21:08

UML面向?qū)ο?/a>

2010-06-13 17:56:49

UML面向?qū)ο?/a>

2013-03-14 11:17:46

2023-03-10 07:43:50

UML圖OOA面向?qū)ο?/a>

2021-04-15 18:44:15

2010-06-17 11:27:11

UML構(gòu)件

2010-06-18 10:34:05

UML面向?qū)ο?/a>

2013-04-17 10:46:54

面向?qū)ο?/a>

2010-06-18 11:16:52

UML面向?qū)ο?/a>

2020-10-10 11:03:24

面向?qū)ο?/a>編程語(yǔ)言開發(fā)

2012-06-07 10:11:01

面向?qū)ο?/a>設(shè)計(jì)原則Java

2024-12-29 19:36:04

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)