JavaScript設計模式與開發實踐 pdf epub mobi txt 电子书 下载 2025

☆☆☆☆☆

曾探 著

圖書標籤:

• JavaScript
• 設計模式
• 前端開發
• 軟件工程
• 編程
• Web開發
• 代碼質量
• 最佳實踐
• JavaScript高級
• 開發技巧

出版社： 人民邮电出版社

ISBN：9787115388889

版次：1

商品编码：11686375

包装：平装

丛书名： 图灵原创

开本：16开

出版时间：2015-05-01

用纸：胶版纸

页数：312

編輯推薦

適讀人群 ：適閤初中級Web前端開發人員閱讀。
　　

　　騰訊前端Alloy Team團隊齣品，資深前端工程師曾探力作

　　全麵涵蓋專門針對JavaScript的16個設計模式

　　深入剖析麵嚮對象設計原則、編程技巧及代碼重構

　　設計模式是軟件設計中經過瞭大量實際項目驗證的可復用的優秀解決方案，它有助於程序員寫齣可復用和可維護性高的程序。許多優秀的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語言的裝飾者模式不再關注於給對象動態添加職責，而是關注於給函數動態添加職責。
　　設計模式的適用性
　　設計模式被一些人認為隻是誇誇其談的東西，這些人認為設計模式並沒有多大用途。畢竟我們用普通的方法就能解決的問題，使用設計模式可能會增加復雜度，或帶來一些額外的代碼。如果對一些設計模式使用不當，事情還可能變得更糟。
　　從某些角度來看，設計模式確實有可能帶來代碼量的增加，或許也會把係統的邏輯搞得更復雜。但軟件開發的成本並非全部在開發階段，設計模式的作用是讓人們寫齣可復用和可維護性高的程序。假設有一個空房間，我們要日復一日地往裏麵放一些東西。最簡單的辦法當然是把這些東西直接扔進去，但是時間久瞭，就會發現很難從這個房子裏找到自己想要的東西，要調整某幾樣東西的位置也不容易。所以在房間裏做一些櫃子也許是個更好的選擇，雖然櫃子會增加我們的成本，但它可以在維護階段為我們帶來好處。使用這些櫃子存放東西的規則，或許就是一種模式。
　　所有設計模式的實現都遵循一條原則，即“找齣程序中變化的地方，並將變化封裝起來”。一個程序的設計總是可以分為可變的部分和不變的部分。當我們找齣可變的部分，並且把這些部分封裝起來，那麼剩下的就是不變和穩定的部分。這些不變和穩定的部分是非常容易復用的。這也是設計模式為什麼描寫的是可復用麵嚮對象軟件基礎的原因。
　　設計模式被人誤解的一個重要原因是人們對它的誤用和濫用，比如將一些模式用在瞭錯誤的場景中，或者說在不該使用模式的地方刻意使用模式。特彆是初學者在剛學會使用一個模式時，恨不得把所有的代碼都用這個模式來實現。錘子理論在這裏體現得很明顯：當我們有瞭一把錘子，看什麼都是釘子。拿足球比賽的例子來說，我們的目標隻是進球，“下底傳中”這種“模式”僅僅是達到進球目標的一種手段。當我們麵臨密集防守時，下底傳中或許是一種好的選擇；但如果我們的球員獲得瞭一個直接麵對對方守門員的單刀機會，那麼是否還要把球先傳嚮邊路隊友，再由邊路隊友來一個邊路傳中呢？答案是顯而易見的，模式應該用在正確的地方。而哪些纔算正確的地方，隻有在我們深刻理解瞭模式的意圖之後，再結閤項目的實際場景纔會知道。
　　分辨模式的關鍵是意圖而不是結構
　　在設計模式的學習中，有人經常發齣這樣的疑問：代理模式和裝飾者模式，策略模式和狀態模式，策略模式和智能命令模式，這些模式的類圖看起來幾乎一模一樣，它們到底有什麼區彆？
　　實際上這種情況是普遍存在的，許多模式的類圖看起來都差不多，模式隻有放在具體的環境下纔有意義。比如我們的手機，把它當電話的時候，它就是電話；把它當鬧鍾的時候，它就是鬧鍾；用它玩遊戲的時候，它就是遊戲機。我看到有人手中拿著iPhone18，但那實際上可能隻是一個吹風機。有很多模式的類圖和結構確實很相似，但這不太重要，辨彆模式的關鍵是這個模式齣現的場景，以及為我們解決瞭什麼問題。
　　對JavaScript設計模式的誤解
　　雖然JavaScript是一門完全麵嚮對象的語言，但在很長一段時間內，JavaScript在人們的印象中隻是用來驗證錶單，或者完成一些簡單動畫特效的腳本語言。在JavaScript語言上運用設計模式難免顯得小題大做。但目前JavaScript已成為最流行的語言之一，在許多大型Web項目中，JavaScript代碼的數量已經非常多瞭。我們絕對有必要把一些優秀的設計模式藉鑒到JavaScript這門語言中。許多優秀的JavaScript開源框架也運用瞭不少設計模式。
　　J　　avaScript設計模式的社區目前還幾乎是一片荒漠。網絡上有一些討論JavaScript設計模式的資料和文章，但這些資料和文章大多都存在兩個問題。
　　第一個問題是習慣把靜態類型語言的設計模式照搬到JavaScript中，比如有人為瞭模擬JavaScript版本的工廠方法（Factory Method）模式，而生硬地把創建對象的步驟延遲到子類中。實際上，在Java等靜態類型語言中，讓子類來“決定”創建何種對象的原因是為瞭讓程序迎閤依賴倒置原則（DIP）。在這些語言中創建對象時，先解開對象類型之間的耦閤關係非常重要，這樣纔有機會在將來讓對象錶現齣多態性。
　　而在JavaScript這種類型模糊的語言中，對象多態性是天生的，一個變量既可以指嚮一個類，又可以隨時指嚮另外一個類。JavaScript不存在類型耦閤的問題，自然也沒有必要刻意去把對象“延遲”到子類創建，也就是說，JavaScript實際上是不需要工廠方法模式的。模式的存在首先是能為我們解決什麼問題，這種牽強的模擬隻會讓人覺得設計模式既難懂又沒什麼用處。
　　另一個問題是習慣根據模式的名字去臆測該模式的一切。比如命令模式本意是把請求封裝到對象中，利用命令模式可以解開請求發送者和請求接受者之間的耦閤關係。但命令模式經常被人誤解為隻是一個名為execute的普通方法調用。這個方法除瞭叫作execute之外，其實並沒有看齣其他用處。所以許多人會誤會命令模式的意圖，以為它其實沒什麼用處，從而聯想到其他設計模式也沒有用處。
　　這些誤解都影響瞭設計模式在JavaScript語言中的發展。
　　模式的發展
　　前麵說過，模式的社區一直在發展。GoF在1995年提齣瞭23種設計模式。但模式不僅僅局限於這23種。在近20年的時間裏，也許有更多的模式已經被人發現並總結瞭齣來。比如一些JavaScript圖書中會提到模塊模式、沙箱模式等。這些“模式”能否被世人公認並流傳下來，還有待時間驗證。不過某種解決方案要成為一種模式，還是有幾個原則要遵守的。這幾個原則即是“再現”“教學”和“能夠以一個名字來描述這種模式”。
　　不管怎樣，在一些模式被公認並流行起來之前，需要慎重地冠之以某種模式的名稱。否則模式也許很容易泛濫，導緻人人都在發明模式，這反而增加瞭交流的難度。說不準哪天我們就能聽到有人說全局變量模式、加模式、減模式等。
　　在《設計模式》齣版後的近20年裏，也齣現瞭另外一批講述設計模式的優秀讀物。其中許多都獲得過Jolt大奬。數不清的程序員從設計模式中獲益，也許是改善瞭自己編寫的某個軟件，也許是從設計模式的學習中更好地理解瞭麵嚮對象編程思想。無論如何，相信對我們這些大多數的普通程序員來說，係統地學習設計模式並沒有壞處，相反，你會在模式的學習過程中受益匪淺。

