出版社: Addison Wesley
副标题: elements of reusable object-oriented software
出版年: 1994-10-31
页数: 416
定价: GBP 47.99
装帧: Hardcover
丛书: Addison-Wesley Professional Computing Series
ISBN: 9780201633610
内容简介 · · · · · ·
* Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalog of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselve...
* Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalog of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselves. * The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently.
作者简介 · · · · · ·
四位作者均是国际公认的面向对象软件领域的专家。
Erich Gamma博士是瑞士苏黎士国际面向对象技术软件中心的技术主管。
Richard Helm博士是澳大利亚悉尼IBM顾问集团公司面向对象技术公司的成员。
Ralph Johnson博士是Urbana-Champaign伊利诺大学计算机科学系成员。
John Vlissides博士是位于纽约Hawthorne的IBN托马斯J.沃森研究中心的研究人员。
目录 · · · · · ·
Foreword
Guide to Readers
1. Introduction
1.1. What Is a Design Pattern?
1.2. Design Patterns in Smalltalk MVC
· · · · · · (更多)
Foreword
Guide to Readers
1. Introduction
1.1. What Is a Design Pattern?
1.2. Design Patterns in Smalltalk MVC
1.3. Describing Design Patterns
1.4. The Catalog of Design Patterns
1.5. Organizing the Catalog
1.6. How Design Patterns Solve Design Problems
1.7. How to Select a Design Pattern
1.8. How to Use a Design Pattern
2. A Case Study: Designing a Document Editor
2.1. Design Problems
2.2. Document Structure
2.3. Formatting
2.4. Embellishing the User Interface
2.5. Supporting Multiple Look-and-Feel Standards
2.6. Supporting Multiple Window Systems
2.7. User Operations
2.8. Spelling Checking and Hyphenation
2.9. Summary
Design Pattern Catalog
3. Creational Patterns
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Discussion of Creational Patterns
4. Structural Patterns
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Discussion of Structural Patterns
5. Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Discussion of Behavioral Patterns
6. Conclusion
6.1. What to Expect from Design Patterns
6.2. A Brief History
6.3. The Pattern Community
6.4. An Invitation
6.5. A Parting Thought
A. Glossary
B. Guide to Notation
C. Foundation Classes
Bibliography
Index
· · · · · · (收起)
丛书信息
喜欢读"Design Patterns"的人也喜欢 · · · · · ·
Design Patterns的话题 · · · · · · ( 全部 条 )



Design Patterns的书评 · · · · · · ( 全部 84 条 )


