前言

寫書不是一件容易的事，因為許多自以為想得很清楚的事情，一旦用文字來表達總感覺有些語焉不詳。同時，將自己寫的代碼公開需要很大的決心，代碼的規范性、正確性等都是需要考慮的問題。幸運的是，各位讀者還是看到了這本書。筆者認為，對于那些剛接觸面向對象開發的人，或者已經具備基本知識卻不知道如何運用的開發者，擁有一本結合開發實踐Python設計模式的書是很有必要的。筆者結合自己二十多年的開發工作經驗，將關于面向對象和設計模式的知識通過Python語言展示給各位讀者。面向對象、設計模式的初學者通過本書可以快速入門；已經基本掌握設計模式的開發者通過本書可以理解設計模式在實際開發中的運用，從而能夠合理、有效地選擇設計模式。

關于設計模式

在實際開發中運用設計模式有利于設計出擴展性更好、更規范的軟件架構。在軟件開發過程中，總有部分內容是設計者憑直覺得出的結論，但是憑直覺得出的結論不可避免地會出現不易理解的內容。通過運用設計模式，可以在另一個高度上審視自己的設計。面向對象的開發很多時候是基于規則的，越早使用規則，越能在早期發現問題，越能開發出獨立性強、擴展性好的軟件，而設計模式就是經過實踐證明的諸多規則的最佳實踐。

理解了設計模式相當于掌握了一種更高級的設計語言。在考慮設計方案時，一個設計模式的名稱就可以表達很多信息，這樣可以大大節約設計的時間，提高溝通的效率。筆者身邊很多程序員的記憶力非常好，很擅長調試程序，但是讓他們描述自己的設計，他們卻會感覺很困難。這時如果使用設計模式語言，就可以大大改善這種狀況。設計模式語言可以讓開發者之間的溝通更順暢，讓設計資料的思路更清晰。

本書的構成

在本書中提到的設計模式都是面向對象領域耳熟能詳的內容，為了讓讀者更好地理解這些內容，本書通過如下方式對其進行說明。

1．問題說明

本書力爭通過PyExecutor中的實例，使讀者理解設計模式想要解決的問題。問題說明部分的內容可以看作設計模式的運用場景，而理解場景和設計模式的關系正是選擇和運用設計模式的關鍵。當然，設計模式的運用場景并不限于問題說明中的實例，這一點請讀者務必理解。

2．模式結構

設計模式是若干類協同完成復雜功能的方式，模式結構用來說明設計模式中每個類的職責、分工，以及類與類之間是如何協同工作的。讀者通過閱讀這部分內容，可以對設計模式有一個大致理解。模式結構重點說明的是設計模式的靜態信息，其動態信息可以結合示例代碼進行理解。

3．示例代碼

為了讓讀者對模式結構中的內容加深理解，示例代碼會提供可以執行的代碼。代碼的內容可能是模式結構的簡單實現，也可能會結合一個簡單的示例，總之不會離設計模式本身的內容太遠。所有代碼都是可以執行的，讀者最好在自己的電腦上輸入并調試這些代碼，這樣可以加深對設計模式的理解，因為很多東西只有在程序運行時才能看出來。

4．實戰運用

示例軟件PyExecutor包含了書中介紹的23個設計模式。如果原封不動地照搬設計模式，是無法獲得理想的結果的。無論是設計模式本身，還是運用設計模式的對象，都需要根據實際情況進行相應調整，實戰運用中的內容就是這方面的示例。由于PyExecutor的規模比較大，所以本書不會展示其所有代碼，讀者最好通過下載鏈接獲得代碼，再結合書中的說明，邊調試邊理解代碼。

5．效果討論

效果討論主要用來說明使用設計模式可以解決的問題，以及設計模式為軟件帶來的優勢。通過對示例的說明，讀者已經對設計模式有了自己的認識，這時再去理解設計模式，可以達到事半功倍的效果。

6．提示和技巧

任何事物都不可能只有優點沒有缺點，設計模式也是如此。提示和技巧一方面會說明使用設計模式的注意事項，另一方面也會提供一些深入運用設計模式的建議。

閱讀本書的幾點建議

設計模式多種多樣，其本質就是對需要替換的、變更的內容進行抽象處理，然后再運用多態技術對功能進行擴展，簡單地講就是，想變什么就抽象什么，這應該是學習和理解設計模式的最重要的9個字了。

