Here are some common causes of redesign along with the design pattern(s) that address them:
- Creating an object by specifying a class explicitly.通过显示方式指定一个类来创建对象
- 在创建对象时指定类名将使你受特定实现的约束，而不是特定接口的约束。
- Abstract Factory(87) ,Factory Method(107),Prototype(117)
- Dependence on specific operations.对特殊操作的依赖
当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地变响应请求的方法。
- Chain of Responsibility (223) , Command(233).
- Dependence on hardware and software platform.对硬件软件平台的依赖
- 外部的操作系统接口和应用编程接口( A P I )在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了.
- Abstract Factory(87),Bridge(151).
- Dependence on object representations or implementations.对对象表示或实现的依赖
- 客户如果依赖对象内部的表示，保存，定位或实现，那么可能当对象改变的时候客户代码也要改变。隐藏这些信息，防止连锁效应。
- Abstract Factory(87),Bridge(151),Memento(283),Proxy(207)
- Algorithmic dependencies 算法依赖
- 在开发和重用时，算法经常被扩展、优化、和替换。对象依赖一个算法则当算法改变时对象也会需要改变。于是，经常会改变的算法需要隔离起来。
- Builder(97) , Iterator(257), Strategy(315),Template Method(325),Visitor(331).
- Tight coupling 紧耦合
- 类们是紧耦合的话，就难以单独的复用，因为他们互相依赖。于是就产生了一个单块的系统，除非你理解内部关系或者牵涉到很多类，否则你无法跟改或移除单个类。整个系统黑压压的(dense mass) 难于学习、移植和维护。
- 松耦合增强了 单个类可复用的可能性且整个系统容易被理解、移植、修改和拓展。
- 设计模式使用诸如抽象化耦合与将系统分层以促进解耦。
- Abstract Factory (87) ,Bridge(151),Chain of Responsibility(223), Command(233),Facade(185),Mediator(273),Observer(293)
- Extending functionnality by subclassing. 通过生成子类来扩展功能
- 使用子类来定制一个对象并不容易。每个新类都有固定的实现开销（初始化，终结，etc）。定义一个子类需要对父类有深入的理解。比如，重写一个操作可能需要重写另一个操作。还有可能需要调用已经继承的操作。并且使用子类扩展可能是类的数量爆炸性增长。试想只要添加一个简单的功能就要添加许多的新子类。
- 普通的对象的组合与特别的委托，能够提供灵活的组合行为的能力，使得继承变成可选。新的功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类的方式加到应用中去。
- 另一方面，过度的使用组合回事设计难以理解。很多设计模式产生的设计使你可以只定义一个子类，然后将其实例与一个已有对象组合来定制功能。
- Bridge (151) ,Chain of Responsibility(223) ,Composite(163),Decorator (175),Observer(293),Strategy(315).
- Inability to alter classes conveniently. 不能方便的对类进行修改
- 有时你必须修改一个不容易修改的类。你可能需要源代码但是却没有（可能是一个商业的类库）。或者任何改变会需要修改很多现有的类。设计模式提供在这些情况下的修改方法。
- Adapter(139),Decorrator(175),Visitor(331)