Java設(shè)計模式

內(nèi)容概要

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

作者簡介

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

章節(jié)摘錄

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

編輯推薦

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

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    Java設(shè)計模式 PDF格式下載

---