周立功教授數年之心血之作《程序設計與數據結構》以及《面向AMetal框架與接口的編程（上）》，電子版已無償性分享到電子工程師與高校群體，書本內容公開后，在電子行業掀起一片學習熱潮。經周立功教授授權，本公眾號特對《程序設計與數據結構》一書內容進行連載，愿共勉之。

第四章為面向對象編程，本文為4.1OO思想。

第四章導讀

面向過程編程（Process-Oriented Programming，POP）是一種以過程為中心的編程思想，以正在發生的事件為主要目標，指導開發者利用算法作為基本構建塊構建復雜系統。

面向對象編程OOP（Object-Oriented Programming，OOP）是利用類和對象作為基本構建塊，指導開發者探索基于對象和面向對象編程語言的表現力。因此分解系統時，要么從算法開始，要么從對象開始，然后利用得到的結構作為框架構建系統。

>>>4.1OO思想

>>>4.1.1 職責轉移

1、人腦的限制

由于受到電腦的信息處理功能的影響，因此于20世紀60年代初產生了以信息處理論為基礎的認知心理學。美國心理學家喬治?米勒在信息記憶上的研究成就，為新興的認知心理學提供了理論的證據。

雖然當時的心理學家已將信息處理的歷程，大致區分為感官記憶（2秒以下）、短時記憶（15秒以下）與長時記憶，但短時記憶的性質及其重要性，則是在喬治?米勒1956 年發表研究報告《神奇的數字7 +/- 2，我們信息加工能力的局限》之后才被確定的，即米勒魔術——人類只能記住和處理7加或減2項內容。

后來的證據表明基數可能少到3或4，這個數字代表大腦“暫存器”解決問題時所能保存的信息容量。無論實際數目是多少，如果要求普通人同時考慮大約15件事情，實際上最多只能記住和處理其中9件甚至更少。

如果要求處理的事情更多，一次只有幾件可以同時處理，其它的會被快速切入或切出暫存器。想一想去商店采購15件東西，如果沒有一份購物清單，你很可能漏掉東西或買回來的東西數量不正確。同樣的道理，如果需求列表或產品清單中的事項成千上萬，那么你的大腦根本沒辦法處理這樣復雜的事情，除非將它分解成更小的結構化分組。

2、核心域和非核心域

一個軟件系統封裝了若干領域的知識，其中一個領域知識代表了系統的核心競爭力，這個領域被稱為“核心域”，其它領域稱為“非核心域”。雖然更通俗的說法是“業務”和“技術”，但使用“核心域”和“非核心域”更嚴謹。

非核心域就是別人的領域，比如，底層驅動、操作系統和組件，即便你有一些優勢，那也是暫時的，競爭對手也能通過其它渠道獲得。非核心域的改進是必要的，但不充分，還是要在核心域上深入挖掘，讓競爭對手無法輕易從第三方獲得。因為在核心域上深入挖掘，達到基于核心域的復用，這是獲得和保持競爭力的根本手段。

要達到基于核心域的復用，有必要將核心域和非核心域分開考慮。因為人腦的容量是有限的，而過早地將各個領域的知識混雜，會增加不必要的負擔，從而導致開發人員騰不出腦力思考核心域中更深刻的問題。

正因為人腦的容量和運算能力有限，待解決的問題的規模一旦變大，就必須分而治之，因為核心域與非核心域的知識都是獨立的。比如，一個計算器要做到沒有漏洞，其中的問題也很復雜。如果不使用狀態圖對領域邏輯顯式地建模，再根據模型映射到實現。而是直接下手編程，領域邏輯的知識靠臨時去想，最終得到的代碼肯定破綻百出。其實有利潤的系統，其內部都是很復雜的，千萬不要幼稚地認為“我的系統不復雜”。

3、職責轉移

在面向過程編程時，由于主程序承擔的責任太多，要確保一切正確工作，還要協調各個函數并控制它們的先后順序，因此經常會產生非常復雜的代碼。很多時候變化是不可避免的，而功能分解法卻又無法應對可能出現的變化。一旦修改代碼，則bug越來越多。更重要的是，由于人類的大腦無法做太多復雜的處理，記憶力和理解力也是有限的。因此面對復雜的軟件開發時，主程序不能做太多的事情，必須通過“分離關注點”進行職轉移責。

假設要乘出租車去機場，一種方式是告訴司機，按照“啟動、右轉、左轉、停止”等單獨的接口去機場。這種方式需要乘客對自己的行為負責，乘客知道每個城市去機場的路線。

既然用戶的需求總是在變化之中，我們將無法阻止變化。與其抱怨變化，不如改變開發過程，從而更有效地應對變化，面向對象編程就是這樣作為對抗軟件復雜性的手段出現的。

在面向對象編程時，另一種方式是告訴司機，“請載我去機場”。盡管具體實現在廣州、北京或上海等不同城市中是不同的，但在任何城市都可以這么說。因為司機知道怎么去機場，司機對自己的行為負責，并信任司機知道如何執行，這就是職責轉移，顯然這種方法比功能分解法要容易得多。

由于每個對象都對自己的行為負責，因此必須有方法告訴對象要做什么。而方法都被標識為能夠被其它對象調用，這些方法的集合被稱為對象的公開接口。其形象的比喻為，“將軟件對象看成具有某種職責的人，他要與其他人協作完成工作。”

>>> 4.1.2 OO機制

面向對象的編程是由類（class）這種結構實現的，C++類的概念是對C結構概念擴展。因此表面上看起來這些特征與面向對象編程語言有很大的關聯，但實際上能用任何一種語言實現。不管實現語言如何，任何大的軟件系統都會以某種形式使用抽象、繼承或多態性。

1、封裝