在學習設計模式時經常遇到的一個問題就是，很多設計模式的類圖都很相似，在實際運用時不知道應該選擇哪一個。出現這個問題的最大原因就是將類圖當成選擇設計模式的依據了。由于面向對象設計唯一的“大招”就是多態，所以很多設計模式的構造看起來或多或少都有些相似。比較合理的步驟是先根據場景選擇設計模式，然后根據設計模式構造（形式）調整類的職責、接口和協作關系。

有些開發者反對設計模式的一個原因就是，使用設計模式容易出現過度設計。關于這個問題，筆者的觀點是：過度設計當然不好，但是這并不是設計模式的錯，而是開發者的問題。這和難以理解的接口、混亂的代碼是同樣的問題。為避免過度設計就不花時間和精力使用設計模式進行設計，就有點因噎廢食了。

關于類圖

本書中的類圖都是按照UML規范繪制的，但是考慮到不是所有讀者都掌握了UML知識，所以這里對其進行簡單說明。

圖0-1中的每個方框均代表一個類，這個類被橫線分為上下兩部分：橫線上面是該類的類名，橫線下面是該類的多態操作（斜體）或方法（正體）。UML類圖也有分為上、中、下三部分的情況，這時中間的區域顯示的是類的屬性。

圖0-1中的帶箭頭的虛線表現的是依賴關系，在大多數情況下它表明一個類會使用另一個類的功能。圖0-1中Director類指向Builder類的依賴關系表明Director類會使用Builder類的功能。

圖0-1中帶空心三角形的有向虛線表現的是實現關系，這種關系的含義是一個類可以實現另一個類定義的接口。例如，圖0-1中ConcreteBuilder1類指向Builder類的實現關系，表示ConcreteBuilder1類會實現Builder類定義的接口。但是Python語言比較特別的一點是：具象Builder不一定需要一個具體的抽象Builder類，只要實現者、利用者遵守相同的約定，即可實現利用者和提供者之間的調用關系。這種情況在Python語言中有一個定義—— protocol。對于這種可選的抽象基類，本書會指定一個<<protocol>>衍型來表明這種關系。

除此之外，本書還用到了繼承關系，它表現為帶空心三角形的實線，這種關系在UML中被稱為泛化，在圖0-2中Leaf類指向Component類的關系就屬于這種情況。這種情況也可以說Leaf類是Component類的派生類。

類之間的實線表示這兩個類之間存在關聯關系，即這兩個類需要協同工作。圖0-2中帶有一個箭頭的實線表明兩個類間的這種關聯關系是單向的，而沒有箭頭的實線表明兩個類間的這種關聯關系是雙向的。

圖0-2中一端為實心菱形的關聯關系表明整體和部分的關系，其中實心菱形端是整體。這種關系表明當整體消失時，部分也會隨著消失，這種關系被稱為組合關系。組合關系類似于筆記本電腦和屏幕的關系。部分和整體的關系也有用空心菱形表示的，雖然其含義和組合關系的含義相似，但是整體和部分可以單獨存在，這種關系被稱為聚合關系。聚合關系類似于臺式電腦和顯示器的關系。

程序員的語言

將自己寫的代碼公開需要很大的勇氣，有很多程序員甚至不敢在自己寫出的代碼上簽名。在本書中使用的PyExecutor是筆者為了說明設計模式而開發的一個模擬項目，由于時間和能力的限制，書中的代碼只寫到能將設計模式講清楚的程度，離真正的產品還有很遠的距離。如果讀者希望將這些代碼運用到自己的工作中，那么還需要對其進行完善和改進。書中關于設計模式、Python語言和tkinter庫的用法也有不足之處，懇請各位讀者批評指正。

致謝

感謝電子工業出版社的林瑞和編輯。本書從立意、結構的確定到內容的確認和整理，每個環節都得到了林編輯的建議和意見。毫不夸張地說，如果沒有林編輯的努力，就不會有本書的面世。

感謝我的父母。他們兩個人都沒有讀過什么書，但是他們不遺余力地培養孩子讀書，時至今日，我們兄弟幾人雖說沒有出人頭地，但做到了自食其力。

感謝我的夫人。夫人本來也是一個學霸，自結婚以后，她將大部分時間都花在家庭、孩子上，但是她一直無怨無悔。

感謝我的兩個孩子。孩子們為這個家庭帶來了活力，他們在自己成長的同時也見證了父母的成長。在本書寫作過程中，他們也做出了自己的貢獻。目前兩個孩子都處在成長的重要階段，在此希望我可以為他們樹立榜樣。

薛衛國

【讀者服務】

微信掃碼回復：37959

●獲取本書配套代碼資源

●獲取博文視點學院20元付費內容抵扣券

●獲取更多技術專家分享視頻與學習資源

●加入讀者交流群，與更多讀者互動