面向對象的思考過程(原書第5版)（簡體書）

經典書全面更新，加入設計模式、SOLID準則等章節，補全面向對象設計思想

正如書名所述，本書闡述了物件導向的思考過程。選擇一本書的主題和書名是很重要的，但如果主題的概念性很強的話，做決定就沒那麼容易了。大部分書籍都只涉及程序設計與物件導向設計的某個方面。一些流行的書則闡述了諸如物件導向分析、物件導向設計、物件導向程序設計、設計模式、物件導向的資料結構（XML）、統一模組化語言（UML）、物件導向Web開發、物件導向移動開發、各種物件導向程序設計語言等與物件導向程序設計（OOP）相關的主題。
然而，許多人仔細研讀這些書後，未曾注意到這些主題都建立在同一個基礎之上，即如何以物件導向的方式進行思考。從學生到軟件發展專業人員，他們往往只是閱讀了這些書，卻沒有付出充分的時間和努力來真正理解代碼背後的設計理念。
我認為僅學習一種特定的開發方式、一種程序設計語言或者一組設計工具並不能說明學會了物件導向這一概念。物件導向的軟件發展簡單來說就是一種思考方式。本書就是關於這種物件導向的思考過程的。
把物件導向的思考過程從語言、開發實踐以及工具中剝離出來並不是一個簡單的任務。人們在學習物件導向這一理念時，往往被要求先深入學習一門程序設計語言。例如，很多年以前，大量的C語言程序員在沒有直接接觸物件導向概念之前，就開始通過C++語言來瞭解物件導向。
學習物件導向的概念與學習使用物件導向語言進行程序設計有著巨大差異，理解這一點很重要。我在撰寫本書第1版前就意識到了這一點。Craig Larman在“What the UML Is-and Isn’t”一文中指出：
不幸的是，在軟件工程和UML圖表語言上下文中，閱讀和編寫UML標記的技能有時等同於物件導向分析和設計的能力。當然，事實並非如此，而且後者遠比前者重要。因此，我推薦尋找一些教學材料來學習使用物件導向分析和設計的知識技能，這優先於學習UML標記或者輔助工具。
因此，儘管學習一門建模語言是非常重要的步驟，但先學習物件導向的技能更加重要。在完全理解物件導向概念前就學習UML，就像還未瞭解任何與電路相關的知識就開始學習電路圖一樣。
學習程序設計語言也有相同的問題。如前所述，很多C語言程序員還未直接瞭解任何物件導向概念，就想通過使用C++語言來達到物件導向的水準。在面試中經常會出現這樣的情況，很多抱怨C++的程序員其實只是會簡單使用C++編譯器的C語言程序員。甚至現在，諸如C# NET、VB NET、Objective-C、Swift以及Java等語言已經相當普及了，但工作面試中的一些關鍵問題還是可以迅速暴露出這些程序員缺乏物件導向的思想。
Visual Basic的早期版本並不是物件導向的。C語言也不是物件導向的，而C++在設計時就向後相容C語言。因此，使用C++編譯器編寫只含C語言語法的程式，而放棄使用C++的物件導向功能是完全可能的。Objective-C被設計為標準ANSI C語言的一個擴展。最糟糕的是，程序員可能使用“半瓶子”的物件導向功能把程式寫成既不是物件導向的也不是面向過程的“四不像”產品。
因此，在學習使用物件導向的開發環境之前，先學習基本的物件導向概念至關重要。與其直接學習一門程序設計語言，不如把時間花在學習物件導向的思考過程上。
第5版中的新內容
就像在前言中經常提到的那樣，我對第1版的願景是堅持概念，而不是專注於某項特定的新興技術。對於第5版，我仍然堅持這個願景，但我也會介紹比早期版本中更多的“相反觀點”。我想表達的是，儘管到目前為止，物件導向的軟件發展是市面上最大的遊戲，但它並不是唯一的遊戲。
自從本書的第1版於1999年完成以來，市場上出現了許多技術，同時也有些技術已經逐漸消失。當時，Java剛剛發佈，並且是最主要的物件導向開發語言；網頁即將成為日常生活和商業的一部分。如今，我們都知道移動設備已經變得無處不在。在過去的20年中，軟件發展人員經歷了XML、JSON、CSS、XSLT、SOAP和RESTful Web服務。Android設備過去使用Java，現在使用Kotlin，而iOS設備使用Objective-C和Swift。
過去20年來，我們已經採用了許多技術（以及本書的前四版）。第5版的主要目標是將所有內容濃縮到第1版的初始意圖，即簡單的物件導向概念。我認為本書的第1版取得的所有成功，都是源於它專注於物件導向的基本概念。在某些方面，第5版囊括了前面所有版本提到的技術。
最後，將這些技術封裝到設計方法中的概念由SOLID表示，該概念貫穿本書的所有章節。
SOLID原則是：
SRP—單一職責原則
OCP—開閉原則
LSP—裡氏替換原則
ISP—接口隔離原則
DIP—依賴倒置原則
本書的前9章代表了我認為的經典物件導向原則，而最後3章（關於設計模式、避免依賴和SOLID原則）代表了一種強大的方法論。
目標讀者
本書是對物件導向基本概念的全面介紹。“概念”一詞很重要—雖然可以通過使用代碼示例來加深對本書中討論的內容的理解，但本書的焦點是使讀者理解物件導向的思考過程。對於程序員來說，需要強調一點：物件導向程序設計並不是唯一的標準（正如許多人認為的那樣）—物件導向程序設計，僅僅是現代軟件發展人員可以使用的龐大工具包的一部分。
當我於1995年首次準備本書第1版的素材時，物件導向的概念才剛剛興起。我之所以這麼說，是因為當時除了Smalltalk之類的物件導向語言外，還沒有真正意義上的物件導向語言。不強制執行物件導向規則的C++，是當時占主導地位的C風格的程序設計語言。Java 10於1996年才發佈，C# 10於2002年才發佈。事實上，當本書的第1版於1999年出版時，我們還無法確定物件導向是否會真正成為領先的開發規則。（Java 2直到1998年12月才發佈。）儘管物件導向程序設計目前占主導地位，但其中仍有一些有趣的問題需要解決。
顯然，本書第1版的讀者與今天的讀者有所不同。
從1995年到2010年，我基本上是在物件導向的技術方面對許多結構化程序員進行重新培訓。這些學員中的絕大多數都是在大學和工作期間，與COBOL、FORTRAN、C和VB一起成長的。而如今，大學畢業、編寫電子遊戲、創建網站，或創作移動應用程式的學生，幾乎可以肯定已經學會了使用物件導向語言的程序設計。因此，本書這一版採用的方法與第1版或第2版等有很大不同。我們現在不是在教結構化程序員如何成為物件導向開發人員，而是在教那些使用物件導向語言成長起來的程序員。
本書適合任何想要全面瞭解物件導向概念的業務經理、設計師、開發人員、程序員和項目經理閱讀。我的希望是，閱讀本書能為學習更高級的主題奠定堅實的基礎。
本書敘述方式
顯然，我堅定地認為，熟悉物件導向的思考過程優先於學習程序設計語言或建模語言。本書中有不少代碼示例及UML類圖，但閱讀本書並不需要掌握一門具體的程序設計語言或UML。我已經說過了要先學習概念本身，那為什麼本書會有如此多代碼和類圖？
首先，代碼和類圖可以很好地展示物件導向概念。其次，它們對於物件導向的使用方式是極其重要的，有助於介紹和展示如何使用物件導向。關鍵在於不要過分關注Java、C#等程序設計語言，而應當使用它們來幫助理解物件導向的深層理念。
要注意的是，在理解類及其自身的屬性和方法時我非常喜歡使用UML類圖實現可視化。事實上，本書中只用到了UML組件中的類圖。我認為UML類圖提供了一種強大的方式來類比物件模型的概念本質。我依舊使用物件模型作為教學工具來展示類的設計以及類之間的關係。
本書中的代碼示例闡述了諸如迴圈和函數之類的概念。然而，理解代碼本身並不是理解物件導向概念的先決條件。如果你想瞭解語言本身的更多細節，那麼有一本講解語言語法的書放在手邊則非常有用。
我不能過分強調本書不教授Java、C# NET、VB NET、Objective-C、Swift或UML。你可以自學這些知識。同樣重要的是要理解這是一本闡述概念的書。在本書中，示例的意圖並非描述設計類的最佳方法，它們更是一種教育性的練習，旨在使你思考物件導向的概念。例如，很明顯，你不會在工作中創建許多企鵝和無吠犬模型，但是使用它們是演示概念的一種有趣方式。考慮到所有這些，我希望本書能引起你對其他物件導向主題的興趣，例如物件導向分析、物件導向設計和物件導向程序設計。

