設計模式之禪

所属分类:軟件工程及軟件方法學  
出版时间:2010年3月   出版时间:機械工業出版社   作者:秦小波   页数:545  

前言

終于可以寫前言了,這說明本書已經基本完成,可以長噓一口氣了。 為什麼寫這本書 今年5月份,我在JavaEye上發了一個帖子,其中提到自己已經工作9年了,總覺得這9年不應該就這麼荒廢了,應該給自己這9年的工作寫一個總結,總結的初稿就是這本書。 在談為什麼寫這本書之前,先抖抖自己這9年的職業生涯吧。大學時我是學習機械的,當時計算機剛剛熱起來,自己也喜歡玩一些新奇的東西,記得最清楚的是用VB寫了一個自由落體的小程序,模擬小球從桌面掉到地板上,然後計算反彈趨勢,很有成就感。于是2000年畢業時,我削尖了腦袋進入了IT行業,成為了一名真正的IT男,干著起得比雞早、睡得比雞晚的程序員工作,IT男的辛酸有誰知曉! 坦白地說,我的性格比較沉悶,屬于典型的程序員型悶騷,比較適合做技術研究。在這9年里,項目管理做過,系統分析做過,小兵當過,團隊領導人也當過,但至今還是一個做技術的。要總結這9年技術生涯,總得寫點什麼吧,最好是還能對其他人有點兒用的。那寫什麼好呢?Spring、Struts等工具框架類的書太多太多,很難再寫出花樣來,經過一番思考,最後選擇了一個每一位技術人員都需要掌握的、但普及程度還不是非常高的、又稍微有點難度的主題-設計模式(Design Pattern,DP)。 中國人有不破不立的思維,遠的如秦始皇焚書坑儒、項羽火燒阿房宮,近的如破“四舊”。正是由于有了這樣的思想,于是乎能改的就改,不能改的就推翻重寫,沒有一個持續開發藍圖。為什麼要破才能立呢?為什麼不能持續地發展?你說這是誰的錯呢?是你架構師的錯,你不能持續地擁抱變化,這是一個系統最失敗的地方。那怎麼才能實現擁抱變化的理想呢?設計模式! 設計模式是什麼?它是一套理論,由軟件界的先輩們(The Gang of Four︰包括Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides)總結出的一套可以反復使用的經驗,它可以提高代碼的可重用性,增強系統的可維護性,以及解決一系列的復雜問題。做軟件的人都知道需求是最難把握的,我們可以分析現有的需求,預測可能發生的變更,但是我們不能控制需求的變更。問題來了,既然需求的變更是不可控的,那如何擁抱變化呢?幸運的是,設計模式給了我們指導,專家們首先提出了6大設計原則,但這6大設計原則僅僅是一系列“口號”,真正付諸實施還需要有詳盡的指導方法,于是23種設計模式出現了。 設計模式已經誕生15年了,在這15年里出版了很多關于它的經典著作,相信大家都能如數家珍。盡管有這麼多書,工作5年了還不知道什麼是策略模式、狀態模式、責任鏈模式的程序員大有人在。不信?你找個機會去“虛心”地請教一下你的同事,看看他對設計模式有多少了解。不要告訴我要翻書才明白!設計模式不是工具,它是軟件開發的哲學,它能指導你如何去設計一個優秀的架構、編寫一段健壯的代碼、解決一個復雜的需求。

内容概要

如果說“四人幫”的《設計模式》是設計模式領域的“聖經”,那麼之後出版的各種關于設計模式的書都可稱之為“聖經”的“注釋版”或“聖經的故事”。本書是得道者對“聖經”的“禪悟”,它既不像“聖經”那樣因為惜字如金、字字珠璣而深奧、晦澀和難懂,又比“聖經”的“注釋版”更深刻和全面、更通俗和生動、更接近開發者遇到的實踐場景,更具指導性。本書兼收並蓄、博采眾長,也許是設計模式領域里的下一個里程碑之作。
  全書共分為四部分,第一部分從原理的角度闡述了面向對象程序設計的6大原則;第二部生動地講解和剖析了23種常見的設計模式,並進行了擴展,通俗易懂,趣味性極強而又緊扣模式的核心;第三部分對各種相關聯的設計模式進行了深入分析和比較,旨在闡明各種設計模式比較理想的應用場景和它們之間的區別;第四部分探討了設計模式的混編,講解了如何在實際開發中將各種設計模式混合起來使用,以發揮設計模式的最大效用。最後,本書還附有一份設計模式彩圖,可以裁剪,便于參考。
  禪宗曰︰“教外別傳,不立文字”,禪的境界本不該用文字來描述,言語也道不明白,但為了傳道,悟道者仍要藉言語來說明。
  何為禪?一種境界,一種體驗,一種精神領域的最高修為。何為設計模式?對面向對象思想的深刻理解,對軟件設計方法和編碼經驗的完美總結。
  本書是創造者的心路歷程,是實踐者的智慧結晶,是得道者的禪悟。它通過幽默風趣的故事和通俗易懂的講述方式,引導你悟透設計模式的真諦。
  如果你在思考下面這些問題,也許本書就是你想要的!
  1. 業務分析如此細致,架構設計如此健壯、可靠和穩定,但為何仍然無法適應業務發展的需要,而且生命周期只有短短幾年?
  2.
為何你的團隊協作了多年卻始終無法沉澱出可復用的組件或構件?依賴和解耦的標準是什麼?如何才能做到既不相互“刺傷”,又能相互“溫暖”?
  3. 架構設計時,如何才能實現高可擴展性和易維護性?如何避免維護成本大于開發成本的悲哀現狀?
  4. 交易型的系統如何大規模地借用設計模式的思想,以實現高性能、高可靠性的建設目標?
  5.
架構設計時,如果遇到這樣的情況︰“有一個請求者和多個處理者,同時要求二者之間解耦,以便處理者可以動態地擴展”,這該如何處理?
  6.
如果遇到過這樣場景︰“多個對象依賴一個對象,該對象狀態改變時所有的依賴者都要相應地獲得通知,並且要求對象間松散耦合”,這該如何處理?
  7. 萬物皆對象,不可能把每一個對象都分解到原子級別,如何適度地細化對象的顆粒度?怎樣界定對象的粒度大小?
  8. 同為創建類模式,工廠方法模式和建造者模式都可以創建對象,它們之間有何區別?適用的場景又有何不同?
  9. 狀態模式和策略模式的通用類圖如此相似,在實際的應用場景中如何區分它們?
  10. 如何使命令模式和責任鏈模式完美搭配並建立一個高可擴展性的系統架構,以解決客戶端和處理者都參數化的場景?
  11. 觀察者模式和責任鏈模式真的沒有可比性嗎?它們的主要區別何在?實際應用中如何使用?
  12. 組合模式只能用來表示部分和整體的關系嗎?其擴展出的規格模式是如何實現的?透明的組合模式和安全的組合模式有何區別?

作者简介

秦小波,資深軟件開發工程師、項目經理、系統分析師和架構師(獲Sun架構師認證),從事IT行業10余年,經驗極其豐富,現就任于交通銀行軟件研發中心。精通設計模式,對設計模式有深刻認識和獨到見解,創造性地提出了自己在大量實踐中總結出來的新的設計模式。擅長于SSH、iBati

书籍目录

前 言
第一部分 大旗不挥,谁敢冲锋——热身篇
 第1章 單一職責原則
  1.1 我是“牛”類,我可以擔任多職嗎
  1.2 絕殺技,打破你的傳統思維
  1.3 我單純,所以我快樂
  1.4 最佳實踐
 第2章 里氏替換原則
  2.1 愛恨糾葛的父子關系
  2.2 糾紛不斷,規則壓制
  2.3 最佳實踐
 第3章 依賴倒置原則
  3.1 依賴倒置原則的定義
  3.2 言而無信,你太需要契約
  3.3 依賴的三種寫法
  3.4 最佳實踐
 第4章 接口隔離原則
  4.1 接口隔離原則的定義
  4.2 美女何其多,觀點各不同
  4.3 保證接口的純潔性
  4.4 最佳實踐
 第5章 迪米特法則
  5.1 迪米特法則的定義
  5.2 我的知識你知道得越少越好
  5.3 最佳實踐
 第6章 開閉原則
  6.1 開閉原則的定義
  6.2 開閉原則的廬山真面目
  6.3 為什麼要采用開閉原則
  6.4 如何使用開閉原則
  6.5 最佳實踐
