二、敏捷开发的设计原则

关于敏捷开发的设计原则：
单一职责原则SRP：Single Responsibility Principle
开放封闭原则OCP：Open－Close Principle
Liskov替换原则LSP：Liskov Substitution Principle
依赖倒置原则DIP：Dependency Invertion Principle
接口隔离原则ISP：Interface Separate Principle
关于包的设计原则：
重用发布等价原则REP：Reuse Equivalence Principle
共同重用原则CRP：Common Resue Principle
共同封闭原则CCP：Common Close Principle
无环依赖原则ADP：Acyclic Dependency Principle
稳定依赖原则SDP：Stabilization Dependency Principle
稳定性度量公式：I＝Ce/(Ca+Ce) (I:不稳定度，Ce:输入耦合度，Ca：输出耦合度)
I取值范围在【0，1】，I＝0表示具有最大稳定度；iI＝1标识具有最大不稳定度
稳定抽象原则SAP：Stabilization Abstract Principle

 

GOF说－－基于对象组合的设计会有更多的对象（而有较少的类）。
如果单纯的看这里，你会明白似乎类较少符合面向对象的逻辑。
但是且慢，我们知道面向对象有一条原则叫单一职责原则－－SRP。
这样好像类多又是面向对象思想的体现。
其实最重要的是GOF中的这句话－－且系统的行为将依赖对象间的关系而不是被定义在某个类中。
所以类的多少并不是问题的关键，是否职责单一也不是大问题，
最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。
在BOB大叔那里定义职责是变化的原因，因此就可以认为这些变化的原因应该是不可代替的，
也可以说你不能由这个原因推导出别的原因。
只要这个原因间可以做到相互关联，那么你就可以把由于这些变化而引起变化的类组合起来，
而不是把他们规定在新的类中。


开放封闭原则OCP：Open－Close Principle

一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。

因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。

该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。

我们以收音机的例子为例，讲述面向对象的开闭原则。

我们收听节目时需要打开收音机电源，对准电台频率和进行音量调节。

但是对于不同的收音机，实现这三个步骤的细节往往有所不同。

比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。

因此，我们不太可能针对每种不同类型的收音机通过一个收音机类来实现（通过重载）这些不同的操作方式。

但是我们可以定义一个收音机接口，提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。

不同的收音机继承并实现这六个抽象方法。

这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为方便。

此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。 
图1是一个应用OCP生成的收音机类图的例子：

Liskov替换原则LSP：Liskov Substitution Principle

子类应当可以替换父类并出现在父类能够出现的任何地方。

我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。

这个例子有些牵强，

一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。

因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。 
 

			
                                                            

                    

                                                    来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/3433/viewspace-269190/，如需转载，请注明出处，否则将追究法律责任。
                                            

                
转载于:http://blog.itpub.net/3433/viewspace-269190/

关于敏捷开发的设计原则：
单一职责原则SRP：Single Responsibility Principle
开放封闭原则OCP：Open－Close Principle
Liskov替换原则LSP：Liskov Substitution Principle
依赖倒置原则DIP：Dependency Invertion Principle
接口隔离原则ISP：Interface Separate Principle
关于包的设计原则：
重用发布等价原则REP：Reuse Equivalence Principle
共同重用原则CRP：Common Resue Principle
共同封闭原则CCP：Common Close Principle
无环依赖原则ADP：Acyclic Dependency Principle
稳定依赖原则SDP：Stabilization Dependency Principle
稳定性度量公式：I＝Ce/(Ca+Ce) (I:不稳定度，Ce:输入耦合度，Ca：输出耦合度)
I取值范围在【0，1】，I＝0表示具有最大稳定度；iI＝1标识具有最大不稳定度
稳定抽象原则SAP：Stabilization  Abstract Principle

