敏捷软件开发

按有用程度 按页码先后 最新笔记

• 

  第三部分 薪水支付案例研究

  Wuqifu (喜欢买书的软件工程师~)

  Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。 命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无... (更多)

  Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。

  命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无需知道接受者任何接口。

  比如说，对文件进行操作，如打开、关闭、打印。正常的操作就是用户点击“打开”按纽，就执行打开命令，在按纽的单击事件中写个方法就可以了。但如要应用Command模式，就要把其抽象出接口，把这三个操作封装成单独的类。

  Template Method模式：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method模式使得子类可以不改变算法的结构即可重新定义该算法的某些特定步骤。（继承）

  Strategy模式：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。Strategy模式使得算法可以独立于使用它们的客户而变化。（委托）

  Facade模式：为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个高层接口使得这一子系统更加容易使用。

  Mediator模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

  Singleton模式：保证一个类仅有一个实例，并提供一个全局访问点。通过使用私有构造函数，静态变量和一个静态访问方法来实现。

  MonoState模式：构造函数声明为public，而将类中所有的字段声明为static。MonoState并不限制创建对象的个数，但是它的状态却只有一个状态。

  NULL Object模式：提供一个给定类型的NULL Object对象，用以代替这个对象为null的情况，简化代码。 (收起)

  2011-12-23 21:34:19   回应

  收藏

  推荐
• 

  第二部分 敏捷设计

  Wuqifu (喜欢买书的软件工程师~)

  腐化的设计 僵化性（Rigidity）：难以对系统进行修改 脆弱性（Fragility）：改动一个地方，程序许多地方出现问题 牢固性（Immobility）：很难解开系统的纠结 粘滞性（Viscosity）：做错误的事情容易，做正确的事情困难 不必要的复杂性（Needless Complexity）：过度设计，为过多的可能性做准备 不必要的重复（Needless Repetition）：重复的代码，开发人员忽视的抽象 晦涩性（Opacity）：难以阅读、理解，没有用清晰、富有.. (更多)

  腐化的设计

  僵化性（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模式 (收起)

  2011-12-22 00:52:36   回应

  收藏

  推荐
• 

  第一部分 敏捷宣言

  Wuqifu (喜欢买书的软件工程师~)

  个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 (更多)

  个体和交互 胜过 过程和工具

  可以工作的软件 胜过 面面俱到的文档

  客户合作 胜过 合同谈判

  响应变化 胜过 遵循计划 (收起)

  2011-12-22 00:52:10   回应

  收藏

  推荐

• 

  第33页

  昨夜o0O`` (一切都不可挽回的走向庸俗.)

  读了一年还没读完 悲剧... (更多)

  读了一年还没读完 悲剧... (收起)

  2011-02-05 15:16:40   3回应

  收藏

  推荐
• 

  第99页

  damen (我执)

  请教各位一个问题～ 这里是用C++来实现的。如果我想换成JAVA来实现，我该怎么做呢？？？？？？ (更多)

  请教各位一个问题～

  这里是用C++来实现的。如果我想换成JAVA来实现，我该怎么做呢？？？？？？ (收起)

  2011-06-08 23:11:26   回应

  收藏

  推荐
• 

  第413页

  芈子叶

  最近一直在扩充UML知识，看UML自然就想去找点开发过程的书开眼，于是早前备下的《敏捷软件开发：原则、模式与实践》便得以不如废纸。 看到孟岩的代序，增了大量激情，由他的推荐我跳到413页UML的附录，开始学习，目前学习中。 最近几天一直在静下心来读书，希望能坚持。 (更多)

  最近一直在扩充UML知识，看UML自然就想去找点开发过程的书开眼，于是早前备下的《敏捷软件开发：原则、模式与实践》便得以不如废纸。

  看到孟岩的代序，增了大量激情，由他的推荐我跳到413页UML的附录，开始学习，目前学习中。

  最近几天一直在静下心来读书，希望能坚持。 (收起)

  2011-04-04 13:06:02   回应

  收藏

  推荐

• 

  第三部分 薪水支付案例研究

  Wuqifu (喜欢买书的软件工程师~)

  Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。 命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无... (更多)

  Command模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。

  命令模式就是把一些具体的命令封装成一些具体的类，这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行，完成一个具体的业务流程。它的优点是：解耦了发送者与接收者之间的联系。发送者调用一个操作，接收者接受请求执行具体类相应的动作。因为使用Command模式解耦，发送者无需知道接受者任何接口。

  比如说，对文件进行操作，如打开、关闭、打印。正常的操作就是用户点击“打开”按纽，就执行打开命令，在按纽的单击事件中写个方法就可以了。但如要应用Command模式，就要把其抽象出接口，把这三个操作封装成单独的类。

  Template Method模式：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method模式使得子类可以不改变算法的结构即可重新定义该算法的某些特定步骤。（继承）

  Strategy模式：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。Strategy模式使得算法可以独立于使用它们的客户而变化。（委托）

  Facade模式：为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个高层接口使得这一子系统更加容易使用。

  Mediator模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

  Singleton模式：保证一个类仅有一个实例，并提供一个全局访问点。通过使用私有构造函数，静态变量和一个静态访问方法来实现。

  MonoState模式：构造函数声明为public，而将类中所有的字段声明为static。MonoState并不限制创建对象的个数，但是它的状态却只有一个状态。

  NULL Object模式：提供一个给定类型的NULL Object对象，用以代替这个对象为null的情况，简化代码。 (收起)

  2011-12-23 21:34:19   回应

  收藏

  推荐
• 

  第二部分 敏捷设计

  Wuqifu (喜欢买书的软件工程师~)

  腐化的设计 僵化性（Rigidity）：难以对系统进行修改 脆弱性（Fragility）：改动一个地方，程序许多地方出现问题 牢固性（Immobility）：很难解开系统的纠结 粘滞性（Viscosity）：做错误的事情容易，做正确的事情困难 不必要的复杂性（Needless Complexity）：过度设计，为过多的可能性做准备 不必要的重复（Needless Repetition）：重复的代码，开发人员忽视的抽象 晦涩性（Opacity）：难以阅读、理解，没有用清晰、富有.. (更多)

  腐化的设计

  僵化性（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模式 (收起)

  2011-12-22 00:52:36   回应

  收藏

  推荐
• 

  第一部分 敏捷宣言

  Wuqifu (喜欢买书的软件工程师~)

  个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 (更多)

  个体和交互 胜过 过程和工具

  可以工作的软件 胜过 面面俱到的文档

  客户合作 胜过 合同谈判

  响应变化 胜过 遵循计划 (收起)

  2011-12-22 00:52:10   回应

  收藏

  推荐