面向對象是一種對現(xiàn)實世界理解和抽象的方法，是計算機編程技術發(fā)展到一定階段后的產物。筆者從產品的角度入手，對面向對象中的一些基本名詞，比如類和對象，進行了發(fā)散式的思考，在此和大家分享。

面向對象（Object-Oriented ，OO）是目前從事軟件開發(fā)行業(yè)的人必備的基礎思維。之所以稱其為“思維”而非“知識”，是因為知識是有限的、有領域（domain）的，而思維是可以無限的、創(chuàng)造性的、跨領域的。

本文要談的正是基于其跨領域的特性，將一些OO中最簡單的基本名詞，從產品設計的角度做一些發(fā)散思考。

一、業(yè)務產品中的OO

本文只普及OO中的幾個最基本的通用術語，并且不再贅述它們的技術定義（有興趣的可以自行百度），用人話把這幾個術語背后的思維邏輯描述一下。

1. 類（Class）和對象（Instance）

在業(yè)務產品設計之前，第一步要做的就是把業(yè)務邏輯中那些可以認為是一個主體的“東西”抽象出來，這個主體可能是真實的（如醫(yī)生、醫(yī)生助理、醫(yī)院等），也可能是虛擬的（如醫(yī)療服務、訂單、預約等），我們稱這些抽象出來的主體為類。

怎么判斷哪些可以抽象成類呢？

1. 擁有自己的屬性或自己的行為。比如醫(yī)生有姓名、職稱、擅長等屬性，也有看病、開檢查單、上班等行為。
2. 還要看這些屬性和行為是否在自己的業(yè)務邏輯中產生作用。比如手機號雖然也有運營商、歸屬地等屬性，但是這些屬性與自己的業(yè)務沒有關系，那么它就沒必要抽象成類。

如果說類是我們對主體定義了一個模型，對象就是基于這個模型產生的具體實例。比如張妙手醫(yī)生、二級護理服務、小李剛成交的2800元的二級護理服務的訂單。

類是在業(yè)務邏輯和產品設計中使用的載體，對象則是業(yè)務運行中實實在在產生的一條條數(shù)據。

在業(yè)務的討論中經常發(fā)生名詞混淆，口徑不統(tǒng)一等問題，多方對同一個名詞理解有偏差，甚至根本不是一個東西，導致很多不必要的爭論和誤解，這些現(xiàn)象產生的原因就是沒有準確的抽象定義清楚類。

2. 抽象（Abstraction）

剛剛提到過這個術語，好的“抽象”就是一個建模的過程。把一個富有多種多樣屬性和行為的主體，抽出對業(yè)務有用的部分，不多不少，不偏不倚，還要富有兼容性和擴展性。

抽象是OO的基礎，這個事跟說相聲差不多。門檻特別低，按剛才說的邏輯很容易就掌握了。

但是要做好也特別難，也是最考驗功力的地方，因為后續(xù)所有的設計都基于抽象出來的類，尤其是在業(yè)務不斷優(yōu)化和拓展中，牽一發(fā)動全身，經常會出現(xiàn)一失足成千古恨的情況。

3. 繼承（Inheritance）

繼承顧名思義，主要用來定義類的父子關系。比如我們的業(yè)務產品提供醫(yī)生就診服務、麻醉服務，護理服務。

于是我們可以抽象出3個類來對應他們在業(yè)務邏輯中的主體位置。但這只是起步，OO的抽象并不僅限于此。

我們可以發(fā)現(xiàn)，這3個主體的屬性和行為中有很多是重復的。比如都有價格、提供者、有效期等屬性，都可以提供預約等。

簡單來說，都有醫(yī)療服務的共性。于是我們可以抽象出一個父類——醫(yī)療服務類。3個主體各自的類都作為子類繼承于服務類，以此自動獲得父類的特征。

這種父子關系的好處是：

1. 將主體的共性抽象出來后，一旦對業(yè)務產品進行升級或者變動時，能夠快速梳理相關的其他業(yè)務邏輯。比如當我們需要為就診服務增加會員價格或評價機制時，馬上就會想到對其他的服務也可以適用。此時，只需要在醫(yī)療服務父類增加相應的邏輯就可以了，減少了很多重復工作量。
2. 同時還能保證子類的特殊性，比如護理服務可能是全天候的，會診服務會提供診斷結果，麻醉服務可能是一次性的。

4. 多態(tài)（Polymorphism）

多態(tài)是指不同子類的同一個行為是有具體差別的，是多種狀態(tài)的。比如醫(yī)護人員能夠提供服務的行為，雖然都叫提供服務，但實際上提供的服務內容和方式都是不一樣的。

于是我們在業(yè)務邏輯中可以統(tǒng)稱為提供醫(yī)療服務，實際運營時要針對具體的服務詳細定制流程和規(guī)則，并提供相應的支持。這樣可以在業(yè)務邏輯設計的過程中，面對總體設計時不會被零碎的細節(jié)干擾。

5. 封裝（Encapsulation）

