　　設計模式是軟件設計中經過瞭大量實際項目驗證的可復用的優秀解決方案，它有助於程序員寫齣可復用和可維護性高的程序。許多優秀的JavaScript開源框架都運用瞭不少設計模式，越來越多的程序員從設計模式中獲益，也許是改善瞭自己編寫的某個軟件，也許是更好地理解瞭麵嚮對象的編程思想。無論如何，係統地學習設計模式都會令你受益匪淺。

內容簡介

　　《JavaScript設計模式與開發實踐》在尊重《設計模式》原意的同時，針對JavaScript語言特性全麵介紹瞭更適閤JavaScript程序員的瞭16個常用的設計模式，講解瞭JavaScript麵嚮對象和函數式編程方麵的基礎知識，介紹瞭麵嚮對象的設計原則及其在設計模式中的體現，還分享瞭麵嚮對象編程技巧和日常開發中的代碼重構。《JavaScript設計模式與開發實踐》將教會你如何把經典的設計模式應用到JavaScript語言中，編寫齣優美高效、結構化和可維護的代碼。
　　

作者簡介

　　曾探，2007年畢業於吉林大學軟件學院。就職於國內知名前端團隊騰訊AlloyTeam，高級工程師。曾參與WebQQ、QQ群、Q+開發者網站、微雲、QQ興趣部落等大型前端項目的開發。有過Java、Python和JavaScript的開發經驗，業餘作品有HTML5版街頭霸王等。平時喜歡電影和音樂，業餘時間也是一名健身教練。

內頁插圖

精彩書評

　　★“深入淺齣，講解得很好!”
　　——starj3221
　　
　　★“看瞭樣章，很不錯！有點迫不及待地想看全書瞭！”
　　——天纔少年
　　
　　★“這本書由淺入深，講解得很細緻，對學習JavaScript很有幫助。”
　　　　——於濤，騰訊AlloyTeam負責人
　　
　　★“內容淺顯易懂，覆蓋範圍全麵，對部分常用的模式有深入的剖析。”
　　　　——林挺，微眾銀行前端工程師
　　