第二部分 我惹了谁——真刀实枪篇
 第7章 單例模式
  7.1 我是皇帝我獨苗
  7.2 單例模式的定義
  7.3 單例模式的應用
  7.4 單例模式的擴展
  7.5 最佳實踐
 第8章 工廠方法模式
  8.1 女媧造人的故事
  8.2 工廠方法模式的定義
  8.3 工廠方法模式的應用
   8.3.1 工廠方法模式的優點
   8.3.2 工廠方法模式的使用場景
  8.4 工廠方法模式的擴展
  8.5 最佳實踐
 第9章 抽象工廠模式
  9.1 女媧的失誤
  9.2 抽象工廠模式的定義
  9.3 抽象工廠模式的應用
   9.3.1 抽象工廠模式的優點
   9.3.2 抽象工廠模式的缺點
   9.3.3 抽象工廠模式的使用場景
   9.3.4 抽象工廠模式的注意事項
  9.4 最佳實踐
 第10章 模板方法模式
  10.1 辉煌工程—制造悍马
  10.2 模板方法模式的定義
  10.3 模板方法模式的應用
  10.4 模板方法模式的擴展
  10.5 最佳實踐
 第11章 建造者模式
  11.1 變化是永恆的
  11.2 建造者模式的定義
  11.3 建造者模式的應用
  11.4 建造者模式的擴展
  11.5 最佳實踐
 第12章 代理模式
  12.1 我是游戲至尊
  12.2 代理模式的定義
  12.3 代理模式的應用
   12.3.1 代理模式的優點
   12.3.2 代理模式的應用
  12.4 代理模式的擴展
   12.4.1 普通代理
   12.4.2 強制代理
   12.4.3 代理是有個性的
   12.4.4 虛擬代理
   12.4.5 動態代理
  12.5 最佳實踐
 第13章 原型模式
  13.1 個性化電子賬單
  13.2 原型模式的定義
  13.3 原型模式的應用
   13.3.1 原型模式的優點
   13.3.2 原型模式的使用場景
  13.4 原型模式的注意事項
   13.4.1 構造函數不會被執行
   13.4.2 淺拷貝和深拷貝
   13.4.3 clone與final兩個冤家
  13.5 最佳實踐
 第14章 中介者模式
  14.1 進銷存管理是這個樣子的嗎?
  14.2 中介者模式的定義
  14.3 中介者模式的應用
  14.4 中介者模式的實際應用
  14.5 最佳實踐
 第15章 命令模式
  15.1 項目經理也難當
  15.2 命令模式的定義
  15.3 命令模式的應用
   15.3.1 命令模式的優點
   15.3.2 命令模式的缺點
   15.3.3 命令模式的使用場景
  15.4 命令模式的擴展
   15.4.1 未講完的故事
   15.4.2 反悔問題
  15.5 最佳實踐
 第16章 責任鏈模式
  16.1 古代妇女的枷锁—“三从四德”
  16.2 責任鏈模式的定義
  16.3 責任鏈模式的應用
   16.3.1 責任鏈模式的優點
   16.3.2 責任鏈模式的缺點
   16.3.3 責任鏈模式的注意事項
  16.4 最佳實踐
 第17章 裝飾模式
  17.1 罪惡的成績單
  17.2 裝飾模式的定義
  17.3 裝飾模式應用
   17.3.1 裝飾模式的優點
   17.3.2 裝飾模式的缺點
   17.3.3 裝飾模式的應用
  17.4 最佳實踐
 第18章 策略模式
  18.1 劉備江東娶妻,趙雲他容易嗎
  18.2 策略模式的定義
  18.3 策略模式的應用
   18.3.1 策略模式的優點
   18.3.2 策略模式的缺點
   18.3.3 策略模式的應用
   18.3.4 策略模式的注意事項
  18.4 策略模式的擴展
  18.5 最佳實踐
 第19章 適配器模式
  19.1 业务发展—上帝才能控制
  19.2 適配器模式的定義
  19.3 適配器模式的應用
   19.3.1 適配器模式的優點
   19.3.2 適配器模式的應用
   19.3.3 適配器模式的注意事項
  19.4 適配器模式的擴展
  19.5 最佳實踐
 第20章 迭代器模式
  20.1 整理项目信息—苦差事
  20.2 迭代器模式的定義
  20.3 迭代器模式的應用
  20.4 最佳實踐
 第21章 組合模式
  21.1 公司的人事架構是這樣的嗎
  21.2 組合模式的定義
  21.3 組合模式的應用
   21.3.1 組合模式的優點
   21.3.2 組合模式的缺點
   21.3.3 組合模式的應用
   21.3.4 組合模式的注意事項
  21.4 組合模式的擴展
   21.4.1 真實的組合模式
   21.4.2 透明的組合模式
   21.4.3 組合模式的遍歷
  21.5 最佳實踐
 第22章 觀察者模式
  22.1 韓非子身邊的臥底是誰派來的
  22.2 觀察者模式的定義
  22.3 觀察者模式的應用
   22.3.1 觀察者模式的優點
   22.3.2 觀察者模式的缺點
   22.3.3 觀察者模式的應用
   22.3.4 觀察者模式的注意事項
  22.4 觀察者模式的擴展
   22.4.1 Java世界中的觀察者模式
   22.4.2 項目中真實觀察者模式
   22.4.3 訂閱發布模型
  22.5 最佳實踐
 第23章 門面模式
  23.1 我要投遞信件
  23.2 門面模式的定義
  23.3 門面模式的應用
   23.3.1 門面模式的優點
   23.3.2 門面模式的缺點
   23.3.3 門面模式的應用
  23.4 門面模式的注意事項
   23.4.1 一個子系統可以有多個門面
   23.4.2 門面不參與子系統內的業務邏輯
  23.5 最佳實踐
 第24章 備忘錄模式
  24.1 如此追女孩子,你還不樂
  24.2 備忘錄模式的定義
  24.3 備忘錄模式的應用
   24.3.1 備忘錄模式的應用
   24.3.2 備忘錄模式的注意事項
  24.4 備忘錄模式的擴展
   24.4.1 clone方式的備忘錄
   24.4.2 多狀態的備忘錄模式
   24.4.3 多備份的備忘錄
   24.4.4 封裝得更好一點
  24.5 最佳實踐
 第25章 訪問者模式
  25.1 員工的隱私何在?
  25.2 訪問者模式的定義
  25.3 訪問者模式的應用
   25.3.1 訪問者模式的優點
   25.3.2 訪問者模式的缺點
   25.3.3 訪問者模式的應用
  25.4 訪問者模式的擴展
   25.4.1 統計功能
   25.4.2 多個訪問者
   25.4.3 雙分派
  25.5 最佳實踐
 第26章 狀態模式
  26.1 城市的纵向发展功臣—电梯
  26.2 狀態模式的定義
  26.3 狀態模式的應用
   26.3.1 狀態模式的優點
   26.3.2 狀態模式的缺點
   26.3.3 狀態模式的應用
   26.3.4 狀態模式的注意事項
  26.4 最佳實踐
 第27章 解釋器模式
  27.1 四則運算你會嗎
  27.2 解釋器模式的定義
  27.3 解釋器模式的應用
   27.3.1 解釋器模式的優點
   27.3.2 解釋器模式的缺點
   27.3.3 解釋器模式使用的場景
   27.3.4 解釋器模式的注意事項
  27.4 最佳實踐
 第28章 享元模式
  28.1 內存溢出,司空見慣
  28.2 享元模式的定義
  28.3 享元模式的應用
   28.3.1 享元模式優點和缺點
   28.3.2 享元模式的應用
  28.4 享元模式的擴展
   28.4.1 線程安全的問題
   28.4.2 性能平衡
  28.5 最佳實踐
 第29章 橋梁模式
  29.1 我有一個夢想……
  29.2 橋梁模式的定義
  29.3 橋梁模式的應用
   29.3.1 橋梁模式的優點
   29.3.2 橋梁模式的應用
   29.3.3 橋梁模式的注意事項
  29.4 最佳實踐
第三部分 谁的地盘谁做主—模式PK篇
 第30章 創建類模式大PK
  30.1 工廠方法模式VS建造者模式
   30.1.1 按工廠方法建造超人
   30.1.2 按建造者模式建造超人
   30.1.3 最佳實踐
  30.2 抽象工廠模式VS建造者模式
   30.2.1 按抽象工廠模式生產車輛
   30.2.2 按建造者模式生產車輛
   30.2.3 最佳實踐
 第31章 結構類模式大PK
  31.1 代理模式VS裝飾模式
   31.1.1 代理模式
   31.1.2 裝飾模式
   31.1.3 最佳實踐
  31.2 裝飾模式VS適配器模式
   31.2.1 按裝飾模式描述丑小鴨
   31.2.2 按適配器模式實現丑小鴨
   31.2.3 最佳實踐
 第32章 行為類模式大PK
  32.1 命令模式VS策略模式
   32.1.1 策略模式實現壓縮算法
   32.1.2 命令模式實現壓縮算法
   32.1.3 小結
  32.2 策略模式VS狀態模式
   32.2.1 策略模式實現人生
   32.2.2 狀態模式實現人生
   32.2.3 小結
  32.3 觀察者模式VS責任鏈模式
   32.3.1 責任鏈模式實現DNS解析過程
   32.3.2 觸發鏈模式實現DNS解析過程
   32.3.3 小結
 第33章 跨戰區PK
  33.1 策略模式VS橋梁模式
   33.1.1 策略模式實現郵件發送
   33.1.2 橋梁模式實現郵件發送
   33.1.3 最佳實踐
  33.2 門面模式VS中介者模式
   33.2.1 中介者模式實現工資計算
   33.2.2 門面模式實現工資計算
   33.2.3 最佳實踐
  33.3 包裝模式群PK
   33.3.1 代理模式
   33.3.2 裝飾模式
   33.3.3 適配器模式
   33.3.4 橋梁模式
   33.3.5 最佳實踐
第四部分 完美世界—混编模式
 第34章 命令模式+責任鏈模式
  34.1 搬移UNIX的命令
  34.2 混編小結
 第35章 工廠方法模式+策略模式
  35.1 迷你版的交易系統
  35.2 混編小結
 第36章 觀察者模式+中介者模式
  36.1 事件觸發器的開發
  36.2 混編小結
 第37章 規格模式
  37.1 規格模式的實現
  37.2 最佳實踐
 第38章 MVC框架
  38.1 MVC框架的實現
   38.1.1 MVC的系統架構
   38.1.2 模型管理器
   38.1.3 值棧
   38.1.4 視圖管理器
   38.1.5 工具類
  38.2 最佳實踐
附錄︰23個設計模式

章节摘录

插图:第一部分大旗不挥,谁敢冲锋——热身篇第1章单一职责原则单一职责原则的英文名称是SingleResponsibilityPrinciple,简称是SRP。这个设计原则备受争议,只要你想和别人争执、怄气或者是吵架,这个原则是屡试不爽的。如果你是老大,看到一个接口或类是这样或那样设计的,你就问一句:“你设计的类符合SRP原则吗?”保准对方立马“萎缩”掉,而且还一脸崇拜地看着你,心想:“老大确实英明”。这个原则存在争议之处在哪里呢?就是对职责的定义,什么是类的职责,以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。只要做过项目,肯定要接触到用户、机构、角色管理这些模块,基本上使用的都是RBAC模型(Role-BasedAccessControl,基于角色的访问控制,通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离),确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构(一个人属于多个机构)、增加角色等,用户有这么多的信息和行为要维护,我们就把这些写到一个接口中,都是用户管理类嘛,我们先来看它的类图,如图1.1 所示。

媒体关注与评论

