敏捷软件开发

出版时间：20101112  出版社：人民邮电出版社  作者：Robert C.Martin,,Micah Martin  页数：538  译者：邓辉,孙鸣  
Tag标签：无  

内容概要

本书中，享誉全球的面向对象技术大师Robert C. Martin深入而生动地使用真实案例讲解了面向对象设计的基本原则、重要的设计模式、UML和敏捷方法。    本书Java版曾荣获2003年第13届Jolt大奖，是公认的经典著作。本书是C#程序员提升功力的绝佳教程，也可用作高校计算机、软件工程专业本科生、研究生的教材或参考书。

作者简介

Robert C. Martin（“Bob”大叔）世界级的软件开发大师，著名软件咨询公司Object Mentor公司的创始人和总裁。曾担任C++ Report杂志主编多年，也是设计模式和敏捷开发运动的主要倡导者之一。

书籍目录

第一部分  敏捷开发 　　第1章  敏捷实践　第2章  极限编程概述　第3章  计划　第4章  测试　第5章  重构　第6章  一次编程实践第二部分  敏捷设计 　第7章  什么是敏捷设计　第8章  SRP：单一职责原则　第9章  OCP：开放－封闭原则　第10章  LSP：LISKOV替换原则　第11章  DIP：依赖倒置原则　第12章  ISP：接口隔离原则　第13章  写给C#程序员的UML概述　第14章  使用UML　第15章  状态图　第16章  对象图　第17章  用例 　第18章  顺序图　第19章  类图　第20章  咖啡的启示第三部分  薪水支付案例研究 　第21章  COMMAND模式和ACTIVE OBJECT模式：多功能与多任务　第22章  TEMPLATE METHOD模式和STRATEGY模式：继承和委托　第23章  FACADE模式和MEDIATOR模式　第24章  SINGLETON模式和MONOSTATE模式　第25章  NULL OBJECT模式　第26章  薪水支付案例研究：第一次迭代开始　第27章  薪水支付案例研究：实现第四部分  打包薪水支付系统 　第28章  包和组件的设计原则　第29章  FACTORY模式　第30章  薪水支付案例研究：包分析　第31章  COMPOSITE模式　第32章  OBSERVER——演化至模式　第33章  ABSTRACT SERVER模式、 ADAPTER模式和BRIDGE模式　第34章  PROXY模式和GATEWAY模式：管理第三方API　第35章  VISITOR模式　第36章  STATE模式　第37章  薪水支付案例研究：数据库　第38章  薪水支付系统用户界面：Model-View-Presenter附录索引

用户评论 (总计30条)

•   早就 想买了,终于买了
•   比较喜欢的一款书
•   讲的是方法
•   敏捷软件开发：原则、模式与实践
•   非常不错，还可以啦。。。
•   　　这本书是我见过的讲述敏捷设计、开发书籍中最棒的一本！尤其是前半部分中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的情况，简化代码。
•   　　 2005年阅读的这本书，也因此知道了邓辉这个人，对前几章印象深刻，特别是敏捷的宣言和SOLID设计原则，但是后面的具体例子，受限于设计能力和语言差别，理解不深，知道了TDD，结对编程等概念，但是不能肯定是否有效。随后打算重读一遍技术章节；
  　　
•   　　读懂这本书还是需要一定功底的，需要相当的设计实践经验才能完全理解，书中也描述了一些设计模式，不过相比GOF的《设计模式》来说它是在一个更高设计原则的层次来描述经典模式的，总的来说值得阅读。
•   　　绝对是值得每一个敏捷开发人员阅读的图书。内容很实用。尤其是第六章《一次编程实践》部分的例子对我的触动很大。
•   　　看到前面有评论说，此书与敏捷的关系不大，颇有同感。所谓敏捷，那就是代码先写了再说，且看我们是如何做到，这就是读了这本书的感受。
  　　
  　　中文版没有把特定的英文缩写在第一次引用时列出来（只能在后面的索引表里找到），让我很不爽，比如DIP和SRP。不过，说到底还是中文看得快，比看小说都快。
  　　
  　　本书的一大特点就是浅显，比GOF的那本《设计模式》通俗易懂多了。虽然我还是不喜欢看大段的代码，但不可否认那些代码能够帮助理解。
  　　
  　　本书最好的地方，还是敏捷设计一章，列出了几个基本的原则：
  　　1.单一职责原则（SRP）
  　　2.开发-封闭原则（OCP）
  　　3.Liskov替换原则（LSP）
  　　4.依赖倒置原则（DIP）
  　　5.接口隔离原则（ISP）
  　　
  　　以及后面的打包原则：
  　　1.内聚性原则
  　　2.耦合性原则
  　　3.稳定依赖原则
  　　4.稳定抽象原则
  　　
  　　特别是LSP还是第一次听说，真是耳目一新。而稳定依赖原则，则有了更深的理论认识，虽然没有仔细看明白那些数学公式。
  　　
  　　当然，关于好的设计模式，还有很多很多，这本书也只是讲了很小一部分，讲得还不错。不过很多东西已经很老套了，基本都是N年前的东西了，难道是Bob大叔老了？
•   　　一本还不错的软件设计方面的书。不过为什么要扯上敏捷的头衔呢。书中最有价值的还是那个附录《源代码即设计》，其它的真正敏捷的东西太少了。而且放的代码过多。
  　　
•   　　通过这本书，你可以有以下收获：
  　　1.更深入的理解模式。
  　　2.提供了更好的软件开发的方法。
  　　3.具有了总体理解系统架构的能力。
  　　
  　　我以前总想看懂DELPHI的源码，总觉得一头雾水，现在知道是我没明白他的设计思想，不能从上往下看，越看东西越多就糊涂啦。
•   有同感！
  我相信作者的幽默感不错，但翻译之后，平平淡淡得！
•   老大，这本来就是本2002年的书，当然是N年前......
•   “所谓敏捷，那就是代码先写了再说”，你的理解比较搞笑，完全误解敏捷开发的含义和主张。看来你还是一个写代码的啊。。。
•   to TiMeZz，我可不可以认为你没有写过代码？
•   难倒狗咬了你一口你就要咬回来?
•   Gabriel纠正得极是，我还得加强修炼才行，呵呵。
•   总有人觉得自己很高竿.
•   敏捷还真就是代码先写了再说，整个极限编程的核心就死简单实现...
•   从书中的举例和故事来看，其实也和敏捷实践有很大关系
•   “所谓敏捷，那就是代码先写了再说”，这倒也是，我看了一遍这书都快把它当作面向对象开发的读物来对待了。
•   TiMeZz说的没有错，optman所说的“敏捷”就是先写代码，确实没有理解到敏捷软件开发的精髓。
  敏捷是指，不断维护一套灵活性很高的，易于修改的，防止其腐化，使之始终保持最佳状态，这样就能够快速地应对不断而来的客户需求变化，从而使得最终产生最符合客户需求的质量最高的系统。
•   还是先写代码
•   跟敏捷的关系还是很大啊。。
•   　“所谓敏捷，那就是代码先写了再说”, 代码是要写的, 但不仅仅是这样的吧, 呵呵
•   对于我们这样的菜豆来说，代码是理解原理的最好形式。
•   有了这些代码, 理解设计模式就比GOF轻松多了.而且从代码的演化过程可以学会如何重构,重构是如何进行的,为什么重构.
•   基本上就没有什么敏捷的内容在里面，这年代你不谈xp，不谈agile，不谈scrum，出版商都和你急！
•   難道真沒有麼？真的沒有麼？真的是沒有麼？