譯者序
前言
致謝
關於作者
第1章　物件導向的概念簡介1
11　基本概念1
12　物件及遺留系統2
13　過程式程序設計與物件導向程序設計對比4
14　由面向過程開發過渡到物件導向開發7
141　過程式程序設計7
142　物件導向程序設計8
15　什麼是物件8
151　物件資料8
152　物件行為9
16　什麼是類13
161　創建物件13
162　屬性15
163　方法15
164　消息15
17　使用類圖作為可視化工具16
18　封裝和數據隱藏16
181　接口17
182　實現18
183　接口/實現範式的一個真實示例18
184　接口/實現範式的模型19
19　繼承20
191　超類和子類21
192　抽象21
193　is-a關係23
110　多態性24
111　組合27
1111　抽象27
1112　has-a關係28
112　本章小結28
第2章　如何以物件的方式進行思考29
21　清楚接口和實現之間的區別30
211　接口32
212　實現32
213　一個接口/實現示例33
22　使用抽象思維設計接口37
23　盡可能提供最小化的使用者接口39
231　確定用戶39
232　物件行為40
233　環境約束40
234　識別公共接口40
235　識別實現41
24　本章小結42
25　參考文獻42
第3章　更多物件導向概念43
31　構造函數43
311　什麼是構造函式呼叫44
312　構造函數中包含什麼44
313　預設構造函數45
314　使用多個構造函數46
315　設計構造函數49
32　錯誤處理50
321　忽略問題50
322　檢查問題並中止應用程式50
323　檢查問題並試圖恢復51
324　拋出異常51
33　作用域的重要性54
331　局部屬性?54
332　物件屬性55
333　類屬性57
34　操作符重載58
35　多重繼承59
36　物件操作60
37　本章小結62
38　參考文獻62
第4章　類的剖析63
41　類名63
42　注釋65
43　屬性65
44　構造函數67
45　訪問器69
46　公共接口方法71
47　私有實現方法72
48　本章小結72
49　參考文獻73
第5章　類設計指導75
51　對現實世界系統建模75
52　識別公共接口76
521　最小化公共接口77
522　隱藏實現78
53　設計健壯的構造函數（以及析構函數）78
54　在類中設計錯誤處理79
541　記錄類並使用注釋80
542　構建可以合作的物件80
55　設計時請考慮重用81
56　設計時請考慮可擴展性81
561　保持命名具有描述性82
562　抽象不可移植的代碼82
563　提供一種方式來複製和比較物件83
564　保持盡可能小的作用域83
57　設計時請考慮可維護性84
571　在開發過程中使用反覆運算85
572　測試接口85
58　使用物件持久化87
59　本章小結89
510　參考文獻89
第6章　使用物件進行設計91
61　設計指導91
611　進行正確的分析95
612　編寫工作陳述文檔95
613　收集需求95
614　開發系統原型96
615　識別類96
616　確定每個類的職責96
617　確定類之間如何協作96
618　創建類模型來描述系統97
619　在代碼中創建使用者接口原型97
62　物件包裝97
621　結構化代碼98
622　包裝結構化代碼99
623　包裝不可移植的代碼101
624　包裝已有類102
63　本章小結103
64　參考文獻103
第7章　精通繼承和組合105
71　重用物件105
72　繼承107
721　泛化和特化109
722　設計決策110
73　組合112
74　為什麼封裝是物件導向的本質115
741　繼承如何減弱封裝115
742　關於多態性的一個具體例子118
743　物件職責118
744　抽象類別、虛方法和協議122
75　本章小結123
76　參考文獻124
第8章　框架和重用：使用接口和抽象類別進行設計125
81　代碼：重用還是不重用125
82　什麼是框架126
83　什麼是契約128
831　抽象類別129
832　接口131
833　綜合運用133
834　編譯器佐證136
835　創建契約137
836　系統外掛程式139
84　一個電子商務示例139
841　一個電子商務問題140
842　非重用方式141
843　電子商務解決方案143
844　UML物件模型143
85　本章小結147
86　參考文獻148
第9章　創建物件及物件導向設計149
91　組合關係150
92　分階段構建151
93　組合類型153
931　聚合153
932　聯合154
933　同時使用聯合和聚合155
94　避免依賴156
95　基數157
951　多個物件聯合158
952　可選的聯合160
96　一個綜合性示例160
97　本章小結161
98　參考文獻162
第10章　設計模式163
101　為什麼使用設計模式164
102　Smalltalk的模型/視圖/控制器165
103　設計模式類型167
1031　創建型模式?167
1032　結構型模式171
1033　行為型模式174
104　反模式175
105　本章小結176
106　參考文獻177
第11章　避免依賴和高度耦合的類179
111　繼承、組合和依賴注入181
1111　繼承182
1112　組合183
1113　依賴注入186
112　本章小結189
113　參考文獻189
第12章　物件導向設計的SOLID原則191
121　物件導向設計的SOLID原則概述192
1211　SRP：單一職責原則192
1212　OCP：開閉原則196
1213　LSP：裡氏替換原則198
1214　ISP：接口隔離原則201
1215　DIP：依賴倒置原則202
122　本章小結208
123　參考文獻208