需要分别针对三个类编写测试用例，设计模型一旦发生变化，测试用例也将需要重新编写。再考虑下面的一种情况：

 
    现在的设计引入了TransferFacade对象，这样我们的测试用例就可以针对TransferFacade来编写了，而转帐的业务逻辑是相对比较稳定的。使用这种测试思路的时候，要注意两点：首先，这并不是说其它的类就不需要测试用例了，这种测试思路仅仅是把测试的重点放在外观类上，因为任何时候充分的测试都是不可能的。但其它类的测试也是必要的，对于外观类来说，任何一个业务方法的错误都会导致最终的测试失败。其次，当外观类的测试无法达到稳定测试用例的效果时，就没有必要使用外观类了。

    只针对有需要的设计进行重构。

    任何时候，请确保重构行为仅仅对那些有重构需要的设计。重构需要花费时间和精力，而无用的重构除了增大设计者的虚荣心之外，并不能够为软件增加价值。重构的需要来源于两点：一是需求的变更。目前的设计可能无法满足新的需求，因此需要重构。二是对设计进行改进，以得到优秀简洁的设计。除了这两种情况，我们不应该对设计模型进行重构。

    使用文档记录重构的模式。

    应该承认，模式为设计提供了充分的灵活性。而这些设计部分往往都是模型的关键之处和难点所在，因此需要对模式进行文档化的工作，甚至在必要的时候，对这部分的设计进行培训和指导。确保你的团队能够正确的使用文档来设计、理解、扩展模式。我们在解决方案的前一个部分提到了尽可能延迟文档的创建。而在设计重构为模式的时候，我们就需要进行文档化的工作了。因为模式具有灵活性，能够抵抗一定的变更风险。

    重构并保持模式的一致性

    正如上一节所说的那样，模式并不是一个很容易理解的东西，虽然它保持了设计的灵活性和稳定性。对于面向对象的新手而言，模式简直就像是飞碟一样，由于缺少面向对象的设计经验，他们无法理解模式的处理思路，在实践中，我们不只一次的碰到这种情况。我们不得不重头开始教授关于模式的课程。因此，最后我们在软件设计采用一定数量的模式，并确保在处理相同问题的时候使用相同的模式。这样，应用的模式就成为解决某一类的问题的标准做法，从而在一定程度上降低了学习的曲线。

    保持模式的一致性的另一个方面的含义是将模式作为沟通的桥梁。软件开发是一种团队的行为。因此沟通在软件开发中扮演着很重要的角色。试想一下，开发人员在讨论软件设计的时候，只需要说"使用工厂模式"，大家就都能够明白，而不是费劲口舌的说明几个类之间的关系。这将大大提高沟通的效率。此外，模式的使用和设计的重构对于提高团队的编程水平，培养后备的设计人员等方面都是很有意义的。