“禅”是一种境界,是得道者的智慧结晶。本书在写作方式上别出心裁,不是将设计模式的概念强行灌输给读者,而是以浅显的故事作为衬垫,深入浅出地展示了设计模式中蕴涵的哲理,进而引发读者的思考,提升他们的实际开发水平。  ——51CTO读书频道聪明的人,把房子盖在磐石上;无知的人,把房子盖在沙土上。对于开发者而言,设计模式就是那坚固的磐石。本书是设计模式领域难得一见的佳作,它用一种创新的方式对面向对象的设计原则和设计模式的要义进行了全新的阐释。对于所有Java开发者而言,无论你是初窥门径,还是深谙其道,本书都值得你阅读并收藏。  ——Java开发者社区本书不仅从开发者的角度对设计模式进行了独到而具有创意性的讲解,而且还从架构师的角度深刻地分析了设计模式在软件架构中的重要性。设计模式是架构师必备的技能之一,它的思想和原则能指导架构师设计出更优秀的软件架构。强烈推荐所有架构师阅读本书。  ——架构师社区多年前学设计模式,犯困无数次,打盹若干回。程序员一直被幽默着,现在终于可以反幽默一回了。这是一本厚积薄发的书,作者以其丰富的实践经验和通俗的讲解方式,把难懂的设计模式“化为”橡皮泥,让程序员想怎么玩就怎么玩,以致读完全书,仍觉意犹未尽。  ——江伍开,知名外企资深架构师,51CTO博客之星很多初学者都抱怨设计模式的抽象和深奥,对于他们来说,本书的出版不啻是一种福音!作者利用诙谐的语言和生动的叙述方式,结合当前国内读者熟知和易于理解的故事和开发场景,对设计模式进行了独特而全面的阐述,大大降低了设计模式的学习曲线,实在不可多得!  ——计文柯,资深软件开发专家和项目经理,《Spring技术内幕-深入解析Spring架构和设计原理》作者本书以设计模式为主题,是作者多年软件开发经验的总结。它介绍了一些重要的设计原则,并对各种经典的设计模式进行了详细的分析、比较和综合。全书通俗易懂、实例丰富,对想要学习设计模式的程序员有很大的启发和帮助。  ——郑晖,资深软件开发专家和CTO,《冒号课堂》作者无论是在建筑领域,还是在面向对象软件开发领域,如何强调设计模式的重要性都不过分。如果你觉得设计模式难学,推荐你认真阅读这本书,它用大量生动、有趣的故事将设计模式的深奥、晦涩化解于无形;如果你对设计模式一知半解,或只能“纸上谈兵”,建议你反复阅读这本书,它对面向对象的原则、设计模式的内涵和外延,以及设计模式的应用场景做了全面而深刻地阐述。  ——王福强,资深软件开发专家和架构师,《Spring揭秘》作者不管是新手还是大侠,本书绝不容错过,因为不能熟练地运用设计模式,就不能算是一名合格的程序员。它通俗易懂,作者精心挑选和设计的故事和案例引人入胜,是初学者的不二选择;它系统而全面,但又不乏深度,处处渗透着作者对设计模式的“悟”,是合格程序员必备的修炼秘籍。  ——徐彬,资深软件开发专家和架构师,《GWT揭秘》作者作者在本书中表现出来的想象力、创造力以及对设计模式和软件架构的深刻理解,让我十分震撼。我喜欢这种通过想象来讲解设计模式和剖析软件结构的方式,它一定会让你也受益匪浅。  ——倪健,资深架构师和项目经理,《软件开发之禅》作者

编辑推荐

《设计模式之禅》:继GOF《设计模式》之后的又一里程碑之作!6大原则,23+1种设计模式设计模式PK、设计模式混编、设计模式最佳实践设计模式领域的又一里程碑之作同样是导演,为什么詹姆斯·卡梅隆、史蒂芬·斯皮尔伯格能够制作出如此让人惊心动魄的旷世巨著呢?同样是建筑师,为什么贝聿铭、圣地亚哥·卡拉特拉瓦能够创造出如此美丽、和谐、雄伟的建筑呢?同样是程序员或架构师,我们的作品又应该达到怎样的境界?诚然,技术和创造力我们都不缺,缺少的是为软件注入灵魂的方式和方法,设计模式正是这一系列方式和方法的集大成者。巧妙地应用设计模式可以让我们的代码变得更健壮、更易于理解和维护,从而显著提高系统的性能、可靠性、稳定性、可维护性和可扩展性,是成长为优秀程序员和架构师的必备技能。“他山之石,可以攻玉”,《设计模式之禅》以亲切、自然的风格阐述了设计模式的核心思想,潜移默化地提升我们面向对象的架构和编程能力,带我们进入“物我合一、见性成佛”的最高设计境界。

图书封面




    設計模式之禪下載