封裝很好理解，比如業(yè)務中的醫(yī)療服務。服務內部的成本、運營、人員配合等對用戶來講是個黑盒子，我們將其封裝起來，只需要提供對應的消息傳遞機制（message sending）就可以了。

消息傳遞機制由接口（interface）和規(guī)則（regulation）構成。

1. 接口：就是消息傳遞的通道，比如服務的購買入口、咨詢入口、預約入口、投訴入口；
2. 規(guī)則：就是明確用戶通過接口需要提供什么、能夠獲得什么。提供個人信息并在線支付價款就能獲得服務；提供時間和服務憑證就能獲得醫(yī)生的預約；提供醫(yī)生助理姓名和證據就能投訴并得到反饋。

當用戶提出需求后，他并不需要知道我們是怎么滿足他的，只需要給用戶結果就可以了。將復雜的邏輯留給自己，將簡單的動作留給用戶，這就是封裝最大的意義。

6. 關聯(lián)（Association）

關聯(lián)形容的是類和類之間的聯(lián)系，將不同類關聯(lián)起來就能夠組合出復雜的業(yè)務，而且每個類就向零件一樣，可以更換，可以復用，為創(chuàng)造提供了無限的可能性。比如：

• 多點執(zhí)業(yè)可以通過醫(yī)生和醫(yī)院的關聯(lián)實現(xiàn)；
• 用戶購買的診療服務通過用戶、醫(yī)生、服務類別的關聯(lián)實現(xiàn)；
• 就診預約可以通過用戶、訂單、服務助理、醫(yī)生出診時間地點等關聯(lián)實現(xiàn)。

關聯(lián)的多種形式

當我們在定義業(yè)務產品的時候提出一個需求：每個醫(yī)生需要配備醫(yī)生助理，幫助醫(yī)生進行患者管理工作。那么醫(yī)生和醫(yī)生助理之間就形成了關聯(lián)。

最基本的4種關聯(lián)：

• “一對一”：一個醫(yī)生配備一個專屬助理，只服務這個醫(yī)生；
• “一對多”：一個醫(yī)生配備多個專屬助理，都只服務這個醫(yī)生；
• “多對一”：一個醫(yī)生配備一個助理，一個助理服務多個醫(yī)生；
• “多對多”：一個醫(yī)生配備多個助理（服務助理，跟診助理等），一個助理可以服務多個醫(yī)生。

不同的關聯(lián)方式擁有不同的成本，不同的效果，不同的管理方式，不同的業(yè)務流程。同樣一個最初的需求，定義什么樣的解決方案，得到的結果卻大不相同。

小案例：

業(yè)務中目前已經提供目前麻醉服務、就診服務等醫(yī)療服務。根據當時的業(yè)務產品定義，每個服務為一個就診人提供服務。隨著業(yè)務的發(fā)展產生了如下兩個需求：

1. 產科服務結束后，一般會向媽媽提供后續(xù)的兒科服務，有時會碰到雙胞胎，于是兒科服務的就診人就需要關聯(lián)多個；
2. 隨著業(yè)務發(fā)展，公司希望開發(fā)家庭服務包，通過打包多個專業(yè)科室的醫(yī)生，為一個家庭的所有成員提供服務。

基于OO的OOA（Object-Oriented Analysis）：

1. 兒科服務與產科服務都屬于個體對個體的服務,都是用了就診服務類作為模型。雙胞胎概率很小，從設計角度分析，為了一些特例去改變類的屬性結構和關聯(lián)關系是需要慎重的。再從業(yè)務角度分析，產生這種現(xiàn)狀的原因是當時沒有清晰的定義兒科服務是否可以針對群體，如果醫(yī)生的工作量會隨就診人的增加而增加，而服務收益不變，這是不合理的。所以，多個孩子（即使是雙胞胎）應該購買多個兒科服務，就像上學也要交兩份學費一樣。而不是直接更改服務和就診人的關聯(lián)規(guī)則和設計；
2. 家庭服務包在業(yè)務定義上是群體對群體的服務。這種服務與醫(yī)生的關聯(lián)關系是多對多，與就診人的關聯(lián)關系也是多對多的。于是，與原來的就診服務類產生了本質上的不同，接下來內部預約的規(guī)則，收益的分配都因此而變的復雜和不同。如果還復用原來的就診服務這個輪子，已經不再適合。這時就需要抽象出一個新類，來作為接下來設計業(yè)務產品的基礎。

二、OO是產品經理的內功心法

如果某個從事技術開發(fā)的同學恰巧也看到了這篇文章，可能會覺得這些內容如此熟悉，不正是每天開發(fā)的內容么？

那就對了，OO其實也是產品經理的內功心法。

從某個角度講，一個好的產品經理必需的一個能力就是通過OO將業(yè)務產品設計和技術產品設計統(tǒng)一，保證方向和實施的無縫對接，協(xié)調業(yè)務和技術的高效配合。

只有內功心法還不夠，還需要大殺器配合才能做到，那就是大名鼎鼎的UML(Unified Modeling Language)，以后再介紹吧。

本文由 @?SeanLiu 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議