是一本需要经常参考并不断实践的书
这篇书评可能有关键情节透露
这本书的中文版2000上年大学时就看过,后来机工出了影印版就买了一本。说实话这不是一本看完一遍就可以扔掉的书,它需要你不断实践,每次翻一下都有新的收获。 (展开)
看了30遍后至今没再看
> 更多书评 84篇
读书笔记 · · · · · ·
我来写笔记-
左岸咖啡 (迷茫的时候就想读读芒格的语录)
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链 public class UglyP...2012-12-03 17:58 1人喜欢
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链
public class UglyPurchasePowerHandler { private PurchaseRequest request; public UglyPurchasePowerHandler(PurchaseRequest request) { this.request = request; } public void doHandler(PurchaseRequest request) { double totalAmount = request.getAmount(); if (totalAmount <= 1000) { System.out.println("your purchase request will send to manager!"); } else if (totalAmount > 1000 && totalAmount <= 5000) { System.out.println("your purchase request will send to director!"); } else { System.out.println("your purchase request can't be approved!"); } } public PurchaseRequest getRequest() { return request; } public void setRequest(PurchaseRequest request) { this.request = request; } }
代码里面使用分支判断,这样做的弊端就是doHandler里面处理了所有的逻辑判断,将来扩展的时候要在这里面加入,其实这里面每一个分支判断就是一个不同的流程,对应不能的角色,完全可以分开,而主流程就是调用handler并且传递。
@Override public void doHandler() { if (request.getAmount() <= 1000) { System.out.println("your purchase request will send to manager!"); } else if (null != successorHandler) { successorHandler.doHandler(); } }
上面是一个manager角色的handler。代码调用区别见下面
public class PurchaseHandlerTest { public static void main(String[] args) { PurchaseRequest request = new PurchaseRequest(2000, "test"); UglyPurchasePowerHandler handler = new UglyPurchasePowerHandler(request); handler.doHandler(request); ////////////////////////////////////////////////// DefaultPurchaseHandler defaultHandler = new DefaultPurchaseHandler(null, request); DirectorPurchaseHandler directorHandler = new DirectorPurchaseHandler(defaultHandler, request); ManagerPurchaseHandler managerHandler = new ManagerPurchaseHandler(directorHandler, request); managerHandler.doHandler(); } }
解耦,关键是解耦,利于扩展。比如将来需要增加角色审批,加一个handler,不需要修改主业务流程。 优点:对于分支比较多的流程建议采用这种方式,加了分支后也仅仅是增加一节“链”,调用流程不会修改,这样也方便单元测试 缺点:代码量增加,增加一个handler需要增加一个类。 当handler变多时最好抽象出模版方法,减少重复代码。
回应 2012-12-03 17:58
-
左岸咖啡 (迷茫的时候就想读读芒格的语录)
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链 public class UglyP...2012-12-03 17:58 1人喜欢
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链
public class UglyPurchasePowerHandler { private PurchaseRequest request; public UglyPurchasePowerHandler(PurchaseRequest request) { this.request = request; } public void doHandler(PurchaseRequest request) { double totalAmount = request.getAmount(); if (totalAmount <= 1000) { System.out.println("your purchase request will send to manager!"); } else if (totalAmount > 1000 && totalAmount <= 5000) { System.out.println("your purchase request will send to director!"); } else { System.out.println("your purchase request can't be approved!"); } } public PurchaseRequest getRequest() { return request; } public void setRequest(PurchaseRequest request) { this.request = request; } }
代码里面使用分支判断,这样做的弊端就是doHandler里面处理了所有的逻辑判断,将来扩展的时候要在这里面加入,其实这里面每一个分支判断就是一个不同的流程,对应不能的角色,完全可以分开,而主流程就是调用handler并且传递。
@Override public void doHandler() { if (request.getAmount() <= 1000) { System.out.println("your purchase request will send to manager!"); } else if (null != successorHandler) { successorHandler.doHandler(); } }
上面是一个manager角色的handler。代码调用区别见下面
public class PurchaseHandlerTest { public static void main(String[] args) { PurchaseRequest request = new PurchaseRequest(2000, "test"); UglyPurchasePowerHandler handler = new UglyPurchasePowerHandler(request); handler.doHandler(request); ////////////////////////////////////////////////// DefaultPurchaseHandler defaultHandler = new DefaultPurchaseHandler(null, request); DirectorPurchaseHandler directorHandler = new DirectorPurchaseHandler(defaultHandler, request); ManagerPurchaseHandler managerHandler = new ManagerPurchaseHandler(directorHandler, request); managerHandler.doHandler(); } }
解耦,关键是解耦,利于扩展。比如将来需要增加角色审批,加一个handler,不需要修改主业务流程。 优点:对于分支比较多的流程建议采用这种方式,加了分支后也仅仅是增加一节“链”,调用流程不会修改,这样也方便单元测试 缺点:代码量增加,增加一个handler需要增加一个类。 当handler变多时最好抽象出模版方法,减少重复代码。
回应 2012-12-03 17:58
-
左岸咖啡 (迷茫的时候就想读读芒格的语录)
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链 public class UglyP...2012-12-03 17:58 1人喜欢
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链
public class UglyPurchasePowerHandler { private PurchaseRequest request; public UglyPurchasePowerHandler(PurchaseRequest request) { this.request = request; } public void doHandler(PurchaseRequest request) { double totalAmount = request.getAmount(); if (totalAmount <= 1000) { System.out.println("your purchase request will send to manager!"); } else if (totalAmount > 1000 && totalAmount <= 5000) { System.out.println("your purchase request will send to director!"); } else { System.out.println("your purchase request can't be approved!"); } } public PurchaseRequest getRequest() { return request; } public void setRequest(PurchaseRequest request) { this.request = request; } }
代码里面使用分支判断,这样做的弊端就是doHandler里面处理了所有的逻辑判断,将来扩展的时候要在这里面加入,其实这里面每一个分支判断就是一个不同的流程,对应不能的角色,完全可以分开,而主流程就是调用handler并且传递。
@Override public void doHandler() { if (request.getAmount() <= 1000) { System.out.println("your purchase request will send to manager!"); } else if (null != successorHandler) { successorHandler.doHandler(); } }
上面是一个manager角色的handler。代码调用区别见下面
public class PurchaseHandlerTest { public static void main(String[] args) { PurchaseRequest request = new PurchaseRequest(2000, "test"); UglyPurchasePowerHandler handler = new UglyPurchasePowerHandler(request); handler.doHandler(request); ////////////////////////////////////////////////// DefaultPurchaseHandler defaultHandler = new DefaultPurchaseHandler(null, request); DirectorPurchaseHandler directorHandler = new DirectorPurchaseHandler(defaultHandler, request); ManagerPurchaseHandler managerHandler = new ManagerPurchaseHandler(directorHandler, request); managerHandler.doHandler(); } }
解耦,关键是解耦,利于扩展。比如将来需要增加角色审批,加一个handler,不需要修改主业务流程。 优点:对于分支比较多的流程建议采用这种方式,加了分支后也仅仅是增加一节“链”,调用流程不会修改,这样也方便单元测试 缺点:代码量增加,增加一个handler需要增加一个类。 当handler变多时最好抽象出模版方法,减少重复代码。
回应 2012-12-03 17:58
论坛 · · · · · ·
原版经典 | 来自Yuan Mai | 1 回应 | 2021-02-21 |
想买本英文版的练练英文水平 | 来自红尘陌客 | 1 回应 | 2020-09-06 |
这本书的其他版本 · · · · · · ( 全部8 )
-
机械工业出版社 (2000)9.1分 3975人读过
-
机械工业出版社 (2002)9.4分 305人读过
-
机械工业出版社 (2007)9.2分 144人读过
-
Pearson Education (2000)9.2分 32人读过
在哪儿借这本书 · · · · · ·
以下书单推荐 · · · · · · ( 全部 )
谁读这本书?
二手市场
订阅关于Design Patterns的评论:
feed: rss 2.0
0 有用 prowyh 2009-02-27
Classic!
1 有用 黯淡蓝点 2017-08-22
The gang of four elevates the art of tools to a magnificent philosophical level.
2 有用 [已注销] 2012-08-04
虽然只是挑了几个章节来读,但已经确定这是读过的关于设计模式的书籍中相当好的一本。不像外国的头大系列,也不像国内大话系列,那些都太浮夸了。这本就是那么的简明•实用!
1 有用 Theme 2012-06-11
如果觉得收获不大,可以看看:addison wesley出版的applying uml and patterns - an introduction to object-oriented analysis。根据这个书做了一个图文混排编辑器,支持多columns,还是有收获的。
0 有用 坏人C 2017-11-28
比Head First那本高到不知道哪里去了
0 有用 法外狂徒ZS 2021-01-14
看我发现了什么。。Why calls this book `Gang of Four`? 真是一本伟大的书。如果可以我愿意给4.5星。
0 有用 万千旅途的开始 2021-01-08
用不上。我没有写一个完整app的经历,也没有写过任何库。脱离了实践的知识真的很难记住。如果一个人没有用过筷子,任他人仔细描述,它也是无法学会的。
0 有用 绿树荫 2020-05-18
配合head first那本食用效果应该更佳
0 有用 呼吸碱中毒 2020-05-11
together with azure design patterns that focus more on availability, efficiency and security
0 有用 [已注销] 2020-04-04
我們當年都叫它《輪子大全》,全方位地告訴你怎麼造輪子⋯⋯用做一個文字編輯器為例,系統講述了為什麼要造輪子,怎麼造輪子。全書寫作語言非常學術,旁證博引,外加很多不知道的計算機遠古時期的知識。力推。 @2017-07-11 17:18:02