Java設計模式

內(nèi)容概要

本書通過一個完整的Java項目對經(jīng)典著作Design
Patterns一書介紹的23種設計模式進行了深入分析與講解，實踐性強，卻又不失對模式本質(zhì)的探討。本書創(chuàng)造性地將這些模式分為5大類別，以充分展現(xiàn)各個模式的重要特征，并結合UML類圖與對應的Java程序，便于讀者更好地理解。全書給出了大量的練習，作為對讀者的挑戰(zhàn)，以啟發(fā)思考，督促讀者通過實踐練習的方式來掌握設計模式。同時，作者又給出了這些練習的參考答案，使讀者可以印證比較，找出自己的不足，提高設計技能。

作者簡介

作者：（美國）史蒂芬?約翰?梅特斯克（Steven John Metsker） （美國）威廉?維克（William C.Wake） 譯者：張逸 史磊  梅特斯克（Steven John Metsker）是Dominion Digital公司的管理顧問，該公司負責信息技術與商業(yè)過程的重新設計。Steven擅長運用面向?qū)ο蠹夹g構建結構清晰、功能強大的軟件系統(tǒng)。他還是Building Parsers with JavaTM、Design Pattern JavaTM Workbook與Design Patterns in C#（皆由Addison—Wesley出版）等著作的作者。 維克（William C.Wake）是一名獨立軟件咨詢師、教練和培訓講師，他擁有超過二十年的軟件開發(fā)經(jīng)驗。William C.Wake先后任職于Capital One Financial、DMR Trecom與VTLS。他Refactoring Workbook與ExtremeProgramming Explored（皆由Addison—Wesley出版）等著作的作者。

書籍目錄

序xv
第1章 緒論1
為何需要模式1
為何需要設計模式2
為何選擇Java3
UML3
挑戰(zhàn)4
本書的組織4
歡迎來到Oozinoz公司6
小結6
第1部分 接口型模式
第2章 接口型模式介紹8
接口與抽象類8
接口與職責10
小結11
超越普通接口12
第3章 適配器（Adapter）模式13
接口適配13
類與對象適配器17
JTable對數(shù)據(jù)的適配20
識別適配器24
小結25
第4章 外觀（Facade）模式27
外觀類、工具類和示例類27
重構到外觀模式29
小結38
第5章 合成（Composite）模式39
常規(guī)組合39
合成模式中的遞歸行為40
組合、樹與環(huán)42
含有環(huán)的合成模式47
環(huán)的影響50
小結51
第6章 橋接（Bridge）模式52
常規(guī)抽象：橋接模式的一種方法52
從抽象到橋接模式54
使用橋接模式的驅(qū)動器57
數(shù)據(jù)庫驅(qū)動57
小結59
第2部分 職責型模式
第7章 職責型模式介紹62
常規(guī)的職責型模式62
根據(jù)可見性控制職責64
小結65
超越普通職責65
第8章 單例（Singleton）模式67
單例模式機制67
單例和線程68
識別單例70
小結71
第9章 觀察者（Observer）模式72
經(jīng)典范例：GUI中的觀察者模式72
模型/視圖/控制器76
維護Observable對象82
小結84
第10章 調(diào)停者（Mediator）模式85
經(jīng)典范例：GUI調(diào)停者（Mediator）85
關系一致性中的調(diào)停者模式89
小結96
第11章 代理（Proxy）模式97
經(jīng)典范例：圖像代理97
重新思考圖片代理102
遠程代理104
動態(tài)代理109
小結114
第12章 職責鏈（Chain of Responsibility）模式115
現(xiàn)實中的職責鏈模式115
重構為職責鏈模式117
固定職責鏈119
沒有組合結構的職責鏈模式121
小結121
第13章 享元（Flyweight）模式122
不變性122
抽取享元中不可變的部分123
共享享元125
小結128
第3部分 構造型模式
第14章 構造型模式介紹130
構造函數(shù)的挑戰(zhàn)130
小結132
超出常規(guī)的構造函數(shù)132
第15章 構建者（Builder）模式134
常規(guī)的構建者134
在約束條件下構建對象137
可容錯的構建者139
小結140
第16章 工廠方法（Factory Method）模式141
經(jīng)典范例：迭代器141
識別工廠方法142
控制要實例化的類143
并行層次結構中的工廠方法模式145
小結147
第17章 抽象工廠（Abstract Factory）模式148
經(jīng)典范例：圖形用戶界面工具箱148
抽象工廠和工廠方法153
包和抽象工廠157
小結157
第18章 原型（Prototype）模式158
作為工廠的原型158
利用克隆進行原型化159
小結162
第19章 備忘錄（Memento）模式163
經(jīng)典范例：使用備忘錄模式執(zhí)行撤銷操作163
備忘錄的持久性170
跨會話的持久性備忘錄170
小結174
第4部分 操作型模式
第20章 操作型模式介紹176
操作和方法176
簽名177
異常178
算法和多態(tài)179
小結180
超越常規(guī)的操作181
第21章 模板方法（Template Method）模式182
經(jīng)典范例：排序182
完成一個算法186
模板方法鉤子188
重構為模板方法模式189
小結191
第22章 狀態(tài)（State）模式193
對狀態(tài)進行建模193
重構為狀態(tài)模式197
使狀態(tài)成為常量201
小結203
第23章 策略（Strategy）模式204
策略建模204
重構到策略模式207
比較策略模式與狀態(tài)模式211
比較策略模式和模板方法模式211
小結212
第24章 命令（Command）模式213
經(jīng)典范例：菜單命令213
使用命令模式來提供服務216
命令鉤子217
命令模式與其他模式的關系219
小結220
第25章 解釋器（Interpreter）模式221
一個解釋器示例221
解釋器、語言和解析器233
小結234
第5部分 擴展型模式
第26章 擴展型模式介紹236
面向?qū)ο笤O計的原則236
Liskov替換原則237
迪米特法則238
消除代碼的壞味道239
超越常規(guī)的擴展240
小結241
第27章 裝飾器（Decorator）模式242
經(jīng)典范例：流和輸出器242
函數(shù)包裝器250
裝飾器模式和其他設計模式的關系257
小結258
第28章 迭代器（Iterator）模式259
普通的迭代259
線程安全的迭代261
基于合成結構的迭代267
小結277
第29章 訪問者（Visitor）模式278
訪問者模式機制278
常規(guī)的訪問者模式280
Visitor環(huán)286
訪問者模式的危機290
小結292
附錄A 指南293
附錄B 答案297
附錄C Oozinoz源代碼366
附錄D UML概覽369
參考文獻375

