描述 前面我們已經對領域內的名詞進行了抽取,並且已經確定了業務流程中參與的核心對象。 但是對象只是靜態的描述,系統中往往會有很多的業務操作,偏演算法的,之前我們說過 領域內的對象往往是比較穩定不怎麼變化的,但是,業務的流程以及業務操作這些是往往 千變萬化,防不勝防,那麼我們如何去及時發現這些系統內變化 ...
描述
前面我們已經對領域內的名詞進行了抽取,並且已經確定了業務流程中參與的核心對象。
但是對象只是靜態的描述,系統中往往會有很多的業務操作,偏演算法的,之前我們說過
領域內的對象往往是比較穩定不怎麼變化的,但是,業務的流程以及業務操作這些是往往
千變萬化,防不勝防,那麼我們如何去及時發現這些系統內變化點,並且如何使用面向對象
的方式去抽象,封裝它呢?,下麵就簡單介紹我們大神的一些個人經驗,也在此記錄一下。
目的
關註系統中的變化點或者說業務的流程中某個節點的多變的演算法,
提供系統的可維護性和擴展性。
步驟
先說步驟,步驟後面跟著一些場景進行解析,試著理解步驟。
找出變化點
這是第一步也是關鍵的一步,如果你連這個系統中的變化點都找不到,下麵的工作也就
無從談起,所以我們在這個階段就要去細心觀察找出那些業務的變化點,
一般的我們可以從產品的原型中,產品的溝通中可以找到:
關註那些從描述上看起來不一樣,卻又是在做同一件事的場景。
去限定詞
找出這個場景或者演算法每次而且每條都出現的領功能變數名稱詞和沒有限定詞的動詞,其他的全部可以忽略。
簡單的說就是把場景中的不斷出現的領功能變數名稱詞都刪除掉,留下動詞。
抽取動詞
根據上一步的操作,我們對場景中的動詞需要進行抽象一下,使用一個動作統一概括。
抽取介面
將這個動作作為一個介面存在,確定這個介面中的方法用來做什麼以及它的輸入,輸出。
說白了就是定義一個函數的名稱,參數,返回值。
一般來說輸入的要是抽象中每次都出現的名詞,輸出是這個抽象需要的內容。
聚合介面
並不是說一個介面只能有一個方法,實際上,有些方法是成雙成對,甚至是成幾對出現的。
如果發現兩個介面合在一起剛好可以表達一個完整的事情就可以將這兩個介面合併成一個介面。
實例解析
場景一描述
在優學習(教育網站http://www.uxuexi.com)這個網站上為用戶提供了很多的服務,比如:
可以購買單個視頻進行觀看,
也可以將視頻打包購買進行觀看,
可以購買閱卷服務讓老師給用戶的試卷進行評閱
也可以購買約課的服務讓老師上門或者線上進行輔導
這個業務場景是一個變化點,因為平臺中可以添加任何具有服務性質的東西讓用戶購買。
這裡可以抽取一個商品的概念,其實用戶購買的就是商品,不管它是視頻,評捲服務,輔導服務都是商品。
所有我們按照步驟就這麼做。
去限定詞:
購買xx商品得到xx商品的服務
抽取動詞:
購買,服務
抽取介面:
IBuy
介面中的方法:
方法名稱:goToBuy
參數:商品
執行:完成購買
返回:空
IService
方法名稱:supply
參數:商品
執行:商品提供的服務
返回:空
類圖如下:
合併介面
我們會發現但凡我們需要增加一個商品都需要實現這兩個介面,這個時候就說明我們可以
將這兩個介面抽取成一個介面,這就是聚合介面。
類圖如下:
場景二描述
在電商網站中支付是一個重要的環節,往往會有以下需求:
用戶可以使用支付寶完成訂單支付
用戶可以使用微信完成訂單支付
用戶可以使用銀行卡的方式完成訂單支付
找出變化點
這個場景的變化點就是用戶可以使用多種方式完成支付。
去限定詞
使用xx方式完成訂單支付
抽取動詞
這個場景強調的動作是支付,所以動詞應該就是:去支付
但是,我們知道每一個支付都需要我們提供給一個支付完成的回調供支付平臺通知支付結果,
所以這裡要添加一個動作:完成支付
抽取介面
介面中的方法:
方法名稱:goToPay
參數:訂單
執行:完成購買
返回:空
方法名稱:finish
參數:訂單
執行:完成購買
返回:空
類圖:
場景三描述
在做優學習網站時,出現了這麼一個場景,每一個視頻的播放需要鑒權,
也就是說用戶點擊某個視頻的時候由後臺決定他是否有觀看的許可權。
情況如下:
免費的視頻可以觀看
課程包中的第一個視頻可以觀看
購買的視頻中包含這個視頻的可以觀看
請求來源的功能變數名稱如果在白名單中可以觀看所有視頻
網站的合作商可以觀看所有視頻
等等。。。。
找出變化點
判斷視頻是否可以播放的條件在不斷增加,這就是一個變化點。
去限定詞
視頻是否可以觀看
抽取動作
判斷視頻是否可以觀看其實就是鑒權,所以動作就是:是否可以播放
抽取介面
介面名稱:IVideoAuthentication
介面中的方法:
方法名稱:goToPay
參數:視頻id
執行:判斷是否具有播放許可權
返回:布爾
類圖:
設計心得
介面有了,但是我們怎麼更好組織它呢?
一般的場景我們可以採用以下方案:
平行演算法
如果這些介面的具體實現在同一時刻只能出現一個具體演算法,這些演算法又可以平行替換,
我們就可以參考“策略模式"去設計。
串列演算法
如果這些介面的具體實現在同一時刻有可能需要組合一起去完成某個功能這就是串列,
我們可以使用”職責鏈模式“去設計。
考慮重用
如果這些演算法之間有一些公用的邏輯,業務,演算法我們可以考慮使用,模板模式,裝飾模式去解決重覆問題,
讓我們的設計更加合理有擴展性。