用户评论 (总计73条)

 
 

  •     這本書絕對是有深厚編程功底的人才能寫出來的。作者相當的務實,他不是在簡單擺弄理論,而是用自己的實際經驗,用相當切合實際的例子對理論進行深入且深刻的闡述。這些例子不復雜,但確實能夠比較好的說明問題。相信作者在例子的選擇上是很下了一番功夫的。最值得欣賞的是作者是真正的做到了活學活用,而不是讀死書。作者在對理論加以靈活運用的時候真正考慮了讓人糾結的問題︰度的問題。任何理論的運用都有一個度,不及或過之都是欠缺。而對度的把握則是難中之難,因為它沒有可遵循的固定規律,只能依賴個人的經驗和智慧綜合考慮,這是任何機器都做不了的事情。相信大家能夠從作者對度的把握上收益良多。閱讀建議︰1.如果有一定coding功底,建議看到作者舉出的例子時,先自己加以重構/重新設計,然後再和作者改良後的代碼進行比較。這樣會收益多多。甚至可以在看到作者用漢字描述的例子時,就可以開始嘗試用程序實現,進而作兩次比較,一次代碼抽象原型比較,一次是改善後的代碼的比較。這樣更鍛煉人。2.盡信書則無書,適合別人的東西不一定適合你。所以用懷疑的態度去讀書,盡可能嘗試去推翻作者。這樣你才能將作者寫出來的東西變成你自己的東西,也就是做到活學活用。  至于不足之處,呵呵,相對于這本書的優點而言,基本上都可以忽略,而且關于通俗和幽默本身也是一個度的問題,其間的斟酌也是相當費時,所以我也就不再雞蛋里挑骨頭了。(轉讀者書評,原文地址見《設計模式之禪》豆瓣頁面)
  •     剛拿到書,看的不多,感覺該書與其他書的一個最大的區別就在于語言的通俗易懂。書中的例子也大多是平時開發工作中遇到的,感覺很親切,作者將設計模式的禪潛移默化的融入在簡單的語言和生動的實例中,不是說教,不會讓你感覺枯燥,我覺得這起碼是好書的一個標準,禪,其實就這麼簡單!(轉互動網讀者評論)
  •     書中通過對通過對六大設計原則的全新解讀、23種設計模式的完美演繹、設計模式的pk、設計模式混編等,向我們展示了作者的想象力,創造力和對設計模式的深刻理解,通過具體的開發場景,以講故事的方式向我們闡釋了設計模式的靈魂思想。  通過這兩天的閱讀,建議大家反復研讀,必將使自己的設計思想得以升華,使我們再次學習設計模式之時,領悟到“禪”的境界,禪的思想。  總之,這本書無論對初學者也好,資深編程人員也好,都是一本難得的好書,在細細玩味之後,在潛移默化之中,我們對設計模式的理解必將富有禪意!
  •     簡單、通俗,但又不膚淺,是本書的最大特色。尤為值得一提的是,本書還有設計模式PK和混編設計模式兩大部分內容講述如何自如地去運用這些設計模式,這是當前所有設計模式類的圖書都不具備的,連“四人幫”的那本書也不例外。
  •     在我的印象里,技術類書籍一向是相當枯燥的,至少我之前看的一直是這樣。眼楮死盯著碼起來的文字一個個地啃下去,遇到難理解的地方,自己看不明白,往往還得回頭再精讀一遍,就是神仙也沒了興趣。學習本應是一個快樂的過程, 相信那些技術類書籍的作者也不願意看到讀者把自己的著作看做一個個紙疙瘩,那就真杯具了。    《設計模式之禪》(以下簡稱《設禪》),很厚的一本書,跟我之前看的一本相當枯燥的《Web信息架構》略厚。當時一拿到手,心想︰完了,這要看到什麼時候!我這人看書本身比較慢,非得要把書里面的每一個字都要讀透(這是個不好的習慣)。但是拿起《設禪》真正讀起來的時候,徹底打消了我之前的疑慮,書中通過一個個實例給我們講了一個個編程的故事,平和的語言,滑稽的比喻,使得整個閱讀過程都相當流暢,一點沒有之前《Web信息架構》那般拖泥帶水的感覺……(慚愧,難為了那本很專業的書。)    完全可以理解華章圖書對這本書的重視,書的作者的確是花了腦筋的。作者的想象力和創造力也在書中有很好的體現,經常會在代碼示例中加入一些很幽默的注釋,例如“運行的時候開電梯門?你瘋了!電梯不會給你開的”,“這是絕對合理的,只運行不停止還有誰敢坐這個電梯?!估計只有上帝了”等等。書中也經常把一個個編程對象比作成現實中的例子,猶如看小說一般行雲流水。其實,每個軟件在設計者的心中,都是一本...小說,一個故事……    能把深奧枯燥的理論知識變得風趣幽默通俗易懂,沒有豐富的經驗是不可能辦到的,也體現了此書的難能可貴。 閱讀更多 ›
  •     從程序員到初涉軟件架構設計,對于我,“設計模式”仿佛從“Hello World”開始就是一個謎,面對完整的項目,復雜的需求,如何設計模型,這的確是一個問題。完美的設計出自對模式的理解和豐富的項目經驗,不得不承認,這需要我們花費很多時間和精力于此,並付諸于實踐中去。但是最近筆者閱讀了機械工業出版社的《設計模式之禪》一書,對設計模式的“禪理”娓娓道來,並且有很多精彩的例子做輔,語言平淡直白,通俗易懂,就像是在與深諳其道的朋友聊天。縱覽全書,本書分為四部分︰ 設計原則,針對六個設計原則進行闡述,其中不乏經驗之談; 設計模式演繹,分別描述了23中設計模式,並且每一種都有例程在里邊,每種模式應用的場景被形象的描述出來,比如第十六章的責任鏈模式,形象的用我國古代“三從四德”來舉例,描述責任鏈模式是怎樣應用的,等; 設計模式比較,分別就創建類模式,結構類模式和行為類模式等進行PK, 設計模式混編,列舉幾例模式嫁接應用,和MVC框架。總之,該書語言平實,實例精準,內容翔實,涵蓋面廣,是軟件設計模式中不可多得的一本書。簡單的幾行文字不足以概括其精妙,還需細細品味。
  •     還行 網上好像有這樣的例子
  •     本書引用許多實例,清楚描述了每個模式的應場景。並且還對不同模式間應用在同一問題進行比較,體現了作者對各模式深刻透徹的理解。
  •     設計模式,無論看多少次都很難入腦。因為現在快速開發框架太多,很少有機會能用到這些;但這不代表它們可以忽略
  •     書中講了很多設計模式,在工作中有很多值得借鑒的地方。尤其作者是有豐富的工作經驗,書寫的很好,希望有更多這類的電子書。
  •     其他都不错有些地方略显啰嗦
  •     用生活化的語言來講解設計模式是本書的最大特點。優點是通俗易懂,讀起來很輕松。缺點︰1.不夠嚴謹。比如錯別字,比如不當的例子,比如代碼中誤用的英文單詞,比如幾處提到“線程安全“的地方存在錯誤。2. 針對 Kindle 版電子書,所有代碼中需要標為“黑體”部分沒有用黑體標出來。
  •     需要經歷過,才能更懂得
  •     不過 評價不錯。給個好評
  •     很不錯的一本書 通俗易懂
  •     用來理解設計模式很好。
  •     送貨速度很快,很方便,比書店買書好。
  •     很不錯的書啦,謝謝
  •     書本超贊,針對java語言
  •       代碼太多了,特別是BO代碼,完全沒必要,唯一的好處就是讓人有看書一目十行的感覺。。
      
      另外,作者廢話挺多,有時候對基礎婆婆媽媽,比如講組合模式的時候的還介紹什麼是樹葉,什麼是根,有時候卻對關鍵的內容一筆帶過,比如在第一次講到ssh的時候,連個簡稱說明都沒有。。
      
      不過,書中的例子都還是不錯的,最後兩章關于不同模式的對比和混合寫的也很好,相信作者還是很費心思的。
  •       紙質書第16頁下面剛改的代碼,在17頁仍然輸出“父類被執行“而不是”Map 轉Collection被執行“,難道我理解有誤?
      
  •       書是在再次讀完 Head First Design Patterns 後讀的,易于做橫向比較,估計接下來會把《大話設計模式》也一並掃讀了。
      
      我是看完後隨手把書評發到微博上,整理到這里,就不再添字了。
      
      掃完「設計模式之禪」,讀的是PDF版本,缺了幾節。整體質量一般,最值得看就是對SOLID解說這一章。作者說讀過 Head First Design Patterns,但不喜歡書中的西方幽默,但我覺得 Head First Design Patterns 這書更好。
      
      Head First Design Patterns 較之「設計模式之禪」的優點︰兩者都在章節起始導入問題,但前者更深入地通過文字引導讀者思路,並且伴隨著教導讀者些許測試驅動和重構的方法。此外,Head First Design Patterns會比較類似模式之間的異同優劣。
      
      Head First Design Patterns 沒有說盡23個設計模式,它有針對性地選擇、編排設計模式講述的先後,並在設計模式的講述中插入對設計原則的講解。相反,「設計模式之禪」只是簡單介紹各個模式,代碼篇幅太多,甚至只給出代碼就讓讀者自個領悟去。
      
      引用「設計模式之禪」中的一句,看官自個評質量︰〞策略模式的好處就是︰體現了高內聚低耦合的特性呀,缺點嘛,這個那個,我回去再查查〞、〞這個就不多說了,自己領悟去〞(第7頁)。注︰我看的是PDF版,與實體書可能有些許不同。但大體內容和風格應該是一致的。
      
      總結︰有閑情可以翻一翻,不值得入手。Head First Design Patterns 更適合用于了解設計模式。
      
      這篇簡評很中肯︰ http://book.douban.com/review/3219343/
  •       這書我是先在網上找到電子版看的。雖然不全,但是足以認定本書乃“十世修來的”好書。我認為好書需要三個條件︰一作者有真才實學;二作者善于講解和表達;三作者態度認真,力求打造經典。而這本書就具備全部條件。于是我買了實體書,還包了書皮兒...
      
      至于書的內容嘛,講設計模式唄。這東西的重要性需要強調嗎?如果你覺得需要那你別猶豫了趕快找本書來惡補吧,這本就不錯。
      
      推薦大家都來看看,絕對不虧的。
  •       說實在的,我根本不懂設計模式,本來看到好多人在力薦這本書,心里就癢的難受,但是,“書,不讀,如廢紙”,心里還是隱隱的告訴自己“再想想,買那麼多書了,有幾本徹底的看完過?!”
      恰巧有pdf格式的下載,下來看看吧,再次說實在啊,看這本書的前言“如何閱讀本書”,一個字“賊拉的震撼”,銀生第二次看到發自內心的話語啊,而不是商人般的唯好必說、逢疵必讓,第一次是看《21天學會C++》,作者前言說道“沒有任何一個人能夠在21天內掌握一門結構嚴謹的語言”,人家把道都給你指明了。第二次,就是本書,為什麼本書會讓我嬌弱的小心眼兒為之震撼呢?我說過,我是一只小鳥,小phper,知道成長的艱辛,絞盡腦汁去參悟作者的意思、看花了眼楮去閱讀手冊,成之路真是辛苦啊!可能是受盡以往資料生硬語言的束縛,本書敘事方式和以往書籍截然相反,舉例說明︰大家都有幾個要好的朋友吧,和朋友談話時候什麼感覺,和朋友談心時什麼感覺,和朋友扯淡是什麼感覺?看這本書就是啥感覺,還是一個字“賊舒服”,換句話,你和楊教授聊天,啥感覺?(你和楊教授關系老鐵了,另當別論);
      嘿嘿,上學的時候語文沒學好,想到哪說到哪,倒是全部發自內心,謝謝︰)
  •       這幾年來,前後讀過3本設計模式的書︰
      
      1. 《大化設計模式》
      2. 《HeadFirst設計模式》
      3. 《設計模式之禪》
      
      前兩本書出版的時間比較早,也比較暢銷,于是我都買了,總體而言,我能給《大話設計模式》打60分,因為它有的僅僅只是對設計模式的解讀,而且是最基礎部分的解讀,試圖用一些很能讓讀者容易懂的方式去解讀,但在我看來,這方面其實做得並不好。缺乏比較核心的內容。我能給《HeadFirst設計模式》打75分,這本書在設計模式領域還是相當有地位的,因為它開創了講解和學習設計模式的新方法,這本書的優點就在于通俗易懂,精準到位,不足之處在于沒有能很好地把這23種設計模式進行融會貫通和綜合比較,也沒有太多關于如何才能更好地應用這些設計模式的講解,屬于入門價的,對提高沒有太多幫助。
      
      《設計模式之禪》算是後起之秀了,這本書剛出版時在社區里引起了轟動,身邊的同事也有幾個人買了,我借來看了看,一下子被吸引住了,于是自己也買了1本,到現在為止,我已經看了2遍了,感覺自己對設計模式的理解加深了很多。這本書幾乎繼承了前面兩本書的所有優點,而且避免了前面兩本書的不足。
      
      強烈向想學習設計模式的朋友推薦這本《設計模式之禪》
  •        熱愛技術並且討厭枯燥乏味技術文章的讀者都可以看本書;
       你是程序員,沒問題,本書能夠讓你寫出更加高效、優雅的代碼;
       你是架構師,那更好,設計模式可讓你設計出健壯、穩定、高效的系統,並且自動地預防未來業務變化可能對系統帶來的影響;
       你是項目經理,也OK,設計模式可以讓你的工期大大縮短,讓你的項目團隊成員快速地理解你的意圖,最終的成果就是優質的項目︰高可靠性,高穩定性,高效率和低維護成本。
      (來自卓越)
      
  •       簡單、通俗、易懂,但又不膚淺,這是本書的最大特色。尤為值得一提的是,本書還有設計模式PK和混編設計模式兩大部分內容教你如何自如地去運用這些設計模式,這是當前所有設計模式類的圖書都不具備的,連“四人幫”的那本書也不例外。
      (來自卓越)
      
  •       前一段時間終于領到了我期待已久的《設計模式之禪》一書,但是由于工作的原因,一直沒有時間靜下心來細細品味作者那些來自自己工作實踐中的禪語。我把這本書放在我的床前,每當我臨睡前,我都會翻翻此書。在此之前我也看過一些設計模式方面的書,但是看看就想睡覺。有些設計模式的書看的是雲里霧里的,看完了都不知道人家說的是什麼。
      《設計模式之禪》這本書更多的是從實踐和應用的角度來講設計模式,作者根據自己的項目實踐總結出一些使用設計模式的方法和應注意事項。再加上作者通俗易懂的語言描述,讀起這本書來就像讀武俠小說一樣過癮。翻看了一下本書的目錄,我覺得本書不僅僅是對23種設計模式的解讀,更多的是對這23中設計模式進行比較,比較各設計模式的優缺點,以便在實際應用中進行合理的使用。
      《設計模式之禪》確實是一本值得讀的好書,我會好好的讀這本書的。
      
  •       轉卓越網讀者評論︰
      
      是程序員都知道設計模式很重要,幾乎所有還沒有悟透設計模式的程序員都指導設計模式很難搞,學習的成本非常高,過來人都說要一邊實踐,一邊理解,然後一邊總結。
      
      關于設計模式的書非常多,有GOF的,也有其他解讀版的,我個人在學習設計模式的過程中也接觸過幾本,比如GOF的《設計模式》,書是很經典,但是太難懂了;《Head First設計模式》也讀過了,還不錯;《大話設計模式》在書店里也翻了翻,能打個60分吧,遠沒有大家說的那麼好;《設計模式之禪》這本書我讀了快一半了,應該說的確彌補了這幾本書的不足之處,淺顯易讀但是又不膚淺是這本書最大的特點,能從書中設計的案例看得出來作者的道行比較深,而且寫這本書時很用心,實在是讀者的福氣。
      
      建議想學設計模式的朋友首選這本書,應該不會讓你失望。
  •       原來借閱過閻宏的《Java與模式》,當初看時,剛入門,對模式設計的興趣不大,而且對傳統文化了解淺薄,感覺讀不懂,就放下了。
      所以,拿到這本書,看到名字的時候,就是怕自己再次看不懂。但在認真的看了幾天之後,就明顯感覺這本書講述的比較樸實,比較結合現實。
      工作了這麼多年,或多或少的用到了些模式,但對它們之間區別和運用往往不夠重視,所以開發中往往猶如芒刺在背,本書開頭用了六章來講解最基本原則。
      本書定位讀者應該是對模式有所了解和項目聯合開發經驗的,不過沒有這些經驗,也可以作為指導性書籍來看。
      我所在公司不大,項目基本都是單兵作戰,往往是一個人同時扛多個項目,而每個項目的參與者頂多不過3-5人(包括頁面設計和客服等), 開發上往往只有一兩個人,所以,接口用的不多,就是有也放著不用。但看了這本書以後,感覺受益良多,發現很多東西如果設計的好,可以避免重復工作的浪費。
      設計模式,不是說看過明白了就可以把書扔掉,此書也介紹了一下常見的組合模式,看起來,就不費勁。推薦給大家此書,時常看看。
      另外,特別感謝哲思社區和華章公司,給我這個機會做此書的評論員,書評有點晚了,非常抱歉!
  •       在我的印象里,技術類書籍一向是相當枯燥的,至少我之前看的一直是這樣。眼楮死盯著碼起來的文字一個個地啃下去,遇到難理解的地方,自己看不明白,往往還得回頭再精讀一遍,就是神仙也沒了興趣。學習本應是一個快樂的過程, 相信那些技術類書籍的作者也不願意看到讀者把自己的著作看做一個個紙疙瘩,那就真杯具了。
      
      《設計模式之禪》(以下簡稱《設禪》),很厚的一本書,跟我之前看的一本相當枯燥的《Web信息架構》略厚。當時一拿到手,心想︰完了,這要看到什麼時候!我這人看書本身比較慢,非得要把書里面的每一個字都要讀透(這是個不好的習慣)。但是拿起《設禪》真正讀起來的時候,徹底打消了我之前的疑慮,書中通過一個個實例給我們講了一個個編程的故事,平和的語言,滑稽的比喻,使得整個閱讀過程都相當流暢,一點沒有之前《Web信息架構》那般拖泥帶水的感覺……(慚愧,難為了那本很專業的書。)
      
      完全可以理解華章圖書對這本書的重視,書的作者的確是花了腦筋的。作者的想象力和創造力也在書中有很好的體現,經常會在代碼示例中加入一些很幽默的注釋,例如“運行的時候開電梯門?你瘋了!電梯不會給你開的”,“這是絕對合理的,只運行不停止還有誰敢坐這個電梯?!估計只有上帝了”等等。書中也經常把一個個編程對象比作成現實中的例子,猶如看小說一般行雲流水。其實,每個軟件在設計者的心中,都是一本小說,一個故事……
      
      能把深奧枯燥的理論知識變得風趣幽默通俗易懂,沒有豐富的經驗是不可能辦到的,也體現了此書的難能可貴。
  •       剛知道自己有機會拿到這本書時,真是喜出望外,倍感興奮。因為以前下了n次的決心想學設計模式,四人幫的《設計模式》也從圖書館借了換,換了又借。一次都沒看完過,並且都是翻了幾頁就放下了,感覺設計模式太可怕了。但他卻又是程序員不得不學的東西,于是為之深感煩惱。有時候時常安慰自己說“現在還沒到學習設計模式的時候呢,等做過幾個項目再去看自然也就懂了。”說是這樣說的,那只不過是安慰自己的話罷了,仍想早些了解他,並能很好的運用它。這時候我極想能找到一本設計模式入門的書籍,先對設計模式有一個初步的了解,讓後再去看那所謂的經典,但一直沒找到合適的。就在這愁人之際看到了這本書,一下子就被這本書的介紹吸引住了︰
      
       如果說“四人幫”的《設計模式》是設計模式領域的“聖經”,那麼之後出版的各種關于設計模式的書都可稱之為“聖經”的“注釋版”或“聖經的故事”。本書 是得道者對“聖經”的“禪悟”,它既不像“聖經”那樣因為惜字如金、字字珠璣而深奧、晦澀和難懂,又比“聖經”的“注釋版”更深刻和全面、更通俗和生動、 更接近開發者遇到的實踐場景、更具指導性。本書兼收並蓄、博采眾長,是設計模式領域里的里程碑之作。
      
       這介紹正合我意,心想我終于找到了它。我終于可以參悟設計模式中的奧秘了。之後便是每天都在期待著這本書的來臨,可是之後一個月都沒拿到書,那可恨的郵局啊。還好華章的張艷又趕緊快遞了一本給我。真是太感謝她了。雖然收到了書,但此時已步入畢業設計的繁忙時期,白天工作,晚上回來做畢業設計,這本書只有等熄燈後每天看上半個小時了。到今天已收到書恰好兩周了,不過至今仍沒看完,但我已了解本書的寫作風格,下面說說我對這本書的感受吧︰
      
       本書使用JAVA語言描述的小例子向大家展示了6大設計原則和23中設計模式。之後又做了擴展來了個設計模式大PK,更令人欣喜的是最後一部分講解設計模式在實際中的運用,若真沒有這一章,我還真對本書有點小失望呢。呵呵。
      
      本書的優點︰
      
      1 紙張質量
      
       這本書的質量沒得說,華麗精美的封面,書的紙張也相當的不錯,絕對適合收藏。
      
      2 讀者範圍廣
      
       這本書的讀者範圍可謂相當廣,不管您有沒有編程經驗,這本書您都可以去讀,就像作者說的,沒有編程經驗的您可以把它當本小說去讀。但說是這麼說,我相信有一定的編程基礎的同學都能看懂些。
      
      3 通俗易懂,風趣幽默
      
       作者之所以敢說沒有編程經驗的同學可以把本書可以當小說讀,完全在于作者那章章節節的小故事,非常風趣幽默,能完全吸引住讀者跟著作者的思路走,再加上作者使用相當簡單的程序去描述每個模式,非常通俗易懂,我相信只要有點編程經驗的人都能看懂一些的。
      
      4 講解細致
      
       相比200多頁的“四人幫”經典,作者可謂大方之極,看來“惜墨如金”這四個字在作者身上沒起作用哈。^_^,作者結合實例細致講解了每個設計模式,之後仍感覺不過癮,又來了個設計模式大PK,通過PK能讀者能更好的理解各個設計模式。PK完之後作者貌似體力仍十足有余啊,又從實際編程的角度給大家講解設計模式的綜合運用,真是一盤絕頂大餐啊。正和我口味,呵呵。
      
      本書的缺點︰
      
       俗話說世上沒有完美的東西,如果完美了,他肯定不是來自地球。呵呵!而每個人對美丑的欣賞角度也不一樣,觀點定不會統一,我認為本書的缺點是︰
      
       1 看本書需要一定的UML基礎,這點真是有點令人不悅,雖然我是學C\C++的,對JAVA的了解為0,但代碼我基本上都能看懂,只可惜作者的類圖有些實在讓人摸不著頭腦,有些類圖畫的是在讓我搞不懂有些類的關系到底是什麼,目前實在懶得去看UML了,.我想作者能對此進行一下解釋就更好了,我認為在這個地方,作者設計好小例子之後,可以專門拿出一小節根據類圖講述類之間的關系,並由此引申一下設計模式,我想會更好。如果所有的東西都讓讀者從代碼中看的話,沒有編程經驗的確實也只能夠看個熱鬧了,只能留給有2年以上工作經驗的人看了。
      
       2 我感覺作者的例子可以在深入一些,我感覺有些例子稍微有些牽強,能深入些會更好。
      
       總之,這本書是一本學習設計模式的很好書籍,如果您還覺得設計模式枯燥無味,難學之極,那請你來看本書吧,它能在你不知不覺中把你帶入設計模式的領地,並 不斷浸潤設計模式之精華。看完本書並做一些練習之後,我相信你不但不會再對設計模式有所恐怖,反而還可以能在自己的項目中運用自如的使用設計模式,使自己 的代碼設計更加靈活。
  •       “設計模式領域又一里程之作”,這個評價夸大其詞了。買了這本書,還是有點後悔的。如果需要入門設計模式,還是看那本head first(例子java寫的)更好一點。
      然後四人幫的那本經典,也是必讀的。
      這本書名字起的很大氣,但是內容並沒有達到這個高度。
  •       在一小段時間前,有點空閑時間,想學習一下設計模式。幾年前就一直听“高人”們提到設計模式,當時也著實想認真研習一下,並認為不明白設計模式,始終是比較瘸腿。但找到的讀物都令人費解,讀起來很吃力,所以每次都中途而廢。
      在網絡上無意中發現了秦小波先生關于設計模式的一個PDF,感覺寫的非常好,很對胃口,有眼前一亮的感覺。然後追根溯源就找到了這本《設計模式之禪》。這本書相對于其他講模式的書,還是非常容易理解的,也比較容易記住。
      這本書讓我重新拾回學習設計模式的信心,非常感謝作者。
      我感覺這本書可以這樣讀並從而學習設計模式︰
      
      1、像讀小說一樣耐心讀完,讀的過程中要集中精力,盡量記住每一種模式的描述
      2、對照目錄,認真回憶每種模式是怎麼描述的,用于何種場景
      3、對于不能記清楚的模式,立刻找到對應章節快速瀏覽,從而加強記憶
      4、有幾個模式會容易記混,所以要認真比較和加強記憶
      5、書本只是對模式進行了容易理解的描述,關鍵還在于理解每個模式的思想,然後使用于自己的設計中
      6、針對每個模式,都重新舉個例子,並用代碼實現,從而更加強化記憶和理解
      7、書中大部分的例子,都是先寫不完全正確的例子,然後循序漸進,給出正確的例子。應該增加一個特殊的索引,直接指向正確的例子,便于讀過的人可以快速定位。不過這本書很不錯的一個做法是在最後提供了一個很大篇幅的關于各個模式的彩頁,我覺得個人可以在這個彩頁上直接標記出每個模式對應的頁號,這樣以後就方便快速索引了。
      8、對于手頭有源碼並且設計復雜的系統或者軟件,可以對照學習,對號入座,從而也可以加強理解。久而久之,以後再看“高人”的代碼就再也不迷惑了,可以一目十行的快速閱讀代碼了。特別是一些架構級別的代碼。
      
  •       
      對與設計模式的認識源于2年前的一本書《設計模式》,GoF(“四人幫”,指Gamma, Helm, Johnson & Vlissides, Addison-Wesley四人)的《設計模式》第一次將設計模式提升到理論高度,並將之規範化,提出了23種基本設計模式,自此,在可復用面向對象軟件的發展過程中,新的大量的設計模式不斷出現。
      但是對于一個初學者來說,這本書畢竟是比較專業化的視角來描述,難免有些苦澀難懂,自從前段時間在51cto 讀書頻道,接觸到“設計模式之禪”這本書後,使我的想法完全發生了改變,作者以親切自然的風格闡述了設計模式的核心思想,潛移默化地提升可我們面向對象的架構和編程能力,帶我們進入了“物我合一,見性成佛”的最高設計境界。全書以簡單通俗易懂但又不膚淺的描寫方法,讓我們在靜靜的思考中,慢慢的會意中,把設計模式的思維無聲地融入自己的思維中。
      就像作者在前言中所說︰“會看的看門道,不會看的看個熱鬧”本書對無論有無編程經驗的人來說都是一本書中的尚品。對于經驗欠缺的編程人員,完全可以把它當成一本小書看。
      書中通過對通過對六大設計原則的全新解讀、23種設計模式的完美演繹、設計模式的pk、設計模式混編等,向我們展示了作者的想象力,創造力和對設計模式的深刻理解,通過具體的開發場景,以講故事的方式向我們闡釋了設計模式的靈魂思想。
      通過這兩天的閱讀,建議大家反復研讀,必將使自己的設計思想得以升華,使我們再次學習設計模式之時,領悟到“禪”的境界,禪的思想。
      總之,這本書無論對初學者也好,資深編程人員也好,都是一本難得的好書,在細細玩味之後,在潛移默化之中,我們對設計模式的理解必將富有禪意!
      就和大家分享這麼多,希望大家在讀這本書時,能共同交流,共同提高,是我們無論對技術的學習還是對生活的領悟都有一個更高的境界。(我的郵箱daiyuxi110@sina.com,希望和大家分享!)
      
  •       1. 綜合評論
      【一句話總結】
      值得一讀。比大話系列嚴謹,比GOF聖經易懂。69塊錢,24小時,劃算。
      
      【各部分感受】
      第一部分,六大原則,及其受用,適用于程序開發也適用于做人做事。
      書中有大量生動活潑的故事,有些十分貼切,想必作者費了不少腦汁。
      
      第二部分,對GOF的模式以有趣的方式庖丁解牛了一番,有些很獨到。
      初學者上手快,已悉者溫故知新。有趣味,有過程,有血肉。
      
      第三部分,PK很有特色,鞏固知識,加深印象,消食通便。
      不打不相識,越打越親近。條條大道通羅馬,風景各不同。
      
      第四部分,合作共贏,綜合應用,凝聚開發者的智慧。
      重點看需求上下文和程序架構,模式名字已不重要。
      
      附錄的23種設計模式類圖,是殺人越貨之必備阿。
      
      【閱讀建議】
      每節的【最佳實踐】都應當理智閱讀,原則也,實踐也。
      演示代碼只是為了說明問題,在實際項目中采用,要斟酌。
      建議閱讀順序,四一二三四一。
      閱讀目標,忘記模式吧,融入場景,心中無刀。
      
      2. 事件考古
      【2010年03月12日 五】 看分享,《設計模式之禪》試評員招募
      【2010年03月13日 六】 湊熱鬧,“申請,看看什麼是禪”
      【2010年03月19日 五】 出結果,直到瑩美女分享才知道。
      【2010年03月22日 一】 發郵件,“哲思-設計模式之禪-試評員-登記”
      【2010年03月23日 二】 收郵件,恭喜您成為華章公司《設計模式之禪》試評員。
      【2010年04月02日 五】 第一篇,哲思楊某俠書評出爐。
      【2010年04月08日 四】 怕誤事,郵件確認︰樣書已于3月25日寄出,平郵。
      【2010年04月15日 四】 樣書到,雯美女親臨。
      
      3. 試評計劃
      設計模式之禪/秦小波/機械工業出版社/ISBN978-7-111-29544-0/545頁/69元
      試評員約定要在樣書到手的兩周內出書評,500字以上,發布于網上。
      作者學機械的,9年技術,兒子三歲。豆腐學化工的,7年技術,兒子175天。
      前輩啊,O(∩_∩)O哈哈~,這書有點啃頭,有計劃有步驟的耐心嚼之。
      盡信書不如無書,豆腐讀書,絕對是批判的繼承,批判是我思考,不直接反映書的品質。
      和買東西一樣,挑刺越多,越易成交,滿口好好的,可能路過。
      
      白天上班,晚上親子。整塊的時間不多,遂分而治之,評一次為一里程,路標如下。
      【C1.1】即第1.1節。(C)hapter,為章節標記。
      【P123】即第123頁。(P)age,為頁數標記。
      【BTW】隨便說一下。(by the way)
      【小結】小小的總結一下。
      
      4. 第一里程
      【2010年04月15日 四 18:30】
      【書名】禪者,心也。有點玄。要是蟬就好了,知了也。
      【封皮】诗经·小雅·鹤鸣 “它山之石,可以攻玉。”
      【作者】交行阿,信用卡用他家的,網銀有待改進。
      【贊譽】很多人很高評價,還有阿福,有點看頭。
      【前言】挺實在。致謝那段有意思。23種模式都用過,是否存在過度設計。
      【C1.1】info隱喻是屬性,不應實現Biz行為接口,見仁見智吧。
      【C1.2】IPhone的例子很好,‘注意’‘學究’,提示背景和視角。
      【C1.3】我單純,所以我快樂。
      【C1.4】很現實的問題,多快好省,服從領導。
      【C2.1】繼承必須擁有父類的所有屬性和方法。private的呢,從哪個角度講。
      【C2.2】OO5大原則之里氏替換,09圖靈獎女得主。例子很好,尤其CS那個。
      【2010年04月15日 四 21:00】
      
      5. 第二里程
      【2010年04月16日 五 18:08】
      【P24】表面類型和實際類型,頭一次听說,為何不用大眾叫法。
      【C3.x】DIP,真的是講了不少。
      【C4.1】實例接口,這種講法,長見識。
      【C4.2】星探找美女,不如改成相親,更有殺傷力。
      【C4.3】IBookSearcher 例子不錯。
      【C5.1】你知道的太多了,所以越單純越好。
      【C5.2】commond通假command?4層含義講的很透徹。
      【BTW】不太習慣,下劃線開始的變量。
      【2010年04月16日 五 21:30】
      
      6. 第三里程
      【2010年04月17日 六 12:11】
      【C6.x】開閉原則,擁抱變化,第一思考的原則。
      【小結】
      六大原則很是受用,程序員進化之必備。例子多樣,很大眾化。
      建議增設第七原則,就是奧康姆剃刀----“如無必要,勿增實體”。
      【P59】say()還是不要static了吧。
      【P60】構造函數private只是確保了非本類不能new,而不是僅產生一個實例。
      【P60】“類中其他方法,盡量是static”,public static 違反LoD,隱患多。
      【C7.3】對單例講的很全面。除了clone外,反序列化也值得注意。
      【C7.4】場景假設的好,還普及歷史知識,但代碼有點不妥。
      【P62】countNumOfEmperor,static太糟糕,鈺有時會說他是鎮,都不用多線程。
      【P63】直接 Emperor.say()試試看。
      【C7.5】單例會被JVM的GC麼?何種情況,理論依據或證據呢?豆腐認為有Ref就不GC。
      【C8.1】大話女媧造人的故事比較有趣。
      【P67】”其中的’?‘表示的是,... ...“ 沒看到代碼里使用。言之何物?
      【P67】Class.forName(c.getName()).newInstance();為何不直接 c.newInstance();
      【P67】使用泛型T,為何要Human強制轉換一下呢。
      【P77】Map<String,Product> prMap = new HashMap(); 建議HashMap parameterized
      【C8.x】GOF說的很好。此節的例子不太恰當,有點為了工廠而工廠。
      【C9.x】略讀。還是女媧娘娘這塊比較有趣,想必費了不少腦筋。
      【2010年04月17日 六 15:20】
      
      7. 第四里程
      【2010年04月17日 六 18:20】
      【C10.1】本小三,純屬虛構。
      【C10.2】final防覆蓋,這個提示很到位。
      【C10.x】模板這塊講的很細膩。記得JIC系統,就問過襪子,如何限定子類行為。
      【C11.1】變化是永恆的,Builder+Templet的例子很有代表性,值得研習。
      【P108】顯式調用Collection的clear(),不僅可避免意外驚喜,還可避免泄漏。
      【小結】模板和創建這兩節非常好,一個場景貫穿,一氣呵成。
      【C12.x】用游戲代練類比Proxy,用“審計”點出AOP,本節的看點。
      【P146】this.arrayList 改成 thing.arrayList,筆誤。
      【C13.4.3】冤家是因為final賦值,淺clone可以,深clone曲線救國也是可以的。
      【C13.x】電子賬單的場景有來路,帶有實際業務的影子,比虛構的系列好很多。
      【2010年04月17日 六 21:33】
      
      8. 第五里程
      【2010年04月18日 日 08:00】
      【C14.1】兩個“庫存情況”。後者應該是”采購情況“。
      【P148】“折半采購“少了 stock.increase(buyNumber);
      【C14.x】貼近生活,容易理解。
      【P170】命令模式通用類圖,Client關聯Receiver還是Invoker?
      【C15.5】原來伏筆在此揭開,算我讀的很仔細。
      【C15.x】有別于GOF,從新的角度講解了Command模式。
      【C16.x】責任鏈,全體婦女同志站起來 ... ... 了。
      【2010年04月18日 日 09:30】
      
      9. 第六里程
      【2010年04月18日 日 13:00】
      【C17.x】成績單大話的很熱鬧,JDK中例子很多。
      【C18.x】略讀。策略枚舉慎用。
      【C19.x】略讀。RMI慎用。
      【C20.x】如書中所說,太普遍了。研究研究Collection框架有好處。
      【C21.x】組合模式這麼講有點暈。樹這麼整不合適。
      【C22.x】先看反面例子,再看注意事項,再研究“暴露狂”。
      【C23.1】letterInotoEnvelope() 通假 Into。
      【C23.x】略讀。應該談談JDBC。
      【2010年04月18日 日 14:40】
      
      10. 第七里程
      【2010年04月18日 日 17:30】
      【P307】寬接口,窄接口,講的很好。
      【C24.x】備忘錄,有用的東西。注意不同場景下的策略略和細節。
      【P317】圖25-5,這個類圖怪怪的,method首字大寫。
      【BTW】類圖有些沒標返回值,圖25-6,25-5,25-4。
      【P328】雙反派,雙分派。
      【C25.x】以鄰居訪問為故事講解的很好。
      【BTW】很多方法論,都有很貼切的例子,在生活中活靈活現。
      【P340】代碼26-13,還是setLiftState(Context.closeingState);好。
      【BTW】closeing,openning這兩個ing很smilence(笑而不語)。
      【C26.x】電梯的例子很好,明了貼切,值得細品。
      【C27.x】堆棧計算器,適合學習。
      【C28.1】對廠商的分析工具感興趣。
      【P360】工廠是200多個並發,咋沒進行線程安全控制呢。
      【P365】講了。
      【P369】10萬次,多按了2個零 10000000
      【C28.x】故事場景不錯。對象在內存的大小可以通過成員變量估算的。
      【P378】眼中無黑體部分,心中有黑體部分。印丟了,呵呵。
      【C30.x】又是一個很有趣的例子,山寨公司。
      【小結】23個模式總算過完了,場景設計的很用心,老少皆宜。
      【2010年04月18日 日 20:15】
      
      11. 第八里程
      【2010年04月19日 一 20:20】
      【C30】PK阿,刺激,類比再對比,是深入了解事物的最佳實踐。
      【C30.1】第一回合,PK的不錯,有點內褲外穿的勢頭。
      【C30.2】第二回合,不太地道,應該工廠PK抽象工廠,工廠欺負Builder。
      【C30.x】這麼P如何︰超人工廠PK抽象工廠,抽象工廠PK建造者于汽車。
      【C31.1】場景合適,級別相當,恰到好處。
      【C31.2】丑小鴨的例子很好很強大,目前為止最贊的一個,是如何想到的呢。
      【C32.1】命令模式在這場PK中狀態不好,暈乎乎的,結論很清楚。
      【C32.2】壓縮對策略有力,對命令不利,容易漂移。
      【C32.3】DNS這段PK也到位,買一贈一,看PK,送DNS原理。
      【2010年04月19日 一 21:40】
      
      12. 第九里程
      【2010年04月20日 二 09:10】
      【C33】各種職業互P,法師對戰士。
      【C33.1】略讀,最佳實踐總結了,尤其是抓到耗子就是好貓。
      【C33.2】看點是類圖和最佳實踐,可以擴展下場景應用。
      【C33.3】五大高手,陣容強大,從頭讀到尾,必有收獲。
      【P474】全書中,代碼34-9(好像)是第一個關鍵字加粗的。
      【C34.x】連橫合縱,天下一統。要是作為上機考試題如何。
      【C35.1】貌似這個例子背景強大,眼楮一亮。過程很Mini。
      【C35.x】過程很Mini,點到為止。
      【C36.x】行,過,有所獲。
      【C37.x】規格模式,AND,OR,NOT的結構是看點。
      【BTW】SSH曾害我找ssh資料費了不少搜商,簡歷上也見到最多。
      【C38.x】MVC火的不得了,略讀。
      【小結】一不小心,看完了,回頭寫總評。
      【2010年04月20日 二 11:20】
      
      13. 終于拿下
      好久沒這麼有壓力,有計劃,有步驟的讀書了。限時讀書是個好套路。
      免費總是有魔力的。看著櫃里間歇冬眠的書,真是非借不能讀也。
      回顧一下讀書過程,9個里程,累計23小時,感覺3個小時一里程效果很好。
      
      書評將要發出,心如跳兔。不是見仁見智,就是賤人賤智,O(∩_∩)O。
      有人的地方就有江湖,有評的地方就有爭辯,評論員不是什麼好差事( ☉ o ☉ )。
      
      最後,支持真原創。大家積極修書立傳,授業解惑。
      
      ---------------------
      更詳細評論參閱︰
      http://www.trydofor.com/a9w3-auhome/trydofor/article/2010/0420133401/body.htm
  •       很言過其實的一本書。
      第一︰作者說了,是用咱們的母語講解設計模式的書,可是每次下定義的時候都先用英文下,然後再用母語重復一遍,估計是為了湊字數的。
      建議︰如果能看懂這本書中的英文,建議直接看HeadFirst Design pattern原版,該書比本書至少要好三個檔次。如果看不懂本書的英文,請看HeadFirst Design pattern的中文版,雖然有很多經典被翻譯糟蹋了,但HeadFirst Design pattern翻譯的還是不錯的。
      
      書中錯誤百出,我昨天稍微翻了翻,就發現幾處很明顯的錯誤︰
      例如第11頁,“直接把sanMao.killEnemy(new Rifle())改為sanMao.killEnemy(new MachineGun()),”簡直不知所雲,原來每開一槍就要換一把搶。
      第217頁,“你要一個研究生,你派了一個高中生給我,那算什麼事”,第一個你應該是我吧,要不你要一個研究生和你派了一個高中生給我有什麼關系。
      還有一些明顯的錯別字。
      
      當然,這種情況的主要責任在編輯。建議以後編輯將主要精力放在提高書籍質量,避免低級錯誤身上。不要光顧吹牛,設計模式的里程碑,按照我的看法只能是四人幫的原著,雖然該書有些晦澀,而且翻譯的很糟糕,但里程碑就是里程碑,不是隨便挑塊石頭就可以當里程碑的。
  •       酒吧以高薪聘“男女公關”為名 騙了廣州市快騰貿易有限公司近百人
       “不許動,統統舉起手來!”3月8日下午2時30分,在深圳南山區粵海街道大沖村的飛馬酒吧內,“內應”偵查
      員配合數十便衣警察,將酒吧內50多名涉案人員全部控制起來。至此,一個以高薪招聘“男女公關”為名的18人詐騙團伙全部落網。
      
      為“兩萬元月薪”
      
      交出500元血汗錢
      
      今年20歲的小林來自江西,在深圳找工作期間看到寫有“內部直招,非中介,免押金”字樣的廣告,一下子就被其“男女公關月薪2萬元”“保安一職不算小費也有2700元工資”的優厚條件吸引住了,于是到約定地點飛馬酒吧面試。
      
      酒吧守門人直至小林報出聯系人賀小姐手機後面4位號碼“9662”的暗號後,才允許其進入酒吧包間接受“面試”。“面試”時,接待人黃某告知小林保安一職已招滿,而經理助理也早有人選了。正當失望的小林準備離去時,黃某改口說︰“現在緊缺的是高級服務員和公關。”
      
      當得知“公關”就是陪富婆聊聊天喝喝酒,一個月能輕松賺三四萬元的職業時,小林毫不猶豫地按要求將身上僅有的500元交了出來,在酒吧里一心等消息。
      
      “入圍者”還要再交
      
      4000元“繼續包裝”
      
      此時,酒吧里突然沖進來數十名便衣警察,把小林嚇了一跳。隨著一句“不許動,統統舉起手來”的大喝,酒吧里兩名“望風”人員、一名“咨客”,酒吧大廳內30余人及“包房”內“面試”的10多人迅速被控制,民警還搜出賬本、傳單、贓款等證據一批。
      
      
      警方在圍捕過程中,酒吧里又先後涌進了15名應聘者。經過辨認、清點、勘查,18名涉嫌詐騙的疑犯無一漏網。
      
      經查,酒吧內存在一個特大的招工詐騙團伙。這個大團伙又分為兩個相互獨立的團伙,其中以王×勇、劉×明等人為首的團伙,以7000元的月租
      租得場地。他們將其中一半場地租給以方×萍、王某等人為首的另一個團伙共同“營業”。
      
      男性應聘者交納300元到1500元不等的“包裝費”後,會被帶到某些夜總會“繞一圈”,然後告知“富婆”沒看上,想要繼續做“公關”,還需交4000元的“繼續包裝費”。而少數容貌姣好的女應聘者則成為“坐台”小姐,大部分女子所交的入職費都落入了詐騙團伙成員的腰包。
      
      據警方初步統計,該團伙總“營業額”在10萬元以上,受騙者多達上百人。
      
  •         讀這本書的起因源于csdn學生大本營的一次活動《設計模式之禪》試讀員招募,身為程序員兼之學生大本營的老師沒有道理不踴躍參加了(參加時可沒走任何後門),佛祖顯靈,真的能有幸成為了試讀員。從得知寄出樣書,居然用了半個多月才拿到手,長了些。卻也將我急切等待讀書的浮躁心情洗滌為一種平和的心情,此時讀這本《設計模式之禪》未嘗不是一件好事,正應了“禪”的心境了。
      
      
        翻開書 贊譽映入眼簾,這麼多還是直奔主題吧,我這人歷來讀書都是先看目錄,讀懂目錄,書也就有機會讀懂了。在參加活動時,在秦少波老師主頁中,簡單閱讀了部分樣章(我這人比較懶,看書還可以,讓我在電腦上看書向來懶惰),作者將要闡述的知識分成了四大塊。從面向對象的6大設計原則入手,逐步演繹了GOF23個設計模式的一招一式,到後來更是演練了一番海陸空聯合作戰(設計模式混編)。每個設計模式用一個小故事引出該模式的定義,隨之展開、深入。結構分塊清晰,正是我喜歡並常建議我的學生學習時采用的學習和思考方式,由原則規矩入手-〉一招一式-〉組合拳。
      
        清楚了這本書的內容的組織結構,閉眼那些知識走馬燈似在腦中過了一遍,設計模式就是這樣啊,禪之何來。往後看下來,不對,不同。章節中深入淺出的故事讓初學者對設計模式通俗易懂;幾句話的定義又將知識點透徹清晰的總結了;而隨之的應用、經驗技巧正是唐三藏要求取的真經啊!!!
      
      快速翻過跳到“第三部分設計模式PK”,慢慢的讀下來,PK相似、PK不同,不是調侃似的PK,不是理論似的PK,好好好,設計模式在心中越來越清晰的勾畫出來。書讀到這里還沒完 ,作者居然在最後的部分增加了幾個“開發項目”。好生動的演練。通過前邊知識的準備,潛移默化的深入再深入地探討了幾個主要模式。
      
      阳春白雪下里巴人。好佩服作者深厚的编程开发功力和文字处理能力,居然在一部书里层次清晰的实现了雅俗共赏。再次闭目冥想,设计模式如春雪入土,慢慢消溶;土中有雪,雪中有土;不着于痕迹——何时悟禅?
      
      初讀,事多,時間緊,未及細讀,很多未及文字,不通處見諒,欲知後事,再讀,再再讀有感時……
      
      
      
  •        我是個剛剛入行半年的小鳥,只讀完了前六章,因為答應了要在收到書的2周內寫出書評,所以斷章取義的寫了些文字....ok, 切入正題:
      
       本書前6章比較詳細的介紹了6大設計原則,相對其他設計模式的書籍而言我覺得這種方式比較能讓我這種小菜鳥入門;作者在每章首先拋出定義,然後是比較有趣實例和一些容易理解的代碼,接著闡述為什麼要用,優缺點和一些經驗建議;但是總感覺有點意猶未盡,換言之我覺得如果能再添加一些點楮之筆那句更好啦,對于這點我覺得<冒號課堂>的文章寫的就不錯(不過T-T太深了,有很多地方我功力不夠...),就個人而言我覺得在闡述優缺點和經驗的地方如果能更深入一些或者說更細致一些就好了 :)
      
       個人覺得如果想掌握一種新的事物,要了解他的定義和後才可能知道這種事物怎麼用,而經過對這種新事物應用並總結優缺點後,才可能真正開始了解這種事物的”價值觀”,才可能無招勝有招.其實之所以提及這個,我覺得設計模式只是一種經驗總結,換句話說,即使你沒看過,也可能自己不知不覺的用過了,問題關鍵就是怎麼去讀懂設計模式的核心思想,因為最近很忙所以就選擇仔細的讀前6章,我認為前六章才是我的重中之重!如果你問我作者是否將這種精煉的思想提取並融入全書中,我暫時還沒法回答,當然也可能是我太菜,不識廬山真面目;等等!難倒這就是作者題目所提及的禪嗎?恩,等讀後面我再好好的體會吧……
      
       嘿嘿,我仔細的看前言了,作為一本將自己多年工作經驗總結,並通過寫成書的方式來共享自己知識,單從這一點,哥們!額,不!前輩,小菜鳥挺感動的,希望以後國內能看到更多類似這類書籍,而不是那些胡亂粘貼的垃圾書籍.呼,可以去睡覺了...
      
  •        實例豐富。全書545頁,很少連著兩面或三頁只見文字不見代碼,實際上基本每頁都有代碼。這些例子是作者九年的工作總結啊,其價值是不言而喻的!
       通俗易懂。先是提出問題,給出一個相對簡單的解決方案,然後不斷完善,循序漸進,層層深入,比如在講工廠模式時,先由女媧造人的神話引出一個簡單工廠的模式,然後根據變化過渡到多個工廠類的模式,再到抽象工廠,用貼近生活的例子和語言娓娓道出高深的模式,讓人感覺自己就像在讀白居易的詩一樣,讓一個不懂設計械的人感受到了學習與設計的快樂。
       客觀、全面。在由淺入深地給出相對完善的模式後,還從優缺兩面進行總結,能讓人有更深的了解。同時,該書的講解是很全面的。比如將唯一的單例擴展成固定數量的“單例”,再如原型模式中,講解了淺拷貝與深拷貝後,還講解了String的特殊性以及clone與final的沖突等,真是知無不言,言無不盡!
       來于現實,最後又回歸現實。來書每章開始都從生活中常見事例引出某類經典問題,當我們懷著好奇之心一步步地看完解決方案後,發現自己已經又學習一種模式了,此時再去看那相對“抽象”的模式的定義,已經感覺不到抽象了。最後,在每章的結束部分,又給出了該運用該模式的具體場景,將讀者的思緒從定義又拉回了現實,給了我們巨大的思考與想象的空間。這也正是我們學習模式的原因啊!
      
  •       從程序員到初涉軟件架構設計,對于我,“設計模式”仿佛從“Hello World”開始就是一個謎,面對完整的項目,復雜的需求,如何設計模型,這的確是一個問題。完美的設計出自對模式的理解和豐富的項目經驗,不得不承認,這需要我們花費很多時間和精力于此,並付諸于實踐中去。
      但是最近筆者閱讀了機械工業出版社的《設計模式之禪》一書,對設計模式的“禪理”娓娓道來,並且有很多精彩的例子做輔,語言平淡直白,通俗易懂,就像是在與深諳其道的朋友聊天。
      縱覽全書,本書分為四部分︰
       設計原則,針對六個設計原則進行闡述,其中不乏經驗之談;
       設計模式演繹,分別描述了23中設計模式,並且每一種都有例程在里邊,每種模式應用的場景被形象的描述出來,比如第十六章的責任鏈模式,形象的用我國古代“三從四德”來舉例,描述責任鏈模式是怎樣應用的,等;
       設計模式比較,分別就創建類模式,結構類模式和行為類模式等進行PK,
       設計模式混編,列舉幾例模式嫁接應用,和MVC框架。
      總之,該書語言平實,實例精準,內容翔實,涵蓋面廣,是軟件設計模式中不可多得的一本書。簡單的幾行文字不足以概括其精妙,還需細細品味。
      
      
  •       很榮幸能成為《設計模式之禪》的試讀員,以前自己也看過一些設計模式的書籍,都是在以導彈火箭作為題材闡述,有兩點,第一、理解非常難,第二,都是抄的,很是郁悶
      抱著嘗試的心態去讀了這本書,因為我自己讀書本身比較慢,所以2周的時間只看到設計模式中的裝飾模式那里。非常想說的一句話是,這本書不是抄的,比較容易理解,
      這本書的結構我很喜歡,從寫代碼和設計代碼的原則入手,直至設計模式到設計模式的混合搭配還有最後的大量設計模式的應用案例,很感謝作者,這本書對我的幫助很大
      
  •       本來應該早些寫出來的,不過最近家里雜事太多,一直抽不出時間了,所以耽擱了,還請大家見諒。
      活動里面說提倡原創,嚇得我都不敢看其他已經貼出來的書評,生怕自己的思路受到影響。
      好了,言歸正傳。
      最深印象︰
       這本書絕對是有深厚編程功底的人才能寫出來的。作者相當的務實,他不是在簡單擺弄理論,而是用自己的實際經驗,用相當切合實際的例子對理論進行深入且深刻的闡述。這些例子不復雜,但確實能夠比較好的說明問題。相信作者在例子的選擇上是很下了一番功夫的。最值得欣賞的是作者是真正的做到了活學活用,而不是讀死書。作者在對理論加以靈活運用的時候真正考慮了讓人糾結的問題︰度的問題。任何理論的運用都有一個度,不及或過之都是欠缺。而對度的把握則是難中之難,因為它沒有可遵循的固定規律,只能依賴個人的經驗和智慧綜合考慮,這是任何機器都做不了的事情。相信大家能夠從作者對度的把握上收益良多。
      閱讀建議︰
       1.如果有一定coding功底,建議看到作者舉出的例子時,先自己加以重構/重新設計,然後再和作者改良後的代碼進行比較。這樣會收益多多。甚至可以在看到作者用漢字描述的例子時,就可以開始嘗試用程序實現,進而作兩次比較,一次代碼抽象原型比較,一次是改善後的代碼的比較。這樣更鍛煉人。
       2.盡信書則無書,適合別人的東西不一定適合你。所以用懷疑的態度去讀書,盡可能嘗試去推翻作者。這樣你才能將作者寫出來的東西變成你自己的東西,也就是做到活學活用。
      
      至于不足之處,呵呵,相對于這本書的優點而言,基本上都可以忽略,而且關于通俗和幽默本身也是一個度的問題,其間的斟酌也是相當費時,所以我也就不再雞蛋里挑骨頭了。
  •     可能是作者的疏漏吧。
  •     竊以為設計模式之禪寫得很好,很幽默,pdf版的
    設計模式也是要一個一個地寫代碼的,光看沒啥作用
  •     設計模式之禪pdf比書上少了相當多的東西,lz可以看一下原書
  •     設計模式之禪是本好書。國人也能寫出好書地
  •     看了幾條書評都是說Head First Design Patterns 比「設計模式之禪」好,本想想買來《設禪》的(目前已經在圖書館把它前面原則設計等前部看完了),搞得我現在都想去看看前者是個怎麼好法咯。
  •     很有煽動性!
    你平時工作會用到設計模式嗎?
  •     兄台,我平時不用,這篇評論是轉的卓越網一位讀者的評論。
  •     個人感覺,絕對槍手!
  •     這位兄弟的評論寫得太精彩了,哈哈,贊一個!
  •     看的我很想讀讀了。。。
  •     這本書多次在當當網斷貨,已經重印多次,繁體版馬上要出版了。
  •     其實,每個軟件在設計者的心中,都是一本小說,一個故事。。還可以說,每個軟件,都是設計者的情人,你正在裝扮她。。
  •     你真厲害,這種書都看完了,這個書我看了1/3之一就看不下去了。
    我不禁想問作者 你真的懂設計麼?
    先不說有沒有把這些思想表達清楚的問題。光從代碼看實在看不出作者有什麼功力,那個皇帝的單例模式,皇帝就多了個name屬性居然使用一個static的arrayList來裝,後面的say和getInstance居然依賴同一個靜態變量,很明顯的邏輯錯誤。
    之後的builder那個例子,N個類公用一個arraylist。。。貌似作者都沒有搞清楚JAVA里傳值和傳引用。
    動態代理那個例子,他居然去繼承一個只有靜態方法的類,真是汗顏。
  •     【C7.5】單例會被JVM的GC麼?何種情況,理論依據或證據呢?豆腐認為有Ref就不GC。
    對的,這個話我也很懷疑。我估計作者可能是做WEB開發的時候,和SESSION的有效時間搞起來了,session長時間不用(默認是30分鐘吧),session會失效。
  •     这书名字和推荐太霸气,囧。
  •     回復zizi的問題︰
    謝謝您對本書的關注,關于您提到的這個問題,您的理解可能欠妥當,建議您看一下JVM的垃圾回收機制,相信您會有更大的收獲。在jvm中任何一個未被引用的實例對象都會被垃圾回收器(GC)回收,單例也不例外。一旦一個單利對象被回收,重新建立引用時,所有靜態變量或實例變量都會重新初始化。這與session有很大的差別,session的生命期是確定的(比如最後一次activate後30分鐘),不管有沒有被訪問。
    sun網站相似的介紹︰http://java.sun.com/developer/technicalArticles/Programming/singletons/ 。
  •     回復zizi的問題︰
    “那個皇帝的單例模式”,這是在講有上限的多例模式(Multiton pattern),小生愚笨,實在沒理解您的意思,或者說您有更好的實現有上限的多例模式?
    “之後的builder那個例子”,糾正您一個問題,Java是以傳值的方式傳遞引用。
    “動態代理那個例子”,子類是對父類的業務細化和深度擴展,SubjectDynamicProxy出現在與業務有關的代理類中,當然是AOP就不再此考慮之列。
  •     回復 《設計模式之禪》作者︰
       其他例子我也不想說了,先看“多例模式(Multiton pattern)”的代碼
      public static Emperor getInstance(){
       Random random = new Random();
       countNumOfEmperor = random.nextInt(maxNumOfEmperor); //隨機拉出一個皇帝,只要是個精神領袖就成
       return emperorList.get(countNumOfEmperor);
       }
      
      //皇帝發話了
       public static void say(){
       System.out.println(nameList.get(countNumOfEmperor));
       }
      
      首先,say是皇帝實例的行為,為什麼是STATIC?
      第二 name是皇帝實例的一個屬性,一個實例變量就行了,為什麼要用個
      共用的static list去存?這樣做是不是要額外的多一個值去記錄每個皇帝實例對應的在這個nameList里的數字。
      
      問題三︰問題是你還沒保存第2點的那個數字,你用了一個靜態變量去保存,也就是說say 如果緊接著getinstance調用是不會出錯的,但是順序一變這個代碼馬上就要出錯,(如果getinstance調了兩次,那麼兩個實例每個實例再掉say那可能會是同一句話)作為一個系統的設計,你怎麼能去預料用戶調用方法的順序?
      
      
      [“之後的builder那個例子”,糾正您一個問題,Java是以傳值的方式傳遞引用。]
      你builder的例子 所有的sequence都指向同一個引用,我也真是服了,這個問題和你皇帝的問題性質相同。
      
      
      請你再仔細看看你的代碼,有些地方(限前1/3)有明顯的邏輯錯誤。
      
      PS︰謝謝你的http://java.sun.com/developer/technicalArticles/Programming/singletons/ 。
  •     >http://java.sun.com/developer/technicalArticles/Programming/singletons/
    這個收下了,謝謝。
    如果出下一版書,請在參考資料里把URL加上吧,對讀者有意。
  •     技術是越辯越明,希望大家在交流技術的同時也能成為好朋友,哈哈。
  •     鼓不打不響,理不辨不明。哈哈,希望繼續多出好書。
  •     這個人家說的是jdk1.2以前的情況,現在的jvm不會出現這種情況了
    有靜態變量引用,gc就不會回收了
  •     那個ocp里面的書店的例子, 今天打個折來個繼承,明天來個買一送一也來個繼承, 萬一又打折又送書怎麼辦? 我覺得應該用decorator包起來,靈活很多
  •     還有你那個工廠方法模式的例子根本不對阿,你的例子只是加了接口的簡單工廠而已
    工廠方法是類行為模式,是將行為延遲到子類,具體實例化哪個產品由子類決定,
    你所謂的多工廠才是真正的工廠方法, 怎麼隨便定義名詞哦!
  •     build 模式里 每個builder 每次都build同一個實例阿,就是那個成員變量, 暈死, 這樣跑10000遍還是跑得同一輛車阿! 這錯誤好多哦。。。
  •     對的 那個工廠方法就是為了屏蔽CLASS,他居然用CLASS來反射創建..
    還有COMMAND模式,那個receiverClass,原文明確說是ANYCLASS...書中居然說這個需要抽一個接口...那這個東西本身就是COMMAND接口.
    書中對于實例的使用是要用的時候隨便NEW...反正CLASS里放著一個靜態成員變量.感覺寫的是設計模式但是貌似OOh愛美弄清楚..
  •     本來想買的....看完評論,保持觀望
  •     這位朋友的書評寫得很中肯,很實在,贊一個!
    尤其是您提出的2個閱讀建議,我個人覺得非常好,打算讀這本書的朋友可以參考一下。
  •     呵呵, 謝謝!

类似《設計模式之禪》的图书资源

 

計算機與互聯網 PDF免费下载,軟件工程及軟件方法學PDF免费下载。 计算机教程网 

计算机教程网 @ 2017