获得最大限度复用的关键在于对新需求和已有需求发生变化时的预见性，要求我们的系统设计能够相应地改进。下面阐述一些导致重新设计的一般原因，以及解决这些问题的设计模式。
 
（1）、通过显式地指定一个类来创建对象   。   在创建对像是指定类名将使你受特定实现的约束而不是特定接口的约束，这会使未来的变化更加复杂，要避免这种情况，应该间接地创建对像，此时考虑：   Abstract Factory 、 Factory Method 、 Prototype
 
（2 ）、对特殊操作的依赖。当你为请求指定一个特殊地操作时，完成该请求的方式就固定下来了，为了避免把请求代码写死，可以在编译或运行时刻很方便地改变响应请求的方式。此时考虑：   Chain of Responsibility   ， Command
 
（3 ）、对硬件和软件平台的依赖。外部的 OS 接口和应用编程接口（ API ）在不同的软硬件平台上是不同的，依赖于特定平台的软件将很难移稙到其它平台上，甚至很难跟上本地平台的更新，所以设计系统时限制其平台相关性就很重要了。此时考虑： Abstract Factory  , Bridge
 
（4）、对对像表示或实现的依赖。 知道对像怎样表示、保存、定位或实现的客户在对像发生变化时可能也需要变化，阻止连锁变化的办法就是对客户隐藏这些变化。此时考虑： Abstract Factory 、 Bridge 、 Memento 、 Proxy
 
（5 ）、算法依赖。算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对像在算法发生变变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。此时考虑： Builder 、 Iterator 、 Strategy 、 Template Method 、 Visitor
 
（6 ）、紧耦合。 紧耦合的类很难独立地被复用，因为它们是互相依赖的。紧耦合产生单快的系统，要改变或删掉一个类，必须理解和改变其它许多类。这样的系统是一个很难学习、移稙和维护的密集体。
松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移稙、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。此时考虑： Abstract Factory 、 Command 、 Façade 、 Mediator 、 Observer ， Chain of Responsibility
 
（7）、通过扩充子类来扩充功能。 通常很难通过定制子类来定制对像，每一个新类都有固定的实现开销（初始化，终止处理等），定义子类还需要对父类有深入的了解，如，重定义一个操作可能需要重定义其它操作，并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，你也不得不引入许多新的子类。
一般的对像组合技术和委托技术，是继承之外组合对像行为的另一种灵活的方法，新的功能可以通过新的方式组合已有对像，而不是通过定义已经存在的类的子类的方式加到应用中去，另一方面，过多使用对像组合会使设计难于理解。许多设计模式产生的设计中，你可以定义一个子类，且将它的实例和已存在的实例进行组合来引入定制的功能。设计模式： Bridge ， Chain of Responsibility ， Composite ， Decorator ， Observer ， Strategy 。
 
（8）、不能方便地对类进行修改。   有时候不得不改变一个难以修改的类，也许你需要而已没有（商业类库），或许可能对类的任何改变会要求修改许多已存在的其它子类，设计模式提供在这些情况下对类进行修改的方法。 Adapter ， Decorator ， Visitor
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />