基本信息
《JavaScript設計模式》·頁碼：250 頁
·出版日期：2009年
·ISBN：711519128X/9787115191281
·條形碼：9787115191281
·版本：1版
·裝幀：平裝
·開本：16
·中文：中文
·叢書名：圖靈程式設計叢書
內容簡介
《JavaScript設計模式》共有兩部分。第一部分給出了實現具體設計模式所需要的面向對象特性的基礎知識，主要包括接口、封裝和信息隱藏、繼承、單體模式等內容。第二部分則專注於各種具體的設計模式及其在JavaScript 語言中的套用，主要介紹了工廠模式、橋接模式、組合模式、門面模式等幾種常見的模式。為了讓每一章中的示例都儘可能地貼近實際套用，書中同時列舉了一些JavaScript 程式設計師最常見的任務，然後運用設計模式使其解決方案變得更模組化、更高效並且更易維護，其中較為理論化的例子則用於闡明某些要點。
《JavaScript設計模式》適合各層次的Web 前端開發人員閱讀和參考，也適合有C++/Java/C# 背景的伺服器端程式設計師學習。
作者簡介
Ross Harmes，資深Web程式設計師，有10多年編程經驗。現任Yahoo前端工程師。他是開源圖片部落格軟體Birch的開發者。Blog地址為Http：//tecrhfoolery.com。
Dustin Diaz，資深Web程式設計師，現任Google用戶界面工程師。新一代JavaScript框架DEDlChain（兼具jQuery和YUI的優勢）的開發者。他還是一位中長跑健將，800米跑曾經在全美國排名第13。擁有西班牙語學士學位。個人網站http：//dustindiaz.com。
媒體推薦
“本書道前人所未道，引導你從編寫代碼進化為設計代碼。書中絕大部分示例代碼都來自YUI等實戰項目，並進行了深入剖析。強烈推薦。”
——Nicholas C.Zakas，著名.JavaScript專家，Yarl00前端工程師，暢銷書《JavaScript高級程式設計》作者
“毫不誇張地說，這是我有生以來讀到的最好的一本JavaScript圖書。作者講授了大量獨門的專家經驗。”
——Mostafa Farghaly，埃及程式設計師
作品推薦
Web套用取代桌面程式的時代已經到來！作為Web前端的核心技術，JavaScript的重要性不言而喻，它有望成為下一代統治性程式語言。但由於業界長期的誤解和濫用，也有不少人仍然對此半信半疑。那么，JavaScript到底能否當此大任呢？
《JavaScript設計模式》中，Google和Yahoo公司的兩位資深Web專家對此給出了擲地有聲的肯定回答。作者針對常見的開發任務，從YUI等實戰代碼中取材，提供了專家級的解決方案，不僅透徹剖析了JavaScript扣的面向對象編程，而且深入探討了如何用JavaScript實現以前只在伺服器端套用的設計模式，如何根據實際場景選擇恰當的設計模式，開發出高質量的企業級代碼。《JavaScript設計模式》充分證明：JavaScript不僅毫不遜色於其他高級語言，已經是一種成熟且強大的面向對象語言，而且還擁有Java和C++等語言不具備的面向未來的特性，因此更加靈活、更富於表現力。
無論是前端工程師，還是伺服器端程式設計師，通過《JavaScript設計模式》都將使自己的JavaScript功力提升到前所未有的高度。
目錄
第一部分 面向對象的JavaScript
第1章 富有表現力的JavaScript
1.1 JavaScript的靈活性
1.2 弱類型語言
1.3 函式是一等對象
1.4 對象的易變性
1.5 繼承
1.6 JavaScript中的設計模式
1.7 小結
第2章 接口
2.1 什麼是接口
2.1.1 接口之利
2.1.2 接口之弊
2.2 其他面向對象語言處理接口的方式
2.3 在JavaScript中模仿接口
2.3.1 用注釋描述接口
2.3.2 用屬性檢查模仿接口
2.3.3 用鴨式辨型模仿接口
2.4 本書採用的接口實現方法
2.5 Interface類
2.5.1 Interface類的使用場合
2.5.2 Interface類的用法
2.5.3 示例：使用Interface類
2.6 依賴於接口的設計模式
2.7 小結
第3章 封裝和信息隱藏
3.1 信息隱藏原則
3.1.1 封裝與信息隱藏
3.1.2 接口扮演的角色
3.2 創建對象的基本模式
3.2.1 門戶大開型對象
3.2.2 用命名規範區別私用成員
3.2.3 作用域、嵌套函式和閉包
3.2.4 用閉包實現私用成員
3.3 更多高級對象創建模式
3.3.1 靜態方法和屬性
3.3.2 常量
3.3.3 單體和對象工廠
3.4 封裝之利
3.5 封裝之弊
3.6 小結
第4章 繼承
4.1 為什麼需要繼承
4.2 類式繼承
4.2.1 原型鏈
4.2.2 extend函式
4.3 原型式繼承
4.3.1 對繼承而來的成員的讀和寫的不對等性
4.3.2 clone函式
4.4 類式繼承和原型式繼承的對比
4.5 繼承與封裝
4.6 摻元類
4.7 示例：就地編輯
4.7.1 類式繼承解決方案
4.7.2 原型式繼承解決方案
4.7.3 摻元類解決方案
4.8 繼承的適用場合
4.9 小結
第5章 單體模式
5.1 單體的基本結構
5.2 劃分命名空間
5.3 用作特定網頁專用代碼的包裝器的單體
5.4 擁有私用成員的單體
5.4.1 使用下劃線表示法
5.4.2 使用閉包
5.4.3 兩種技術的比較
5.5 惰性實例化
5.6 分支
5.7 示例：用分支技術創建XHR對象
5.8 單體模式的適用場合
5.9 單體模式之利
5.10 單體模式之弊
5.11 小結
第6章 方法的鏈式調用
6.1 調用鏈的結構
6.2 設計一個支持方法鏈式調用的JavaScript庫
6.3 使用回調從支持鏈式調用的方法獲取數據
6.4 小結
第二部分 設計模式
第7章 工廠模式
7.1 簡單工廠
7.2 工廠模式
7.3 工廠模式的適用場合
7.3.1 動態實現
7.3.2 節省設定開銷
7.3.3 用許多小型對象組成一個大對象
7.4 示例：XHR工廠
7.4.1 專用型連線對象
7.4.2 在運行時選擇連線對象
7.5 示例：RSS閱讀器
7.6 工廠模式之利
7.7 工廠模式之弊
7.8 小結
第8章 橋接模式
8.1 示例：事件監聽器
8.2 橋接模式的其他例子
8.3 用橋接模式聯結多個類
8.4 示例：構建XHR連線佇列
8.4.1 添加核心工具
8.4.2 添加觀察者系統
8.4.3 開發佇列的基本框架
8.4.4 實現佇列
8.4.5 哪些地方用了橋接模式
8.5 橋接模式的適用場合
8.6 橋接模式之利
8.7 橋接模式之弊
8.8 小結
第9章 組合模式
9.1 組合對象的結構
9.2 使用組合模式
9.3 示例：表單驗證
9.3.1 匯合起來
9.3.2 向FormItem添加操作
9.3.3 向層次體系中添加類
9.3.4 添加更多操作
9.4 示例：圖片庫
9.5 組合模式之利
9.6 組合模式之弊
9.7 小結
第10章 門面模式
10.1 一些你可能已經知道的門面元素
10.2 JavaScript庫的門面性質
10.3 用作便利方法的門面元素
10.4 示例：設定HTML元素的樣式
10.5 示例：設計一個事件工具
10.6 實現門面模式的一般步驟
10.7 門面模式的適用場合
10.8 門面模式之利
10.9 門面模式之弊
10.10 小結
第11章 適配器模式
11.1 適配器的特點
11.2 適配原有實現
11.3 示例：適配兩個庫
11.4 示例：適配電子郵件API
11.4.1 用適配器包裝Web郵件API
11.4.2 從fooMail轉向dedMail
11.5 適配器模式的適用場合
11.6 適配器模式之利
11.7 適配器模式之弊
11.8 小結
第12章 裝飾者模式
12.1 裝飾者的結構
12.1.1 接口在裝飾者模式中的角色
12.1.2 裝飾者模式與組合模式的比較
12.2 裝飾者修改其組件的方式
12.2.1 在方法之後添加行為
12.2.2 在方法之前添加行為
12.2.3 替換方法
12.2.4 添加新方法
12.3 工廠的角色
12.4 函式裝飾者
12.5 裝飾者模式的適用場合
12.6 示例：方法性能分析器
12.7 裝飾者模式之利
12.8 裝飾者模式之弊
12.9 小結
第13章 享元模式
13.1 享元的結構
13.2 示例：汽車登記
13.2.1 內在狀態和外在狀態
13.2.2 用工廠進行實例化
13.2.3 封裝在管理器中的外在狀態
13.3 管理外在狀態
13.4 示例：Web日曆
13.4.1 把日期對象轉化為享元
13.4.2 外在數據保存在哪裡
13.5 示例：工具提示對象
13.5.1 未經最佳化的Tooltip類
13.5.2 作為享元的Tooltip
13.6 保存實例供以後重用
13.7 享元模式的適用場合
13.8 實現享元模式的一般步驟
13.9 享元模式之利
13.10 享元模式之弊
13.11 小結
第14章 代理模式
14.1 代理的結構
14.1.1 代理如何控制對本體的訪問
14.1.2 虛擬代理、遠程代理和保護代理
14.1.3 代理模式與裝飾者模式的比較
14.2 代理模式的適用場合
14.3 示例：網頁統計
14.4 包裝Web服務的通用模式
14.5 示例：目錄查找
14.6 創建虛擬代理的通用模式
14.7 代理模式之利
14.8 代理模式之弊
14.9 小結
第15章 觀察者模式
15.1 示例：報紙的投送
15.1.1 推與拉的比較
15.1.2 模式的實踐
15.2 構建觀察者API
15.2.1 投送方法
15.2.2 訂閱方法
15.2.3 退訂方法
15.3 現實生活中的觀察者
15.4 示例：動畫
15.5 事件監聽器也是觀察者
15.6 觀察者模式的適用場合
15.7 觀察者模式之利
15.8 觀察者模式之弊
15.9 小結
第16章 命令模式
16.1 命令的結構
16.1.1 用閉包創建命令對象
16.1.2 客戶、調用者和接收者
16.1.3 在命令模式中使用接口
16.2 命令對象的類型
16.3 示例：選單項
16.3.1 選單組合對象
16.3.2 命令類
16.3.3 匯合起來
16.3.4 添加更多選單項
16.4 示例：取消操作和命令日誌
16.4.1 使用命令日誌實現不可逆操作的取消
16.4.2 用於崩潰恢復的命令日誌
16.5 命令模式的適用場合
16.6 命令模式之利
16.7 命令模式之弊
16.8 小結
第17章 職責鏈模式
17.1 職責鏈的結構
17.2 傳遞請求
17.3 在現有層次體系中實現職責鏈
17.4 事件委託
17.5 職責鏈模式的適用場合
17.6 圖片庫的進一步討論
17.6.1 用職責鏈提高組合對象的效率
17.6.2 為圖片添加標籤
17.7 職責鏈模式之利
17.8 職責鏈模式之弊
17.9 小結
索引
……
序言摘引
設計模式對於程式設計師來說並不是一個陌生話題。在Erich Gamma等人合著的經典著作《設計模式》出版之後，十幾年間陸續出現了許多這方面的專著。不過它們大都結合Java和C++等傳統的面向對象語言進行講解，而講述設計模式在動態語言中的實現的書則較為罕見。在早期的JavaScript編程實踐中，這種語言只被用於做點為網頁塗脂抹粉的小差事；程式的規模很小，也很簡單。那個時候恐怕沒有人會想到把設計模式用到這種“玩具語言”編寫的程式中。隨著Ajax技術的興起，Web）套用的許多邏輯都從伺服器端轉移到客戶端執行，客戶端JavaScript程式的作用越來越重要，其規模和複雜程度也越來越大，人們也越來越多地把面向對象方法套用到JavaScript程式設計中。在此背景下，有許多人開始研究設計模式在JavaScript程式設計中的套用，網上也陸續出現了一些關於這個話題的零星討論。但是到目前為止，系統地探討面向對象的程式設計模式在JavaScript語言中的實現的書，只此一本。（Michael Mahemof所著的《Ajax設計模式》一書總結的是運用Aiax技術開發Web套用的各種設計模式，雖然也涉及大量JavaScript編程，但它與本書關注的焦點不同。本書討論的是一些通用的面向對象設計模式在JavaScript中的實現，屬於更基礎性的東西，它們不僅僅適用於Web客戶端編程。）
JavaScript這種語言與Java等傳統的面向對象語言有很大的不同。它的動態性、詞法作用域和基於原型的繼承機制等特點可能會讓很多初次接觸它的程式設計師都有點不習慣，而且由於語言設計上的一些不完善，許多在傳統面向對象語言中只是舉手之勞的事在JavaScript卻不得不依靠hack手法來實現。這也許就是那些已經熟知設計模式在Java等語言中實現方式的程式設計師也需要本書的原因。本書第一部分著重講述了面向對象技術在JavaScript中的實現方法。這對於對JavaScript只有過初步了解的人非常有用（當然，本書不適合對JavaScript一竅不通的讀者。他們應該先找一本,JavaScript基礎教材來看看，比如人民郵電出版社出版的《JavaScript基礎教程》）。Java和C++編程老手們在學完這部分內容之後，想必應該能夠在JavaScript程式設計中自行套用各種經典的設計模式了。不過不同的人可能會有一些不同的做法，因此繼續看看本書第二部分，借鑑一下作者的方法也不無益處。對於那些從未學過設計模式的JavaScript程式設計師來說，本書的重要性更是毋庸置疑。不過，坦率地說，要想深入學習設計模式僅看本書是不夠的。取代Gamma等人的《設計模式》並不是本書的目標。
內容選摘
在事件驅動的環境中，比如瀏覽器這種持續尋求用戶關注的環境中，觀察者模式〔又名發布者—訂閱者（publisher-subscriber）模式〕是一種管理人與其任務之間的關係（確切地講，是對象及其行為和狀態之間的關係）的得力工具。用JavaScript的話來說，這種模式的實質就是你可以對程式中某個對象的狀態進行觀察，並且在其發生改變時能夠得到通知。
觀察者模式中存在兩個角色：觀察者和被觀察者。本書一般傾向於稱其為發布者和訂閱者。這種模式在JavaScript中有幾種不同的實現方式，本章將對其中的一些實現方式進行考察。不過我們首先要說明一下發布者和訂閱者這兩種角色。下一節的例子以報業為例說明了觀察者模式的工作方式。
15.1 示例：報紙的投送
在報紙行業中，發行和訂閱的順利進行有賴於一些關鍵性的角色和行為。首先是讀者。他們都是訂閱者（subscriber），是與你我一樣的人。我們消費數據並且根據讀到的訊息做出反應。我們可以選擇自己的居住地點，讓報社把報紙送到自己家中。這個活動中的另一個角色是發行方（publisher）。他們負責出版諸如San Francisco Chronicle、New York Times和Sacramento Bee這樣的報紙。
確定了各方的身份之後，我們就可以分析每一方的職責所在。作為報紙的訂閱者，我們有一些事要做。數據到來的時候我們收到通知。我們消費數據。然後我們根據數據做出反應。只要報紙到了訂閱者手中，他們就可以自行處置。有些人讀完之後會將其扔在一邊，有些人會向朋友或家人轉述其中的新聞，甚至還有一些人會把報紙送回去。總而言之，訂閱者要從發行方接收數據。
發行方則要傳送數據。在本例中，發行方也是投送方（deliver）。一般說來，一個發行方很可能有許多訂閱者，同樣，一個訂閱者也很可能會訂閱多家報社的報紙。問題的關鍵在於，這是一種多對多的關係，需要一種高級的抽象策略，以便訂閱者能夠彼此獨立地發生改變，而發行方能夠接受任何有消費意向的訂閱者。
15.1.1 推與拉的比較
對於報社來說，只為給幾個訂閱者投送報紙就滿世界跑是不划算的。而紐約市的居民也不可能特意飛到舊金山去拿自己訂的San Francisco Chronicle，要知道這份報紙可以直接投送到他們家門口。
訂閱者要想拿到報紙的話有兩種投送方式可選：推或拉。在推環境中，發行方很可能會僱傭投送人員四處送報。換句話說，他們把自己的報紙推出去，讓訂閱者收取。在拉環境中，規模較小的本地報社可能會在訂閱者家附近的街角提供自己的數據，
……
