n 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
n 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
n 晦涩性： 很难阅读、理解。没有很好地表现出意图。
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：
n 单一职责原则(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
n 开放-封闭原则(OCP)
软件实体应该是可以扩展的，但是不可修改。
n Liskov替换原则(LSP)
子类型必须能够替换掉它们的基类型。
n 依赖倒置原则(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
n 接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
n 重用发布等价原则(REP)
重用的粒度就是发布的粒度。
n 共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
n 共同重用原则(CRP)
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
n 无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
n 稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
n 稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。
下面举一个简单的设计问题方面的模式与原则应用的示例：
问题：
选择设计运行在简易台灯中的软件，台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着，也可以让灯打开或关闭。
解决方案一：
下面图1是一种最简单的解决方案，Switch对象可以轮询真实开关的状态，并且可以发送相应的turnOn和turnOff消息给Light。
解决方案二：
上面这个设计违反了两个设计原则：依赖倒置原则(DIP)和开放封闭原则(OCP)，DIP原则告诉我们要优先依赖于抽象类，而Switch依赖了具体类Light，对OCP的违反是在任何需要Switch的地方都要带上Light，这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案，可以采用ABSTRACT SERVER模式，在Switch和Light之间引入一个接口，这样就使得Switch能够控制任何实现了这个接口的东西，这也就满足了DIP和OCP原则。如下面图2所示：
解决方案三：
上面图2所示解决方案，违返了单一职责原则(SRP)，它把Switch和Light绑定在一起，而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决，适配器从Switchable 派生并委托给Light，问题就被优美的解决了，现在，Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示：
敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。
参考文献
设计模式-可复用面向对象软件的基础 -- 李英军等译
重构-改善既有代码的设计 -- 侯捷等译
敏捷软件开发-原则、模式与实现 -- 邓辉译
文章来源于领测软件测试网 https://www.ltesting.net/
