1 面向物件是符合人認識事物的基本方法
01 人是怎么認識事物的
在面向物件出現之前，已有面向程序的分析方法，為什么面向物件被提出了呢？究其本質原因，人們發現面向程序并不是按照人正常認識事物的方式去分析軟體，那么人究竟是怎么認識事物的呢，Yourdon 在《面向物件的分析》一書中提到，人類認識事物是遵循分類學的原理，分類學主要包含三點：區分物件及其屬性；區分整體物件及其組成部分；不同物件類的形成及區分，
我們現在可以回想下我們認識事物的程序，是不是和分類學所提到的 3 個要點很相似，看到一個事物，大概會感知到它的組成結構是怎樣的，形狀是怎樣的，屬于什么分類，所以，人認識事物是以物件的視角切入的，然后賦于物件具體的概念，比如蘋果、梨子、汽車等等概念名稱，
02 分類與分層的兩種思維
我們面對的現實世界是非常復雜的，應對復雜事物的有一個重要的方法即是抽象，抽象在實際應用程序中，又體現在兩種方法上：分層和分類，分類即是將有差異的事物歸類到不同的分組中，正如我們常聽到的"物以類聚、人以群分"的道理一樣，產生分類的原因有兩點：一點是事物間的關聯緊密程度，不需要將所有的事物都耦合在一起；另一點是人掌握事物是有局限的，只能掌握少量的要點，比如 5~7 個要點，超過了容易忘記，
分層是通過不同的視角看事物，每一層的關注點是不一樣的，這種關注點不同是由自己的視角造成的，比如我們理解計算機，并不需要深入到二進制電信號去理解計算機，層次特性在軟體設計中我們經常遇到，比如計算機體系結構、TCP 七層協議等，層次特性有一個特點：越往上越具體、越往下越抽象，越往上的內容越不穩定，也即是容易變化，
03 問題域到解空間的映射
我們把需要解決的問題稱之為問題域，或者問題空間，把解決方案稱之為解空間，正向上一小節中提到的事物有層次特性，不同的人理解的事物是站在各自理解的視角，這樣大家的理解、溝通并不一致的，如果我們看到的問題空間是表層的，那么基于淺層次理解設計出來的方案就會不穩定，可能下次有一個小變化導致方案需要重新設計，
我們可以把一個軟體劃分成三層：場景、功能和物體，場景層是經常會變的，比如發放優惠券場景就非常多，比如有天降紅包領取優惠、分享有禮領取優惠券、新人注冊領取優惠券等，這種場景的更迭隨著業務的調整變化得非常快，因此場景層是不穩定的，功能支撐某一些的場景集合，對比場景，功能相對而言穩定些，就像前面提到的發放優惠券場景，本質就是給用戶發放優惠券，只需要提供發放優惠券的功能即可，至于哪些場景來呼叫它并不關注，但功能還是基于場景的集合抽象出來的，如果場景場景型別變化了，功能也就隨之變化，比如擔保交易和預售交易就不一樣，物體是穩定的，以擔保交易和預售交易為例，它的訂單模型大致是一樣的，只是新增加了一些資訊而已，
因此，我們希望從問題空間到解空間，大家看到的、理解的是一致的，而且看到的是問題的本質而非表象，往往場景、功能是不穩定的，而面向程序又是以功能驅動的，所以在易變化的場景下，它面臨的問題就比較多，比較穩定的是問題空間中的物體物件，所以面向物件分析是現實的需要，面向程序和面向物件是兩個不同的視角的分析方法：面向程序是一種歸納的分析方法，由外到內的程序；面向物件是一種演繹的分析方法，由內到外的程序，
04 三個一致性
軟體開發會經歷需要分析、概要設計、詳細設計、編碼、測驗、上線主要階段，我們不希望每塊是割裂的，比如分析做完之后，做設計階段又要重新去做分析的作業，那么這里面就涉及到一致性的問題，即需求到分析的一致性、分析到設計的一致性、設計到編碼的一致性，這樣做的好處可以保證無資訊失真，因此我們急需求一種分析設計方法能做到這一點，面向物件分析與設計就能做到，因此全流程是以物件作為分析與設計的目標，在最終編碼中也都是物件，
05 面向物件的底層邏輯
提到面向物件，有部分人會提到封裝、繼承、多型等特性，然后這些并不是面向物件的本質特性，比如封裝，面向程序中也有封裝，多型面向程序也有體現，這些特性算不上面向物件特有的特性，面向物件的底層邏輯是基于現實事物做的抽象映射：現實事物對應軟體中的物件，我們討論解空間能對應到問題空間中的物件，兩者是一一直接映射的，其它的分析方法是問題空間到解空間的間接映射，
2 面向物件分析與設計的全景圖
01 我們面臨的問題是什么
從頂層看，我們要完成需求到編碼的作業，然而從需求到編碼又會經過多個階段，如需求分析、方案設計等，從大的層面講，我們主要遇到三個問題：
1. 做什么的問題
看似這是一個簡單的問題，但在復雜的業務場景下，對做什么的理解太重要了，因為不同的人對需求的理解是不同的，比如最近做了一個專案，有一個業務判斷規則是只針對跨境訂單計稅，最開始開發同學的理解是判斷賣家型別是否是跨境賣家，然而到了測驗階段，發現大家對這個業務規則判斷理解是不一致的，跨境訂單跟賣家型別是沒有關系的，真正的跨境訂單計稅場景是 shipTo（識訓地址）和 shipFrom（發貨地址）國家地址是不一樣的，在大項專案中，涉及到多個團隊之間的協同，這樣的問題例外突出，而且從業務訴求到產品需求，再到技術方案，這其中是經過了 2 次變換，每次變換是不同的角色在里面，大家的認識也會不一樣，
2. 怎么做的問題
落實到事情具體要怎么做時，往往大家并不會出大的問題，怎么做偏具體執行階段，程式員往往在邏輯嚴密性上沒多大的問題，往往出問題是在第一個問題上，相當于方向弄錯了，所做的作業也是無用的，
3. 方法指導的問題
我們往往希望不勞而獲得到一種萬能的方法，能夠應對所有的問題，同時又看不起低級的方法，比如大部分人對用例分析方法嗤之以鼻，想要能體現技術水平高大上的方法，其實自上世紀 70、80 年代，軟體的分析設計方法并沒有太大的變化，而且在我們大學期間都學過，只是大家并不認為它是一種高大上的方法而已，
02 分析到設計的程序
在本節中，我們推導軟體分析到設計的程序，由粗到細，最終落實到我們接觸到的 UML 知識上，從需求提出到編碼實作，這中間有兩個關鍵問題：一是界定目標，即是定義清楚要做什么的問題，相當于是我們做事的方向、目標；二是具體如何做的問題，即通過怎樣具體的方案支撐需求目標實作，因此，我們需要一種方法能夠幫助我們界定目標和表示具體方案，而且是大家互認的一種通用的方法，
通過用例圖可以幫我們界定目標，用例中有三個關鍵要素：用戶、場景和目標，比如交易下單是一個用例，它的用戶是買家，場景包含下單成功和下單失敗兩個場景，用例的目標是買家可以購買心儀的商品，當用例目標確定了，相當于界定了目標，知道需求要做什么，這個程序要反復和業務方確認好，至到最終大家對目標的理解是一致的，方向對了，具體怎么做就好辦了，
具體怎么做用時序圖表示，畫時序圖需要注意的一點是頂層的物件層次要一致，不能有的物件表示具體的物體物件，有的表示系統物件，即物件的層級是一致的，要么大家都是系統，比如導購系統呼叫交易系統，交易系統呼叫支付系統，要么大家都是物件，比如商品、訂單等，通過時序圖可以看到一個完整功能的執行步驟，它就包含具體執行的細節，如正常流程、例外流程，
其實在上面有一個問題，在畫時序圖時要確定好物件，那么這個物件是怎么來的呢？它是由健壯性圖分析出來的，它里面有三個關鍵的物件：一個是邊界物件，這個比較好理解，比如UI界面就是邊界物件；另一個是控制物件，即是控制業務流程的物件，如下單服務就可以看作是控制物件；物體物件即是問題空間中的業務物件，比如訂單，畫健壯性圖是有規則的，一般是邊界物件呼叫控制物件，控制物件產生物體物件，比如用戶下單界面是邊界物件，下單服務是控制物件，訂單就是物體物件，
3 尋找物件之路
01 物件從哪里來
在本文第一部分第三小節中已經提到，問題空間到解空間是一一映射，我們討論解空間中的物件時，其實它映射到問題空間中的物件，而問題空間中的物件主要來源于業務概念、業務規則、關鍵事件，大部分的物件是顯現的，我們通過理解業務能發現，有的物件是隱性的，需要我們持續對業務有更深的理解才能發掘出來，好的物件模型是需要經過多次迭代打磨出來的，并非一次就能設計得十全十美，
02 發現物件的方法
在本文第二部分第二小節中已經提到尋找物件的方法，不過那還只是關鍵顯現的物件，在本節中主要講述完整物件發現的方法，主要方法分成四個步驟：
1. 通過健壯性圖找到關鍵的物體物件；
2. 通過結構分析方法找出更多的物體物件；
3. 將物件組成有機的物件模型；
4. 最后通過用例走查物件模型是否完備，
這里以一個案例來說明發現物件的程序，案例是用戶在下單時，在訂單上展示稅的金額，首先畫出健壯性圖，這里的邊界物件是下單界面，控制物件有兩個，一個是下單服務，另一個是計稅服務，物體物件也有兩個，一個是計稅單，一個是訂單，有了計稅單和訂單這兩個物體物件后，接下來通過結構分析方法，分析出更多的物件，
物件都是有結構的，只要我們掌握了物件的結構，基本上就能掌握物件的概貌，因此我們從物件的結構入手，去分析物件內部的結構、物件關聯的結構，實質上是從兩個維度出發：一是從自身的角度出發，看自己內部還包含了哪些物件，如主訂單包含了子訂單；另一個是從外部的角度出發，看自己還與哪些物件相關聯，如計稅單與訂單是有關聯的，這種找物件的方法我稱之為結構分析方法，因為本身結構又是事物本質的一種表達方式，比如化學分子結構決定化學現象，
為了更好地表達出物件的結構，我的一個經驗是給物件下好定義，下定義可以從不同的維度，比如功能性維度、價值性維度、目的性維度、結構性維度等，這里可以從結構性的維度去給物件下定義，以計稅單為例，可以給它下一個定義：計稅單是將訂單金額資訊轉成若干個標的物計稅的單據模型，從這個定義中，我們可以看到計稅單是與訂單有關聯關系的，另一個是計稅單是包含了若干個標的物，我們可以畫出計稅單的物件模型，
當物件模型畫出來后，后續我們討論業務基本上圍繞這個物件模型去討論業務問題的，比如商品標的物哪些金額要參與計稅、計稅金額的計算口徑是怎樣的，到這里，大家再體會下"問題空間到解空間一一直接映射"這句話，業務上的訴求也無非是哪些訂單費用項要計稅，計稅的邏輯是怎樣的，有可能在這個場景下要扣減金本位優惠，在另外一種場景下金本位優惠不需要扣減，基于物件模型與產品、測驗同學討論問題，大家都是處于同一個維度的視角看問題，溝通理解成本會少很多，
物件模型是一種可視化的表達，我們大部分的溝通問題是缺乏顯性表達造成的，這句話可以這樣理解，也可以那樣理解，導致大家理解有偏差，現在用模型的形式溝通問題，很多偏差、歧義就消除了，
03 組織物件結構
當我們分析出一堆的物件后，還需要經過一定的組織，正如前面提到，人對事物理解是有局限的，不能一下子接受太多的事物，因此可以將它們分成一個個小的域，比如商品域、訂單域、稅務域等，這樣當聚集一個問題時，可以只看某個子域里的物件模型即可，
4 如何分配職責
01 職責是怎么來的
面向物件最難的點有兩個：一個是找出物件；另一個是分配職責，UML 把職責定義為"類元的契約或義務"，因此職責的劃分從本質來講還是類元本身決定的，比如訂單，它要提供訂單渲染、訂單創建、訂單修改、訂單查詢的義務，
職責分為兩類：一類是認知職責；另一類是行為職責，
- 認知職責包含：
- 對私有資料封裝的認知，
- 對相關物件的認知，
- 對其能夠匯出或計算的事物的認識，
- 行為職責包含：
- 自己執行的行為，包括創建物件或計算，
- 初始化其它物件的動作，
- 控制或協調其它物件的活動，
02 分配職責的邏輯
上一小節中提到的職責有兩類，認知職責是物件自身的認知范圍，即它只能基于自身屬性完成相應的職責，舉一個例子，假如一主多子的訂單，要計算總的訂單金額，怎么分配職責呢？首先商品只能查到自身價格的資訊，它的認識是基于商品 price 屬性，一個子訂單可以有多個商品，那么它也只能計算出子訂單的金額資訊，它的認知是基于 item 和 quantity兩個屬性，主訂單包含所有子訂單的資訊，那么就可以計算出總的訂單金額，
從上面的例子中我們可以看出，認知職責是基于物件屬性的，正所謂"不在其位、不謀其政"，認知職責一定不會超過它的認識范圍的，
行為職責是偏領域服務的，有的時候一個職責不屬于某一個物件，比如轉賬，就是一個行為，讓其它的職責承擔并不合適，這類行為職責往往是一個顯著的業務活動，比如訂單渲染、訂單創建就是行為職責而非認知職責，
分配職責一定要遵循"資訊專家"模式，它的含義是將職責分配給具有完成該職責所需要資訊的那個類，也即上面提到的認識產生職責，
03 驗證職責分配的合理性
我們期望分配的職責滿足"高內聚、低耦合"，怎么檢驗呢？我們再回過頭來思考職責的定義：類元的契約或義務，換句話講，職責是滿足其它物件來呼叫的，這個就與我們畫時序圖的目的是一致的，每次發生一次呼叫，即意味著其它的物件要提供一個職責出來，因此我們可以在時序圖中看物件間的呼叫頻次，如果一個物件被呼叫得非常頻繁，有可能這個物件承擔了太多的職責，是不是可以對其拆分，把職責分配一部分出去，因此，物件職責分配并不是一蹴而就的，需要不斷審視、檢驗，
分配職責是要遵循一定的原則，如創建者模式、資訊專家模式、純虛構模式等，這些原則會在下一篇中單獨去講，
5 案例
01 案例背景
這里舉一個例子，說明面向程序和面向物件在分析、撰寫代碼的差異性，計稅需要判斷是否滿足計稅規則，比如虛擬商品不計稅（手機充值之類）、有些免稅地址不計稅、小 B 買家也不計稅等，因此需要提供一個計稅過濾判斷邏輯，
02 常規面向程序實作
面向程序的思路很簡單，提供一個過濾方法依次處理下面邏輯：過濾虛擬商品計稅請求、過濾免稅地址計稅請求、過濾小 B 買家計稅請求，
public void filter(List<TaxCalculateRequest> request){ // 過濾虛擬商品計稅請求 filterVirtualItem(request); // 過濾免稅地址計稅請求(即外島) filterOuterIsland(request); // 過濾小B買家計稅請求 filterPurchaseType(reqeust); }
03 面向物件實作
面向程序是從程序視角或者是功能視角分析問題，而面向物件是從物件的視角分析問題，過濾計稅請求是計稅過濾器判斷計稅請求是否滿足計稅規則，這里就包含了兩個物件：計稅過濾器和計稅規則，判斷是否滿足計稅要求這個職責應該是在具體的計稅規則處理器中，比如是否是小 B 買家等，因此我們可以畫出物件模型，
關鍵代碼如下：
public abstract class AbstractRuleHandler { /** * 抽象的業務規則處理 * * @param request */ public abstract void handler(TaxCalculateRequest request); /** * 建構式里完成注冊 */ public AbstractRuleHandler() { TaxCaluclateFilter.register(this); } }
06 總結
在文章中提到，面向物件的底層邏輯是基于現實事物做的抽象映射，重要的不是要面向物件具體技術的使用上，而是分析問題的思維上，這是最難的，它最大的好處是問題空間到解空間是一一直接映射的，請注意是一一直接映射，它意味著我們在討論方案的時候，完全可以映射到問題空間，如果是間接映射，也就意味著設計的方案后面會面臨重新設計的可能性，因為它是基于場景或功能做出的歸納設計，而且是表層的設計，真正掌握了面向物件分析和設計的方法，也體會到其中的益處，對理解業務、方案設計、編碼開發都有好處，
作 者 | 不拔
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/The-underlying-logic-of-object-oriented-analysis-and-design.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/502500.html
標籤：其他
上一篇：前途無量的MEMS傳感器技術
下一篇：對抗軟體復雜度的戰爭