GOF说－－基于对象组合的设计会有更多的对象（而有较少的类）。
如果单纯的看这里，你会明白似乎类较少符合面向对象的逻辑。
但是且慢，我们知道面向对象有一条原则叫单一职责原则－－SRP。
这样好像类多又是面向对象思想的体现。
其实最重要的是GOF中的这句话－－且系统的行为将依赖对象间的关系而不是被定义在某个类中。
所以类的多少并不是问题的关键，是否职责单一也不是大问题，
最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。
在BOB大叔那里定义职责是变化的原因，因此就可以认为这些变化的原因应该是不可代替的，
也可以说你不能由这个原因推导出别的原因。
只要这个原因间可以做到相互关联，那么你就可以把由于这些变化而引起变化的类组合起来，
而不是把他们规定在新的类中。

第七章 什么是设计模式
1. 源代码是软件系统的主要设计文档

我们不应该认为软件设计就是一组和代码分离的UML图，UML图只是描述了设计的一部分。
软件项目的设计是一个抽像的概念。它和程序的概括形状、结构以及每一个模块、类和方法的详细形状和结构有关。
设计的最终体现在 源代码 中。

2.设计中臭味——腐化软件的气味

僵化性： 耦合性高，模块组件件关系太紧密，依赖性高，一动全动。
脆弱性： 改动一处，其他相关联的地方也会变动，引发意想不到的问题。
牢固性： 设计难以重用。
粘滞性： 这一点有点难以理解。
不必要的复杂性： 导入不必要的模块，组件或包。
不必要的重复： 随意copy，将可以的抽象隐藏起来，而且如果随处copy的代码（如果有错误）需要变动，得到处进行修改。

【案例】：开发中，打印空指针异常信息处理方法的例子


晦涩性： 模块难以理解。


设计中的臭味



3.保持尽可能好的设计

需求是项目中最不稳定的要素。
敏捷团队依靠变化来获取活力。
团队几乎不进行预先设计，因此不需要一个成熟的初始设计。
敏捷开发人员致力于保持设计尽可能的适当、干净、简单，并且使用许多的单元测试和验收测试支援。
敏捷软件开发知道要做的事情：

他们遵循敏捷实践去发现问题
他们应用设计原则去诊断问题
并且，他们应用适当的设计模式去解决问题



4.结论-什么是敏捷设计



敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能的简单、干净以及富有表现力。



5.臭味

设计中的臭味是一种症状，是可以主观进行度量的。这些臭味通常是由违反了这些原则中的一个或者多个导致的。
比如违反了开闭原则，会导致僵化性。
应用原则的目的是去除僵化性，当没有臭味时就不应该应用这些原则

6.敏捷设计之原则

单一职责原则（The Single Responsibility Principle,简称SRP）
开放——封闭原则（The Open-Close Principle,简称OCP）
Liskov替换原则（The Liskov Substitution Principle,简称LSP）
接口隔离原则（The Interface Segregation Interface,简称ISP）
依赖倒置原则（The Dependency Inversion Principle,简称DIP）

第八章 单一职责原则（SRP）

内聚性：


一个模块的组成元素之间的功能相关性。把内聚性和引起一个模块或者类改变的作用力联系起来。


职责： 变化的原因。
原则的定义：就一个类而言，应该仅用一个引起它变化的原因。
描述：

每一个职责都是变化的一条轴线。当需求变化时，该变化反应为类的职责的变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。
如果一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
这种耦合导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏。


Employee的例子

Employee类包含了业务规则和对于持久化的控制。
业务规则往往会频繁的变化，而持久化的方式却不会如此频繁的变化。
测试驱动开发的实践常常会远在设计出现臭味之前就迫使我们分离这两个职责。


一个实例：

SpringIOC源码中BeanFactory的设计。
getBaen()和getBeanDefinition()、registerBeanDefinition()的分离。



第九章 开放-封闭原则（OCP）

原则的定义：


软件实体（类，模块、函数等等）应该是可以扩展的，但是不可修改的。


描述：