第一部分　基礎知識
第1章　麵嚮對象的JavaScript
1.1 動態類型語言和鴨子類型
1.2 多態
1.3 封裝
1.4 原型模式和基於原型繼承的JavaScript對象係統
第2章　this、call和apply
2.1 this
2.2 call和apply
第3章　閉包和高階函數
3.1 閉包
3.2 高階函數
3.3 小結
第二部分設計模式
第4章　單例模式
4.1 實現單例模式
4.2 透明的單例模式
4.3 用代理實現單例模式
4.4 JavaScript中的單例模式
4.5 惰性單例
4.6 通用的惰性單例
4.7 小結
第5章　策略模式
5.1 使用策略模式計算奬金
5.2 JavaScript 版本的策略模式
5.3 多態在策略模式中的體現
5.4 使用策略模式實現緩動動畫
5.5 更廣義的"算法"
5.6 錶單校驗
5.7 策略模式的優缺點
5.8 一等函數對象與策略模式
5.9 小結
第6章　代理模式
6.1 第一個例子--小明追MM的故事
6.2 保護代理和虛擬代理
6.3 虛擬代理實現圖片預加載
6.4 代理的意義
6.5 代理和本體接口的一緻性
6.6 虛擬代理閤並HTTP 請求
6.7 虛擬代理在惰性加載中的應用
6.8 緩存代理
6.9 用高階函數動態創建代理
6.10 其他代理模式
6.11 小結
第7章　迭代器模式
7.1 jQuery 中的迭代器
7.2 實現自己的迭代器
7.3 內部迭代器和外部迭代器
7.4 迭代類數組對象和字麵量對象
7.5 倒序迭代器
7.6 中止迭代器
7.7 迭代器模式的應用舉例
7.8 小結
第8章　發布-訂閱模式
8.1 現實中的發布-訂閱模式
8.2 發布-訂閱模式的作用
8.3 DOM 事件
8.4 自定義事件
8.5 發布-訂閱模式的通用實現
8.6 取消訂閱的事件
8.7 真實的例子--網站登錄
8.8 全局的發布-訂閱對象
8.9 模塊間通信
8.10 必須先訂閱再發布嗎
8.11 全局事件的命名衝突
8.12 JavaScript實現發布-訂閱模式的便利性
8.13 小結
第9章　命令模式
9.1 命令模式的用途
9.2 命令模式的例子--菜單程序
9.3 JavaScript中的命令模式
9.4 撤銷命令
9.5 撤消和重做
9.6 命令隊列
9.7 宏命令
9.8 智能命令與傻瓜命令
9.9 小結
第10章　組閤模式
10.1 迴顧宏命令
10.2 組閤模式的用途
10.3 請求在樹中傳遞的過程
10.4 更強大的宏命令
10.5 抽象類在組閤模式中的作用
10.6 透明性帶來的安全問題
10.7 組閤模式的例子--掃描文件夾
10.8 一些值得注意的地方
10.9 引用父對象
10.10 何時使用組閤模式
10.11 小結
第11章　模闆方法模式
11.1 模闆方法模式的定義和組成
11.2 第一個例子--Coffee or Tea
11.3 抽象類
11.4 模闆方法模式的使用場景
11.5 鈎子方法
11.6 好萊塢原則
11.7 真的需要"繼承"嗎
11.8 小結
第12章　享元模式
12.1 初識享元模式
12.2 內部狀態與外部狀態
12.3 享元模式的通用結構
12.4 文件上傳的例子
12.5 享元模式的適用性
12.6 再談內部狀態和外部狀態
12.7 對象池
12.8 小結
第13章　職責鏈模式
13.1 現實中的職責鏈模式
13.2 實際開發中的職責鏈模式
13.3 用職責鏈模式重構代碼
13.4 靈活可拆分的職責鏈節點
13.5 異步的職責鏈
13.6 職責鏈模式的優缺點
13.7 用AOP 實現職責鏈
13.8 用職責鏈模式獲取文件上傳對象
13.9 小結
第14章　中介者模式
14.1 現實中的中介者
14.2 中介者模式的例子--泡泡堂遊戲
14.3 中介者模式的例子--購買商品
14.4 小結
第15章　裝飾者模式
15.1 模擬傳統麵嚮對象語言的裝飾者模式
15.2 裝飾者也是包裝器
15.3 迴到JavaScript 的裝飾者
15.4 裝飾函數
15.5 用AOP 裝飾函數
15.6 AOP 的應用實例
15.7 裝飾者模式和代理模式
15.8 小結
第16章　狀態模式
16.1 初識狀態模式
16.2 狀態模式的定義
16.3 狀態模式的通用結構
16.4 缺少抽象類的變通方式
16.5 另一個狀態模式示例--文件上傳
16.6 狀態模式的優缺點
16.7 狀態模式中的性能優化點
16.8 狀態模式和策略模式的關係
16.9 JavaScript版本的狀態機
16.10 錶驅動的有限狀態機
16.11 實際項目中的其他狀態機
16.12 小結
第17章　適配器模式
17.1 現實中的適配器
17.2 適配器模式的應用
17.3 小結
第三部分設計原則和編程技巧
第18章　單一職責原則
18.1 設計模式中的SRP原則
18.2 何時應該分離職責
18.3 違反SRP原則
18.4 SRP 原則的優缺點
第19章　最少知識原則
19.1 減少對象之間的聯係
19.2 設計模式中的LKP原則
19.3 封裝在LKP 原則中的體現
第20章　開放-封閉原則
20.1 擴展window.onload函數
20.2 開放和封閉
20.3 用對象的多態性消除條件分支
20.4 找齣變化的地方
20.5 設計模式中的開放-封閉原則
20.6 開放-封閉原則的相對性
20.7 接受第一次愚弄
第21章　接口和麵嚮接口編程
21.1 迴到Java的抽象類
21.2 interface
21.3 JavaScript 語言是否需要抽象類和interface
21.4 用鴨子類型進行接口檢查
21.5 用TypeScript 編寫基於interface的命令模式
第22章　代碼重構
22.1 提煉函數
22.2 閤並重復的條件片段
22.3 把條件分支語句提煉成函數
22.4 閤理使用循環
22.5 提前讓函數退齣代替嵌套條件分支
22.6 傳遞對象參數代替過長的參數列錶
22.7 盡量減少參數數量
22.8 少用三目運算符
22.9 閤理使用鏈式調用
22.10 分解大型類
22.11 用return退齣多重循環
參考文獻

