这本书是我见过的讲述敏捷设计、开发书籍中最棒的一本!尤其是前半部分中OOP设计原则的讲述,非常佩服Bob大叔对设计原则的总结。后半部分感觉涉及到细节太繁琐了就没看完,不过这无损于这本名著的光芒!这本书可以和其它讲述设计模式的相关书籍一起阅读,相得益彰。
读书笔记:
第一部分 敏捷宣言
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
第二部分 敏捷设计
腐化的设计
僵化性(Rigidity):难以对系统进行修改
脆弱性(Fragility):改动一个地方,程序许多地方出现问题
牢固性(Immobility):很难解开系统的纠结
粘滞性(Viscosity):做错误的事情容易,做正确的事情困难
不必要的复杂性(Needless Complexity):过度设计,为过多的可能性做准备
不必要的重复(Needless Repetition):重复的代码,开发人员忽视的抽象
晦涩性(Opacity):难以阅读、理解,没有用清晰、富有表达力的代码来体现意图
需求总是处在持续变动中,加速了代码腐化
运用抽象来封装变化Open-Closed Principle
OOP设计原则:
一,SRP 单一职责原则(Single Responsibility Princip)
就一个类而言,应该仅有一个引起它变化的原因
高内聚、低耦合
Facade模式、PROXY模式
二,OCP 开放-封闭原则(Open-Closed Principle)
软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改
对扩展开放(Open for extension):对模块进行扩展,使其满足那些改变的新行为
对更改封闭(Closed for modification):不必改动模块的源代码或二进制文件
抽象、多态
Strategy模式、Template Method模式,
三,LSP Liskov替换原则(Liskov Substitution Principle)
子类型必须能够替换掉它们的基类型
IS-A继承
从使用者角度来审视API
契约式设计(Design By Contract):通过为每个方法声明前置条件和后置条件来指定契约
LSP是使OCP成为可能的主要原则之一
子类型的正确含义是“可替换的”
四,DIP 依赖倒置原则(Depend Invert Princip)
高层模块不应该依赖于低层模块,二者都应该依赖于抽象
抽象不应该依赖于实现细节,实现细节应该依赖于抽象
如果高层模块独立于低层模块,那么高层模块就可以非常容易地被重用。该原则是FrameWork设计的核心原则:依赖于抽象
Don't call us,we will call you.低层模块实现了在高层模块中声明的接口,这些接口被高层模块调用
把不稳定的具体类隐藏在抽象接口后面,可以隔离它们的不稳定性
OOP设计倒置了依赖关系结构,使得细节和策略都依赖于抽象
Template Method模式,Bridge模式
五,ISP 接口隔离原则(Least Knowledge Principle)
不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
客户程序看到的应该是多个具有内聚接口的抽象基类
客户程序应该仅仅依赖于它们实际调用的方法
Facade模式
第三部分 薪水支付案例研究
Command模式:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操作。
命令模式就是把一些具体的命令封装成一些具体的类,这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行,完成一个具体的业务流程。它的优点是:解耦了发送者与接收者之间的联系。发送者调用一个操作,接收者接受请求执行具体类相应的动作。因为使用Command模式解耦,发送者无需知道接受者任何接口。
比如说,对文件进行操作,如打开、关闭、打印。正常的操作就是用户点击“打开”按纽,就执行打开命令,在按纽的单击事件中写个方法就可以了。但如要应用Command模式,就要把其抽象出接口,把这三个操作封装成单独的类。
Template Method模式:定义一个操作中的算法骨架,而将一些步骤延迟到子类中。Template Method模式使得子类可以不改变算法的结构即可重新定义该算法的某些特定步骤。(继承)
Strategy模式:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换。Strategy模式使得算法可以独立于使用它们的客户而变化。(委托)
Facade模式:为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口,这个高层接口使得这一子系统更加容易使用。
Mediator模式:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
Singleton模式:保证一个类仅有一个实例,并提供一个全局访问点。通过使用私有构造函数,静态变量和一个静态访问方法来实现。
MonoState模式:构造函数声明为public,而将类中所有的字段声明为static。MonoState并不限制创建对象的个数,但是它的状态却只有一个状态。
NULL Object模式:提供一个给定类型的NULL Object对象,用以代替这个对象为null的情况,简化代码。
非常好的敏捷设计书籍
《敏捷软件开发》热门书评
-
好书不代表是好教材
18有用 3无用 总很有神叔 2009-11-16
好的技术书籍的标准是通俗易懂;文字精炼;耐读,有吸引力;有思想性。uncle bob的书写功力有目共睹,而且他的技术修为也绝对无人质疑。因此他写的这本书秉承了他一贯的优势。符合所有好处所具备的条件。所有我们可以毫无内疚的宣称,“这本书是我见过最好的书”。孟岩作序,也为这本书的推广添砖加瓦。在序中他表...
-
又一本设计模式
12有用 8无用 optman 2007-07-23
看到前面有评论说,此书与敏捷的关系不大,颇有同感。所谓敏捷,那就是代码先写了再说,且看我们是如何做到,这就是读了这本书的感受。中文版没有把特定的英文缩写在第一次引用时列出来(只能在后面的索引表里找到),让我很不爽,比如DIP和SRP。不过,说到底还是中文看得快,比看小说都快。本书的一大特点就是浅显,...
-
这本书里有一个爱情故事!
5有用 7无用 LipingTaBaBa 2009-02-13
孟岩为这本书写了一个代序.这个代序很长,有两页半,其中一页半用来讲述孟岩本人和这本书的感情纠葛.我为大家复述一下这段感人至深的故事.下面孟先生代表孟岩,小doocaubm和Asd代表什么,请您自己判断.2001年秋天,北京,孟先生那时候已经颇有些成就了,见识也颇有些广泛了,但是他碰见doocaubm...
-
模式案例书
5有用 0无用 一格 2011-01-13
敏捷软件开发提倡测试先行,设计适应要求,迭代式渐进开发。一、通过用例来确认需求,分析软件行为:针对用例中的事物对象建立合理的类结构;分析用例中类似情形的变化因素,尽量用抽象来统一一类变化,由此建立系统的大致静态结构。在此不需要、也很难确定好系统的最终结构,因为还没有实际的类交互,还不能很好明确此时的...
-
java晋级绝对推荐
3有用 4无用 pesome 2006-02-08
我2年前读这本书,只能理解20%,但觉水平已经上了一个档次。现在重读,更觉经典。这是能够读多遍,每次都让你有新体会的技术书。它涉及XP,UML,原则,模式,实战等,绝对值得收藏。...
书名: 敏捷软件开发
作者: [美] Robert C·Martin
出版社: 清华大学出版社
原作名: Agile Software Development: Principles, Patterns, and Practices
副标题: 原则、模式与实践
译者: 邓辉
出版年: 2003-09-01
页数: 476
定价: 59.00元
装帧: 平装
丛书: 软件工程实践丛书
ISBN: 9787302071976