重拾面向对象软件设计
作者 | 聶曉龍
來源 | 阿里技術(shù)公眾號
你還在用面向?qū)ο蟮恼Z言，寫著面向過程的代碼嗎？
一 前言
在歐洲文藝復興時期，一位偉大的數(shù)學家天文學家-哥白尼，在當時提出了日心說，駁斥了以地球為宇宙中心的天體思想，由于思想極其超前，直到半個世紀后開普勒伽利略等人經(jīng)過后期研究，才逐步認可并確立了當時哥白尼思想的先進性。
無獨有偶，在軟件工程領域也上演著同樣的故事。半個世紀前 Kristen Nygaard發(fā)明了Simula語言，這也是現(xiàn)在被認同的世界上第一個明確實現(xiàn)面向?qū)ο缶幊痰恼Z言，他提出了基于類的編程風格，確定了"萬物皆對象"這一面向?qū)ο罄碚摰?#34;終極思想"，但在當時同樣未受到認可。Peter Norvig 在 Design Patterns in Dynamic Programming 對此予以了駁斥，并表述我們并不需要什么面向?qū)ο蟆０雮€世紀后 Robert C.Martin、Bertrand Meyer、Martin Fowler等人，再次印證并升華了面向?qū)ο蟮脑O計理念。編程思想的演進也不是一蹴而就，但在這一個世紀得到了飛速的發(fā)展。
二 編程思想的演進
從上個世紀五十年代馮·諾依曼創(chuàng)造第一臺計算機開始，一直到現(xiàn)在只有短短70年時間，從第一門計算機語言FORTRAN，到現(xiàn)在我們常用的C++，JAVA，PYTHON等，計算機語言的演進速度遠超我們所使用的任何一門自然語言。從最早的面向機器，再到面向過程，到演化為現(xiàn)在我們所使用的面向?qū)ο蟆２蛔兊氖蔷幊痰淖谥?#xff0c;變化的是編程的思想。
1 面向機器
計算機是01的世界，最早的程序就是通過這種01機器碼來控制計算機的，比如0000代表讀取，0001代表保存等。理論上這才是世界上最快的語言，無需翻譯直接運行。但弊端也很明顯，那就是幾乎無法維護。運行5毫秒，編程3小時。由于機器碼無法維護，人們在此基礎上發(fā)明了匯編語言，READ代表0000，SAVE代表0001，這樣更易理解和維護。雖然匯編在機器碼上更可視更直觀，但本質(zhì)上還是一門面向機器的語言，依然還是存在很高的編程成本。
2 面向過程
面向過程是一種以事件為中心的編程思想，相比于面向機器的編程方式，是一種巨大的進步。我們不用再關(guān)注機器指令，而是聚焦于具體的問題。它將一件事情拆分成若干個執(zhí)行的步驟，然后通過函數(shù)實現(xiàn)每一個環(huán)節(jié)，最終串聯(lián)起來完成軟件設計。
流程化的設計讓編碼更加清晰，相比于機器碼或匯編，開發(fā)效率得到了極大改善，包括現(xiàn)在仍然有很多場景更適合面向過程來完成。但軟件工程最大的成本在于維護，由于面向過程更多聚焦于問題的解決而非領域的設計，代碼的重用性與擴展性弊端逐步彰顯出來，隨著業(yè)務邏輯越來越復雜，軟件的復雜性也變得越來越不可控。
3 面向?qū)ο?/h4>
面向?qū)ο笠苑诸惖姆绞竭M行思考和解決問題，面向?qū)ο蟮暮诵氖浅橄笏季S。通過抽象提取共性，通過封裝收斂邏輯，通過多態(tài)實現(xiàn)擴展。面向?qū)ο蟮乃枷氡举|(zhì)是將數(shù)據(jù)與行為做結(jié)合，數(shù)據(jù)與行為的載體稱之為對象，而對象要負責的是定義職責的邊界。面向過程簡單快捷，在處理簡單的業(yè)務系統(tǒng)時，面向?qū)ο蟮男Ч鋵嵅⒉蝗缑嫦蜻^程。但在復雜系統(tǒng)的設計上，通用性的業(yè)務流程，個性化的差異點，原子化的功能組件等等，更適合面向?qū)ο蟮木幊棠Ｊ健?/p>
但面向?qū)ο笠膊皇倾y彈，甚至有些場景用比不用還糟，一切的根源就是抽象。根據(jù) MECE法則 將一個事物進行分類，if else 是軟件工程最嚴謹?shù)姆诸悺Ｎ覀冊谠O計抽象進行分類時，不一定能抓住最合適的切入點，錯誤的抽象比沒有抽象復雜度更高。里氏替換原則的創(chuàng)始人Barbara Liskov 談抽象的力量 The Power of Abstraction。
三 面向領域設計
1 真在“面向?qū)ο蟆眴?/h4> // 撿入客戶到銷售私海 public String pick(String salesId, String customerId){// 校驗是否銷售角色Operator operator = dao.find("db_operator", salesId);if("SALES".equals(operator.getRole())){return "operator not sales";}// 校驗銷售庫容是否已滿int hold = dao.find("sales_hold", salesId);List<CustomerVo> customers = dao.find("db_sales_customer", salesId);if(customers.size() >= hold){return "hold is full";}// 校驗是否客戶可撿入Opportunity opp = dao.find("db_opportunity", customerId);if(opp.getOwnerId() != null){return "can not pick other's customer";}// 撿入客戶opp.setOwnerId(salesId);dao.save(opp);return "success"; }
這是一段CRM領域銷售撿入客戶的業(yè)務代碼。這是我們熟悉的Java-面向?qū)ο笳Z言，但這是一段面向?qū)ο蟠a嗎？完全面向事件，沒有封裝沒有抽象，難以復用不易擴展。相信在我們代碼庫，這樣的代碼不在少數(shù)。為什么？因為它將成本放到了未來。我們將此稱之為“披著面向?qū)ο蟮耐庖?#xff0c;干著面向過程的勾當。”
在系統(tǒng)設計的早期，業(yè)務規(guī)則不復雜，邏輯復用與擴展體現(xiàn)得也并不強烈，而面向過程的代碼在支撐這些相對簡單的業(yè)務場景是非常容易的。但軟件工程最大的成本在于維護，當系統(tǒng)足夠復雜時，當初那些寫起來最easy的代碼，將來就是維護起來最hard的債務。
2 領域驅(qū)動設計
還有一種方式我們也可以這么來寫，新增“商機”模型，通過商機來關(guān)聯(lián)客戶與銷售之間的關(guān)系。而商機的歸屬也分為公海、私海等具體歸屬場景。商機除了有必要的數(shù)據(jù)外，還應該收攏一些業(yè)務行為，撿入、開放、分發(fā)等。通過領域建模，利用面向?qū)ο蟮奶匦?#xff0c;確定邊界、抽象封裝、行為收攏，對業(yè)務分而治之。
當我們業(yè)務上說“商機分發(fā)到私海”，而我們代碼則是“opportunity.pickTo(privateSea)”。這是領域驅(qū)動所帶來的改變，面向領域設計，面向?qū)ο缶幊?#xff0c;領域模型的抽象就是對現(xiàn)實世界的描述。但這并非一蹴而就的過程，當你只觸碰到大象的身板時，你認為這是一扇門，當你觸碰到大象的耳朵時，你認為是一片芭蕉。只有我們不斷抽象不斷重構(gòu)，我們才能愈發(fā)接近業(yè)務的真實模型。
Use the model as the backbone of a language, Recognize that a change in the language is a change to the model.Then refactor the code, renaming classes, methods, and modules to conform to the new model
--- Eric Evans 《Domain-Driven Design Reference》
譯：使用模型作為語言的支柱，意識到言語的改變就是對模型的改變，然后重構(gòu)代碼，重命名類，方法和模塊以符合新模型。
3 軟件的復雜度
這是Martin Flowler在 Patterns of Enterprise Application Architecture 這本書中所提的關(guān)于復雜度的觀點，他將軟件開發(fā)分為數(shù)據(jù)驅(qū)動與領域驅(qū)動。很多時候開發(fā)的方式大家傾向于，拿到需求后看表怎么設計，然后看代碼怎么寫，這其實也是面向過程的一個表現(xiàn)。在軟件初期，這樣的方式復雜度是很低的，沒有復用沒有擴展，一人吃飽全家不餓。但隨著業(yè)務的發(fā)展系統(tǒng)的演進，復雜度會陡增。
而一開始通過領域建模方式，以面向?qū)ο笏季S進行軟件設計，復雜度的上升可以得到很好的控制。先思考我們領域模型的設計，這是我們業(yè)務系統(tǒng)的核心，再逐步外延，到接口到緩存到數(shù)據(jù)庫。但領域的邊界，模型的抽象，從剛開始成本是高于數(shù)據(jù)驅(qū)動的。
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
--- Robert C. Martin 《Clean Architecture》
譯：軟件架構(gòu)的終極目標是，用最小的人力成本來滿足構(gòu)建和維護該系統(tǒng)的需求
如果剛開始我們直接以數(shù)據(jù)驅(qū)動面向過程的流程式代碼，可以很輕松的解決問題，并且之后也不會面向更復雜的場景與業(yè)務，那這套模式就是最適合這套系統(tǒng)的架構(gòu)設計。如果我們的系統(tǒng)會隨著業(yè)務的發(fā)展逐漸復雜，每一次的發(fā)布都會提升下一次發(fā)布的成本，那么我們應該考慮投入必要的成本來面向領域驅(qū)動設計。
四 抽象的品質(zhì)
抽象永遠是軟件工程領域最難的命題，因為它沒有規(guī)則，沒有標準，甚至沒有對錯，只分好壞，只分是否適合。同樣一份淘寶商品模型的領域抽象，可以算是業(yè)界標桿了，但它并非適合你的系統(tǒng)。那我們該如何駕馭“抽象”呢？UML的創(chuàng)始人Grady booch在 Object Oriented Analysis and Design with Applications 一書中，提到了評判一種抽象的品質(zhì)可以通過如下5個指標進行測量：耦合性、內(nèi)聚性、充分性、完整性與基礎性。
1 耦合性
一個模塊與另一個模塊之間建立起來的關(guān)聯(lián)強度的測量稱之為耦合性。一個模塊與其他模塊高度相關(guān)，那它就難以獨立得被理解、變化或修改。TCL語言發(fā)明者John Ousterhout教授也有同樣的觀點。我們應該盡可能減少模塊間的耦合依賴，從而降低復雜度。
Complexity is caused by two things: dependencies and obscurity.
--- John Ousterhout 《A Philosophy of Software Design》
譯：復雜性是由兩件事引起的：依賴性和模糊性。
但這并不意味著我們就不需要耦合。軟件設計是朝著擴展性與復用性發(fā)展的，繼承天然就是強耦合，但它為我們提供了軟件系統(tǒng)的復用能力。如同摩擦力一般，起初以為它阻礙了我們前進的步伐，實則沒有摩擦力，我們寸步難行。
2 內(nèi)聚性
內(nèi)聚性與耦合性都是結(jié)構(gòu)化設計中的概念，內(nèi)聚性測量的是單個模塊里，各個元素的的聯(lián)系程度。高內(nèi)聚低耦合，是寫在教科書里的觀點，但我們也并非何時何地都應該盲目追求高內(nèi)聚。
內(nèi)聚性分為偶然性內(nèi)聚與功能性內(nèi)聚。金魚與消防栓，我們一樣可以因為它們都不會吹口哨，將他們抽象在一起，但很明顯我們不該這么干，這就是偶然性內(nèi)聚。最希望出現(xiàn)的內(nèi)聚是功能性內(nèi)聚，即一個類或模式的各元素一同工作，提供某種清晰界定的行為。比如我將消防栓、滅火器、探測儀等內(nèi)聚在一起，他們是都屬于消防設施，這是功能性內(nèi)聚。
3 充分性
充分性指一個類或模塊需要應該記錄某個抽象足夠多的特征，否則組件將變得不用。比如Set集合類，如果我們只有remove、get卻沒有add，那這個類一定沒法用了，因為它沒有形成一個閉環(huán) 。不過這種情況相對出現(xiàn)較少，只要當我們真正去使用，完成它的一系列流程操作后，缺失的一些內(nèi)容是比較容易發(fā)現(xiàn)并解決的。
4 完整性
完整性指類或模塊需要記錄某個抽象全部有意義的特征。完整性與充分性相對，充分性是模塊的最小內(nèi)涵，完整性則是模塊的最大外延。我們走完一個流程，可以清晰得知道我們?nèi)蹦男?#xff0c;可以讓我們馬上補齊抽象的充分性，但可能在另一個場景這些特征就又不夠了，我們需要考慮模塊還需要具備哪些特征或者他應該還補齊哪些能力。
5 基礎性
充分性、完整性與基礎性可以說是3個相互輔助相互制約的原則。基礎性指抽象底層表現(xiàn)形式最有效的基礎性操作（似乎用自己在解釋自己）。比如Set中的add操作，是一個基礎性操作，在已經(jīng)存在add的情況下，我們是否需要一次性添加2個元素的add2操作？很明顯我們不需要，因為我們可以通過調(diào)用2次add來完成，所以add2并不符合基礎性。
但我們試想另一個場景，如果要判斷一個元素是否在Set集合中，我們是否需要增加一個contains方法。Set已經(jīng)有foreach、get等操作了，按照基礎性理論，我們也可以把所有的元素遍歷一遍，然后看該元素是否包含其中。但基礎性有一個關(guān)鍵詞叫“有效”，雖然我們可以通過一些基礎操作進行組合，但它會消耗大量資源或者復雜度，那它也可以作為基礎操作的一個候選者。
五 軟件設計原則
抽象的品質(zhì)可以指導我們抽象與建模，但總歸還是不夠具象，在此基礎上一些更落地更易執(zhí)行的設計原則涌現(xiàn)出來，最著名的當屬面向?qū)ο蟮奈宕笤O計原則 S.O.L.I.D。
1 開閉原則OCP
Software entities should be open for extension,but closed for modification
-- Bertrand Meyer 《Object Oriented Software Construction》
譯：軟件實體應當對擴展開放，對修改關(guān)閉。
開閉原則是Bertrand Meyer 1988年在 Object Oriented Software Construction 書中所提到一個觀點，軟件實體應該對擴展開放對修改關(guān)閉。
我們來看一個關(guān)于開閉原則的例子，需要傳進來的用戶列表，分類型進行二次排序，我們代碼可以這樣寫。
上述代碼就是一個明顯違背開閉原則的例子，當我們需要新增一種類似時，需要修改主流程。由于這些方法都定義在私有函數(shù)中，我們哪怕對現(xiàn)有邏輯做調(diào)整，我們也需要修改到這份代碼文件。
還有一種做法，可以實現(xiàn)對擴展開放對修改關(guān)閉，JDK的排序其實已經(jīng)為我們定義了這樣的標準。我們將不同的排序方式進行抽象，每種邏輯單獨實現(xiàn)，單個調(diào)整邏輯不影響其他內(nèi)容，新增排序方式也無需對已有模塊進行調(diào)整。
2 依賴倒置DIP
High level modules shouldnot depend upon low level modules.Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions
--- Robert C.Martin C++ Report 1996
譯：高層模塊不應該依賴低層模塊，兩者都應該依賴抽象；抽象不應該依賴細節(jié)，細節(jié)應該依賴抽象。
Robert C.Martin是《Clean Code》《Code Architecture》兩本經(jīng)典書籍的作者，1996年他在C++ Report中發(fā)表了一篇名為 The Dependency Inversion Principle 的文章。他認為模塊間的依賴應該是有序的，高層不應該依賴低層，低層應該依賴高層，抽象不應該依賴細節(jié)，細節(jié)應該依賴抽象。
怎么理解Robert C.Martin的這一觀點。我們看這張圖，我們的手可以握住這個杯子，是我們依賴杯子嗎？有人說我們需要調(diào)杯子提供的hold服務，我們才能握住它，所以是我們依賴杯子。但我們再思考一下，棍子我們是不是也可以握，水壺我們也可以握，但貓狗卻不行，為什么？因為我們的杯子是按照我們的手型進行設計的，我們定義了一個可握持的holdable接口，杯子依賴我們的需求進行設計。所以是杯子依賴我們，而非我們依賴杯子。
依賴倒置原則并非一個新創(chuàng)造的理論，我們生活的很多地方都有在運用。比如一家公司需要設立“法人”，如果這家公司出了問題，監(jiān)管局就會找公司法人。并非監(jiān)管局依賴公司提供的法人職位，它可以找到人，而是公司依賴監(jiān)管局的要求，才設立法人職位。這也是依賴倒置的一種表現(xiàn)。
3 其他設計原則
這里沒有一一將 S.O.L.I.D 一一列舉完，大家想了解的可以自行查閱。除了SOLID之外，還有一些其他的設計原則，同樣也非常優(yōu)秀。
PLOA最小驚訝原則
If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature
-- Michael F. Cowlishaw
譯：如果必要的特征具有較高的驚人因素，則可能需要重新設計該特征。
PLOA最小驚訝原則是斯坦福大家計算機教授 Michael F. Cowlishaw 提出的。不管你的代碼有“多好”，如果大部分人都對此感到吃驚，或許我們應該重新設計它。JDK中就存在一例違反PLOA原則的案例，我們來看下面這段代碼。
在分享會上，我故意將這行注釋遮蓋起來，大家都猜不到 newFormatter.getClass() 這句代碼寫在這里的作用。如果要檢查空指針，完全可以用Objects工具類提供的方法，實現(xiàn)完全一樣，但代碼表現(xiàn)出來的含義就千差萬別了。
KISS簡單原則
Keep it Simple and Stupid-- Robert S. Kaplan
譯：保持愚蠢，保持簡單
KISS原則是 Robert S. Kaplan 提出的一個理論，Kaplan并非是一個軟件學家，他是平衡積分卡Balanced Scorecard創(chuàng)始人，而他所提出的這個理論對軟件行業(yè)依然適用。把事情變復雜很簡單，把事情變簡單很復雜。我們需要盡量讓復雜的問題簡明化、簡單化。
六 寫在最后
軟件設計的最大目標，就是降低復雜性，萬物不為我所有，但萬物皆為我用。引用JDK集合框架創(chuàng)辦人Josh Bloch 的一句話來結(jié)束。學習編程藝術(shù)首先要學會基本的規(guī)則，然后才能知道什么時候可以打破這些規(guī)則。
You should not slavishly follow these rules, but violate them only occasionally and with good reason. Learning the art of programming, like most other disciplines, consists of first learning the rules and then learning when to break them.
--- Josh Bloch 《Effective Java》
譯：你不該盲目的遵從這些規(guī)則，應該只在偶爾情況下，有充分理由后才去打破這些規(guī)則
學習編程藝術(shù)首先要學會基本的規(guī)則，然后才能知道什么時候可以打破這些規(guī)則
參閱書籍
1、《Object Oriented Analysis and Design with Applications》https://niexiaolong.github.io/Object%20Oriented%20Analysis%20and%20Design%20with%20Applications.pdf
2、《Clean Architecture》
https://detail.tmall.com/item.htm?id=654392764249
3、《A Philosophy of Software Design》
https://www.amazon.com/-/zh/dp/173210221X/ref=sr_1_1?qid=1636246895
第一期阿里云鏡像站體驗官持續(xù)招募中
鏡像站體驗官第一期招募開始啦, 12月24日前在各大社區(qū)平臺分享鏡像相關(guān)內(nèi)容累計積分就可贏得獎勵，銀牌體驗官的獎勵人數(shù)不設限哦。
點擊這里，參與報名吧。
原文鏈接：https://developer.aliyun.com/article/808762?
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的重拾面向对象软件设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 12.04 深圳站 | Serverle
- 下一篇： 如何让智能客服成为企业的生产力工具？