出版社: 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.沃森研究中心的研究人员。
丛书信息
喜欢读"Design Patterns"的人也喜欢的电子书 · · · · · ·
喜欢读"Design Patterns"的人也喜欢 · · · · · ·
Design Patterns的话题 · · · · · · ( 全部 条 )



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


是一本需要经常参考并不断实践的书
这篇书评可能有关键情节透露
这本书的中文版2000上年大学时就看过,后来机工出了影印版就买了一本。说实话这不是一本看完一遍就可以扔掉的书,它需要你不断实践,每次翻一下都有新的收获。 (展开)
看了30遍后至今没再看
> 更多书评83篇
读书笔记 · · · · · ·
我来写笔记-
左岸咖啡 (迷茫的时候就想读读芒格的语录)
责任链模式与if-else 这个模式对于繁琐的if-else判断非常好用,也比较适合写框架代码。 1、首先if-else会让代码变得丑陋,模块与流程耦合,对于复杂的判断直接影响主业务流程,不利于扩展。 2、引入链(chain)则是让模块与流程解耦,如果A不能做,就让B做,依次类推。 举个例子,对于一个公司采购的审批,比如金额在1000以内让经理审批,1000-5000之前让主管审批。。。可以用if-else写,当然也可以用责任链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写,当然也可以用责任链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写,当然也可以用责任链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
在哪儿买这本书 · · · · · ·
-
当当网
675.18 元
电子书加价购-默认促销
- > 查看1家网店价格 (675.18 元起)
在哪儿借这本书 · · · · · ·
这本书的其他版本 · · · · · · ( 全部7 )
- 机械工业出版社版 2000-9 / 3676人读过 / 有售
- 机械工业出版社版 2002-3-1 / 293人读过
- 机械工业出版社版 2007年3月1日 / 141人读过
- Pearson Education版 2000 / 29人读过
以下豆列推荐 · · · · · · ( 全部 )
- 程序员最应该读的图书(原版) (hongqn)
- 【C/C++学习指南】 (小李飞刀)
- 軟件工程 (Milo)
- Quantitative Finance Books (海若)
- Reading Radar by ThoughtWorks (ggarlic)
谁读这本书?
二手市场
- > 点这儿转让 有650人想读,手里有一本闲着?
订阅关于Design Patterns的评论:
feed: rss 2.0
0 有用 黯淡蓝点 2017-08-22
The gang of four elevates the art of tools to a magnificent philosophical level.
0 有用 坏人C 2017-11-28
比Head First那本高到不知道哪里去了
0 有用 丸子(^.^)v 2010-09-30
设计模式的经典~
0 有用 Creasy 2016-07-15
A must read for all software engineers. It did not make much sense when I read it at school, but made tons of sense now
0 有用 米子 2016-01-11
An amazingly handy handbook for conceptualizing and developing design patterns.
0 有用 绿袜子 2019-02-14
范例有点过时了.. https://refactoring.guru/design-patterns更通俗易懂 强推!
0 有用 Fr.dmg 2018-12-20
作教材用,教授带着我们批判性地读,看哪些过时了,哪些可以改进。但总的来说高屋建瓴,发人深省。
0 有用 lennonwoo 2018-07-20
第二章例子就值10分
0 有用 fu_gangqiang 2018-01-14
果然是好书, 一本薄书,一种讲解模式,叙述20种精选设计模式,又夹杂各种经典实例。
0 有用 黯淡蓝点 2017-08-22
The gang of four elevates the art of tools to a magnificent philosophical level.