封裝是OO方法中的一個重要原則，其含義是將封裝視為任何形式的隱藏，對外形成一個邊界，只暴露有限的對外接口使之與外部發生聯系。封裝不僅僅是將對象的全部屬性和全部操作結合在一起，形成一個不可分割的獨立單位（對象），而是發現變化將其封裝。

抽象實現封裝的分析工具，抽象可以使我們專注于應用程序最本質的方面，同時忽略細節。在確定如何實現功能之前，先關注對象是什么？做了什么？更具體地，抽象是將一類對象的共同特征總結出來創建類的過程，包括數據抽象和行為抽象。

數據抽象是數據和處理方法的結合，即封裝數據和函數到類中的能力，因此又將數據抽象稱為信息隱藏或封裝，信息隱藏是一種軟件設計思想。由于不必知道內部結構，因此可以將數據當作黑盒子來操作。即使將來數據結構發生變化，對外部也沒有影響。從而避免程序的各個組成部分過于相互依賴，否則很小的變化也會引起巨大的連鎖反應。

在結構化的設計中，通常將代碼封裝到函數和模塊中。因此封裝不是OO語言所特有的，但它能將數據結構和行為組織在一個實體中，其主要目的是為使用代碼的程序員提供一致的接口，這是面向對象編程的突出特點。盡管如此，面向對象和結構化的代碼并不是互斥的，實際上不用結構化代碼將無法創建對象。因此在構建面向對象的系統時，在設計中依然離不開結構化的技術。

2、繼承

雖然結構化程序設計通過編寫一個功能塊實現重用，但面向對象程序設計實現代碼重用的方法是允許定義類之間的關系。而繼承是實現該功能的主要手段，其將不同代碼中相同的部分提取出來。即抽取不同類的共同屬性和行為創建全新的類，實現代碼最大限度地重用。

利用類和繼承這兩個特性，高效地將抽象數據通過類封裝起來，即通過類將同一類對象管理起來。因此可以說類是將數據黑盒子化的工具，而繼承可以從其它類繼承屬性，只需要擴展實現或對實現稍作改進，即可支持軟件重用。

在經典的Shape（形狀）示例中，Circle（圓形）、Square（矩形）和Star（星形）都直接繼承自Shape，這種關系通常被稱為is-a關系。因為圓是一種形狀，矩形也是一種形狀，星形也是一種形狀，即Circle、Square和Star都是Shape的擴展。當子類繼承自父類時，任何父類能做的事情子類都可以做。

3、多態性

當你要求某人畫一個形狀Shape時，實際上沒有人能完成這個任務。因為形狀是一個抽象的概念，所以Shape無法提供繪制代碼，必須指定一個具體的形狀。有了具體形狀，就可以為各種具體形狀實現各自的繪圖代碼。

顯然，無論畫什么形狀，其共性是Draw畫圖方法，每種形狀都可以通過函數指針調用各自的繪圖代碼繪制自己，這就是多態的意義，即多態允許用相同的方法（代碼）在運行中，根據對象的類型調用不同的處理函數。

4、組合

組合是指在類中包含一個對象，且該對象是其它類的實例，開發者將責任委托給所包含的對象完成。組合有兩種方式：聚合和組合，這些方式表示了對象之間的協作關系。

聚合就是“可聚可散”的意思，被包含的對象如同一個集合。聚合關系是整體與部分的關系，且部分可以離開整體而單獨存在。雖然汽車和發動機是整體和部分的關系，但發動機離開汽車仍然可以存在，所以汽車和發動機是聚合關系。

雖然組合關系也是某種形式的整體和部分的聚合，但部分不能離開整體而單獨存在，部分對象與整體對象之間具有同生共死的關系。在組合關系中，部分是整體的一部分，且整體可以控制部分的生命周期，即部分的存在依賴于整體。

雖然花瓣不是一種花，但它是花的一部分，因此它們之間存在一種真正的has-a組合關系，不存在父子關系。同樣，頭部是由眼睛、嘴巴、鼻子和耳朵組合而成的，如果頭部不存在，那么這些部件都不能單獨存在。

>>> 4.1.3 OO收益

耦合性與內聚性是相輔相成的關系，內聚性描述的是一個模塊內部組成部分之間相互聯系的緊密程度，而耦合性描述的是一個模塊與其它模塊之間聯系的緊密程度。由此可見，無論使用哪種方法，軟件開發的目標是創建符合“高內聚、低耦合”這樣的模塊。也就是說，每個模塊盡可能獨立完成某個特定的功能。

如果模塊之間做到了低耦合，那么修改一個模塊就不需要修改另一個模塊。使用模塊化最重要的一點是，能夠獨立修改單個模塊，而不需要修改系統的其它模塊。一個典型的錯誤是，使用緊耦合的方式做模塊之間的集成，從而使得一個模塊的修改會導致其消費者的修改。一個低耦合的模塊應該盡可能少地知道與之協作的那些模塊的信息，即應該限制兩個模塊之間不同調用形式的數量，因為除了潛在的性能問題之外，過度的通信可能會導致緊耦合。

內聚性用于評估一個組件（包、模塊或配件）中成員的功能相關性，內聚程度高表明各個成員共同完成了一個功能特性或一組功能特性，內聚程度低表明各個成員提供的功能互不相干。如果一個類的方法和屬性共同完成了一個功能或一系列緊密相關的功能，這個類就是內聚的。假設有一個這樣的類，實現了3種完全不同的功能。如果這3個功能的需求細節發生了變化，這個類也必須跟著改變，從而導致更多的開發和維護成本。因此高內聚就是將相關的行為聚集在一起，而將不相關的行為放在別處。這樣做的好處是，如果要修改某個行為，則只在一個地方修改，即可盡快發布。