前言/序言

　　《設計模式》一書自1995年成書一來，一直是程序員談論的“高端”話題之一。許多程序員從設計模式中學到瞭設計軟件的靈感，或者找到瞭問題的解決方案。在社區中，既有人對模式無比崇拜，也有人對模式充滿誤解。有些程序員把設計模式視為聖經，唯模式至上；有些人卻認為設計模式隻在C++或者Java中有用武之地，JavaScript這種動態語言根本就沒有設計模式一說。
　　那麼，在進入設計模式的學習之前，我們最好還是從模式的起源說起，分彆聽聽這些不同的聲音。
　　設計模式並非是軟件開發的專業術語。實際上，“模式”最早誕生於建築學。20世紀70年代，哈佛大學建築學博士Christopher Alexander和他的研究團隊花瞭約20年的時間，研究瞭為解決同一個問題而設計齣的不同建築結構，從中發現瞭那些高質量設計中的相似性，並且用“模式”來指代這種相似性。
　　受Christopher Alexander工作的啓發，Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四人（人稱Gang Of Four ，GoF）把這種“模式”觀點應用於麵嚮對象的軟件設計中，並且總結瞭23種常見的軟件開發設計模式，錄入《設計模式：可復用麵嚮對象軟件的基礎》一書。
　　設計模式的定義是：在麵嚮對象軟件設計過程中針對特定問題的簡潔而優雅的解決方案。
　　通俗一點說，設計模式是在某種場閤下對某個問題的一種解決方案。如果再通俗一點說，設計模式就是給麵嚮對象軟件開發中的一些好的設計取個名字。
　　GoF成員之一 John Vlissides在他的另一本關於設計模式的著作《設計模式沉思錄》中寫過這樣一段話：
　　設想有一個電子愛好者，雖然他沒有經過正規的培訓，但是卻日積月纍地設計並製造齣許多有用的電子設備：業餘無綫電、蓋革計數器、報警器等。有一天這個愛好者決定重新迴到學校去攻讀電子學學位，來讓自己的纔能得到真實的認可。隨著課程的展開，這個愛好者突然發現課程內容都似曾相識。似曾相識的並不是術語或者錶述的方式，而是背後的概念。這個愛好者不斷學到一些名稱和原理，雖然這些名稱和原理原來他不知道，但事實上他多年來一直都在使用。整個過程隻不過是一個接一個的頓悟。
　　軟件開發中的設計也是如此。這些“好的設計”並不是GoF發明的，而是早已存在於軟件開發中。一個稍有經驗的程序員也許在不知不覺中數次使用過這些設計模式。GoF最大的功績是把這些“好的設計”從浩瀚的麵嚮對象世界中挑選齣來，並且給予它們一個好聽又好記的名字。
　　那麼，給模式一個名字有什麼意義呢？上述故事中的電子愛好者在未進入學校之前，一點都不知道這些關於電器的概念有一些特定的名稱，但這不妨礙他製造齣一些電子設備。
　　實際上給“模式”取名的意義非常重要。人類可以走到生物鏈頂端的前兩個原因分彆是會“使用名字”和“使用工具”。在軟件設計中，一個好的設計方案有瞭名字之後，纔能被更好地傳播，人們纔有更多的機會去分享和學習它們。
　　也許這個小故事可以說明名字對於模式的重要性：假設你是一名足球教練，正在球場邊指揮一場足球賽。通過一段時間的觀察後，發現對方的後衛技術精湛，身體強壯，但邊後衛速度較慢，中後衛身高和頭球都非常一般。於是你在場邊大聲指揮隊員：“用速度突破對方邊後衛之後，往球門方嚮踢齣高球，中路接應隊員搶點頭球攻門。”
　　在機會稍縱即逝的足球場上，教練這樣費盡口舌地指揮隊員比賽無疑是荒謬的。實際上這種戰術有一個名字叫作“下底傳中”。正因為戰術有瞭對應的名字，在球場上教練可以很方便地和球員交流。“下底傳中”這種戰術即是足球場上的一種“模式”。
　　在軟件設計中亦是如此。我們都知道設計經驗非常重要。也許我們都有過這種感覺：這個問題發生的場景似曾相識，以前我遇到並解決過這個問題，但是我不知道怎麼跟彆人去描述它。我們非常希望給這個問題齣現的場景和解決方案取一個統一的名字，當彆人聽到這個名字的時候，便知道我想錶達什麼。比如一個JavaScript新手今天學會瞭編寫each函數，each函數用來迭代一個數組。他很難想到這個each函數其實就是迭代器模式。於是他嚮彆人描述這個函數結構和意圖的時候會遇到睏難，而一旦大傢對迭代器模式這個名字達成瞭共識，剩下的交流便是自然而然的事情。
　　學習模式的作用
　　小說傢很少從頭開始設計劇情，足球教練也很少從頭開始發明戰術，他們總是沿襲一些已經存在的模式。當足球教練看到對方邊後衛速度慢，中後衛身高矮時，自然會想到“下底傳中”這種模式。
　　同樣，在軟件設計中，模式是一些經過瞭大量實際項目驗證的優秀解決方案。熟悉這些模式的程序員，對某些模式的理解也許形成瞭條件反射。當閤適的場景齣現時，他們可以很快地找到某種模式作為解決方案。
　　比如，當他們看到係統中存在一些大量的相似對象，這些對象給係統的內存帶來瞭較大的負擔。如果他們熟悉享元模式，那麼第一時間就可以想到用享元模式來優化這個係統。再比如，係統中某個接口的結構已經不能符閤目前的需求，但他們又不想去改動這個被灰塵遮住的老接口，一個熟悉模式的程序員將很快地找到適配器模式來解決這個問題。
　　如果我們還沒有學習全部的模式，當遇到一個問題時，我們冥冥之中覺得這個問題齣現的幾率很高，說不定彆人也遇到過同樣的問題，並且已經把它整理成瞭模式，提供瞭一種通用的解決方案。這時候去翻翻《設計模式》這本書也許就會有意外的收獲。
　　模式在不同語言之間的區彆
　　《設計模式》一書的副標題是“可復用麵嚮對象軟件的基礎”。《設計模式》這本書完全是從麵嚮對象設計的角度齣發的，通過對封裝、繼承、多態、組閤等技術的反復使用，提煉齣一些可重復使用的麵嚮對象設計技巧。所以有一種說法是設計模式僅僅是就麵嚮對象的語言而言的。
　　《設計模式》最初講的確實是靜態類型語言中的設計模式，原書大部分代碼由C++寫成，但設計模式實際上是解決某些問題的一種思想，與具體使用的語言無關。模式社區和語言一直都在發展，如今，除瞭主流的麵嚮對象語言，函數式語言的發展也非常迅猛。在函數式或者其他編程範型的語言中，設計模式依然存在。
　　人類飛上天空需要藉助飛機等工具，而鳥兒天生就有翅膀。在Dota遊戲裏，牛頭人的人生目標是買一把跳刀（跳刀可以使用跳躍技能），而敵法師天生就有跳躍技能。因為語言的不同，一些設計模式在另外一些語言中的實現也許跟我們在《設計模式》一書中看到的大相徑庭，這一點也不令人意外。
　　Google的研究總監Peter Norvig早在1996年一篇名為“動態語言設計模式”的演講中，就指齣瞭GoF所提齣的23種設計模式，其中有16種在Lisp語言中已經是天然的實現。比如，Command模式在Java中需要一個命令類，一個接收者類，一個調用者類。Command模式把運算塊封裝在命令對象的方法內，成為該對象的行為，並把命令對象四處傳遞。但在Lisp或者JavaScript這些把函數當作一等對象的語言中，函數便能封裝運算塊，並且函數可以被當成對象一樣四處傳遞，這樣一來，命令模式在Lisp或者JavaScript中就成為瞭一種隱形的模式。
　　在Java這種靜態編譯型語言中，無法動態地給已存在的對象添加職責，所以一般通過包裝類的方式來實現裝飾者模式。但在JavaScript這種動態解釋型語言中，給對象動態添加職責是再簡單不過的事情。這就造成瞭JavaScript語言的裝飾者模式不再關注於給對象動態添加職責，而是關注於給函數動態添加職責。
　　設計模式的適用性
　　設計模式被一些人認為隻是誇誇其談的東西，這些人認為設計模式並沒有多大用途。畢竟我們用普通的方法就能解決的問題，使用設計模式可能會增加復雜度，或帶來一些額外的代碼。如果對一些設計模式使用不當，事情還可能變得更糟。
　　從某些角度來看，設計模式確實有可能帶來代碼量的增加，或許也會把係統的邏輯搞得更復雜。但軟件開發的成本並非全部在開發階段，設計模式的作用是讓人們寫齣可復用和可維護性高的程序。假設有一個空房間，我們要日復一日地往裏麵放一些東西。最簡單的辦法當然是把這些東西直接扔進去，但是時間久瞭，就會發現很難從這個房子裏找到自己想要的東西，要調整某幾樣東西的位置也不容易。所以在房間裏做一些櫃子也許是個更好的選擇，雖然櫃子會增加我們的成本，但它可以在維護階段為我們帶來好處。使用這些櫃子存放東西的規則，或許就是一種模式。
　　所有設計模式的實現都遵循一條原則，即“找齣程序中變化的地方，並將變化封裝起來”。一個程序的設計總是可以分為可變的部分和不變的部分。當我們找齣可變的部分，並且把這些部分封裝起來，那麼剩下的就是不變和穩定的部分。這些不變和穩定的部分是非常容易復用的。這也是設計模式為什麼描寫的是可復用麵嚮對象軟件基礎的原因。
　　設計模式被人誤解的一個重要原因是人們對它的誤用和濫用，比如將一些模式用在瞭錯誤的場景中，或者說在不該使用模式的地方刻意使用模式。特彆是初學者在剛學會使用一個模式時，恨不得把所有的代碼都用這個模式來實現。錘子理論在這裏體現得很明顯：當我們有瞭一把錘子，看什麼都是釘子。拿足球比賽的例子來說，我們的目標隻是進球，“下底傳中”這種“模式”僅僅是達到進球目標的一種手段。當我們麵臨密集防守時，下底傳中或許是一種好的選擇；但如果我們的球員獲得瞭一個直接麵對對方守門員的單刀機會，那麼是否還要把球先傳嚮邊路隊友，再由邊路隊友來一個邊路傳中呢？答案是顯而易見的，模式應該用在正確的地方。而哪些纔算正確的地方，隻有在我們深刻理解瞭模式的意圖之後，再結閤項目的實際場景纔會知道。
　　分辨模式的關鍵是意圖而不是結構
　　在設計模式的學習中，有人經常發齣這樣的疑問：代理模式和裝飾者模式，策略模式和狀態模式，策略模式和智能命令模式，這些模式的類圖看起來幾乎一模一樣，它們到底有什麼區彆？
　　實際上這種情況是普遍存在的，許多 JavaScript設計模式與開發實踐下載 mobi epub pdf txt 電子書

JavaScript設計模式與開發實踐 pdf epub mobi txt 電子書下載

想要找書就要到求知書站

tushu.tinynews.org

立刻按 ctrl+D收藏本頁

你會得到大驚喜!!