章節(jié)摘錄

版權頁：   插圖：   假設其他的開發(fā)者編寫了一個方法，用來查詢車間里所有機器擁有的原料桶的集合。一旦訪問到卸載緩沖池，如果unloadBuffer類的9etTubs0方法拋出異常，這段代碼就會出現(xiàn)問題。這嚴重違反了LSP：當你將unloadBuffer對象當做Machine對象來使用時，程序可能會崩潰！假設不拋出異常，我們需要簡單地忽略對unloadBuffer類中9etTubs0和addTubO的調(diào)用。這一做法依然違反了LSP，因為在你給機器添加一個原料桶時，這個原料桶可能會消失！ 違反LSP并不一定是設計缺陷。針對Oozinoz公司的這種情況，需要權衡一下，讓Machi ne類擁有大多數(shù)機器的行為和違反LSP原則，究竟哪個價值更大。重要的一點是意識到LSP，并且清楚為什么其他設計可能違反了LSP。 迪米特法則 在20世紀80年代后期，美國東北大學Demeter Project的成員嘗試編輯了一些規(guī)則，用于確保健康的面向?qū)ο缶幊?。項目團隊將這些規(guī)則稱為迪米特法則（Law ofDemeter，LoD）。KarlLieberherr和Ian Holland在Assuring Good Style for Object—Oriented Programs一文中全面地總結了這一規(guī)則。聲明認為：非正式地說，迪米特法則要求每個方法只能給有限的對象發(fā)送消息，包括參數(shù)對象、[this]偽變量，以及[this]的直接子部分。文章隨后給出了該法則的正式定義。相對于完全理解迪米特法則的意圖，識別設計是否違反該法則更加容易。 假設你有一個Material Manager對象，該對象有一個方法接收一個Tub對象作為參數(shù)。Tub對象有一個Location屬性，該屬性返回一個Machi ne對象，用以表示桶被放在哪個位置。假設在Material Manager的方法中，想要知道機器是否可用，你可能會寫如下代碼： 如果這個挑戰(zhàn)僅僅讓你覺得形如a.b.c的表達式是錯誤的，那就降低了迪米特法則的價值。事實上，Lieberherr和Holland希望迪米特法則能夠進一步確定無誤地回答這樣的問題：是否可以遵循某種公式或法則來寫出更好的面向?qū)ο蟪绦?？這篇闡釋迪米特法則的早期論文非常值得我們拜讀。就像Liskov替換原則一樣，如果知道并遵循這些規(guī)則，它就會幫助你寫出更好的代碼，一旦你的設計違背了這些原則，就能夠及時獲知。 你會發(fā)現(xiàn)，遵循這些指導原則，擴展性就能夠自然而然產(chǎn)生好的代碼。但是，對于很多開發(fā)者而言，面向?qū)ο蟮拈_發(fā)依然是一門藝術。對代碼庫的藝術擴展源于藝術家們的實踐，而這些大師們依然在不斷地改進他們的藝術。重構就是諸多技藝中的一種工具，它可以在不改變既有功能的前提下，改善代碼的質(zhì)量。 消除代碼的壞味道 你可能寄希望于Liskov替換原則與迪米特法則，能夠永遠地防止你寫出拙劣的代碼。不過，更實際的做法是運用這些準則來幫助發(fā)現(xiàn)代碼的壞味道，然后修復它。這是一種通用的實踐：先寫出可工作的代碼，然后找出代碼的問題，并且修復它，以提升代碼質(zhì)量。但是該如何準確地識別問題呢？答案就是找到代碼的壞味道。在Refactoring：Improving the Design of ExitingCode（由Fowler等人在1999年編寫）一書中描述了22種壞味道，并給出了相應的重構手法。

編輯推薦

《Java設計模式(第2版)》適合各個層次的Java開發(fā)人員與設計人員閱讀，也可以作為學習Java與設計模式的參考讀物或教材。

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    Java設計模式 PDF格式下載

---