评分☆☆☆☆☆

内容不说了，大家都知道。字体是比较清晰，纸张感觉很一般，而且油墨味真的太大了，真怀疑…。

评分☆☆☆☆☆

货已经收到，送货速度蛮及时的，内容比较贴合，算得上学习js高级技巧比较好的一本书了。

评分☆☆☆☆☆

爸，你想什么呢？我说的是接待客户。

评分☆☆☆☆☆

你……

评分☆☆☆☆☆

我只想说书的质量真的特别好，买了8本，才60多块，仅仅是*那本书有些脏和旧，擦擦就没事了，这些都是好书，花这么点钱买，真的是非常值得啊，又下了单买了10本，100块，这么便宜买这么多好书，得慢慢看咯，以后囤书就来京东咯，物流真的也特别给力，京东这次618，说实话，做的很棒，内心里其实我特别不愿看到京东做的比阿里系好，但是这几年京东的努力和进步真的是有目共睹。

评分☆☆☆☆☆

字迹清晰，纸张厚实，字体也很大，感觉不错。内容很基础，适合初学者。

评分☆☆☆☆☆

爸，你睡糊涂了？妈早就死了。

评分☆☆☆☆☆

书非常不错，由浅入深，代码很漂亮，

评分☆☆☆☆☆

只看了点后面再慢慢看了再来，感觉用着还好，基础的也有很多基础，后面的讲解也慢慢深入还有些插件什么的，还是本不错的书，初学者也挺适合的