对于扩展是开放的
对于更改的封闭的


开闭的原则描述




本质： 构造抽象来隔离引起的变化
如何知道变化的发生：

进行适当的调查，提出正确的问题，并且使用我们的经验和一般常识，最终，直到我们会一直等到变化发生的时候才采取行动。


结论：


在许多方面，OCP都是面向对象设计的核心所在，遵循这个原则可以带来巨大好处。比如，灵活性，可重用性以及可维护性。



第十章 Liskov替换原则（LSP）

定义：


子类型必须能够替换掉它们的基类型


背后的本质：继承
描述： 若对每个类型S的对象o1,都存在一个类型T的对象o2,使得在所有针对T编写的程序P中,用o1替换o2后，程序P行为功能不变，则S是T的子类型。
隐藏的问题：一般违反LSP原则的同时，也潜在的违反了OCP原则。
Rectangle类与Square类违反了LSP的有趣例子
结论：


一个模型，如果孤立地看，并不具有真正意义上的有效性。在考虑一个特定设计是否恰当时，不能完全孤立地来看这个解决方案。必须要根据该设计的使用者所做出的合理假设来审视它。


基于契约式设计（约定大于配置）

契约：是通过为每个方法声明的前置条件和后置条件来指定的。
要使一个方法得以执行，前置条件必须为真。执行完毕后，该方法要保证后置条件为真。




继承的适用性



第十一章 接口隔离原则

**定义：**不应该强迫客户依赖它们不用的方法
胖类：意味着高耦合性，当一个客户程序要求该胖类进行一个改动时，会影响到所有其他的客户程序。
分离客户就是分离接口


接口隔离原则描述


分离接口的两种方式：

使用委托分离接口
使用多重继承分离接口



第十二章 依赖倒置原则（DIP）


定义：



a.高层模块不应该依赖于低层模块。两者都应该依赖于抽象。

b.抽象不应该依赖于细节。细节应该依赖于抽象。




依赖倒置原则描述



设计的层次化；

所有结构良好的面向对象架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。
这里的倒置不仅仅是依赖关系的倒置，它也是接口所有权的倒置。



依赖于抽象： 程序中所有的依赖关系都应该终止于抽象类或者接口。

任何变量都不应该持有一个指向具体类的指针或者引用。
任何类都不应该从具体类派生。
任何方法都不应该覆写它的任何基类中的已经实现了的方法。



java是静态编程语言，python是动态编程语言。


参考博客：

单一职责原则（Single Responsibility Principle）
开放封闭原则（Open Closed Principle）
设计模式六大原则（2）：里氏替换原则
里氏替换原则（Liskov Substitution Principle)
接口分离原则（Interface Segregation Principle）
依赖倒置原则（Dependency Inversion Principle）

[b]计划游戏：如今的SCRUM敏捷方法论的原型。核心概念是拆分软件开发任务，排优先级，迭代式增量开发。[/b]
 小规模发布：主要思想是软件发布/部署应该提高频度，增量发布/部署。

 简单设计：是指让系统保持越简单越好——无论将来的变化会让我们如何担忧。

 测试：是指程序员，甚至客户，应该编写自动化测试程序，来验证产品代码是否是按设计的方式运行。如今我们把它称作测试驱动开发(TDD)和确认测试驱动开发(ATDD)。

  重构：是指软件的内部结构可以、并且应该做持续的改进
。
  结队编程：是说团队成员如果各自独立工作就不能称之为团队。团队成员必须有规律的合作——在键盘上。这样，他们能充分分享团队其他成员应该知道的知识。

  集体所有制：是指代码归团队共有，不属于个人
。
 每周工作40小时：是说经常加班的团队是失败的团队。

  现场客户：是指来自业务方、负责需求的人，必须有准备的全程和开发团队保持畅通交流。

 编码标准：是指开发团队要采用一种固定的代码风格，用来提高代码整洁和方便交流。