再谈外观模式

       在上次重构机房收费系统时，好多人千篇一律的画出了这样的架构图。                 

                              

      采用的是经典三层加外观、抽象工厂加反射以及辅助类的架构。关于这个架构，我想说一下外观模式。

      外观：提供了一个统一的接口，用来访问子系统中的一群接口。

      UI层和BLL层之间，有些交互需要调用BLL层中好几个类，但是有些只需要一个调用一个。所以在写的时候曾这样想，将复杂的操作，通过外观来整合；简单的就直接用UI层调BLL层。然后就出现了下面的架构图。

                                 

        对于这个，有点疑惑。因为这样之后，明显感觉乱了好多，但是又不没有违反外观模式啊。

       因为我在看HeadFirst中，它这样说外观模式：通过实现一个提供更合理的接口的外观类，你可以将一个复杂的子系统变得容易使用。如果你需要复杂子系统的强大威力，别担心，还是可以使用原来的复杂接口的；如果你需要的是一个方便使用的接口，那就使用外观。

       上面叙述的就是我对上面一段话的理解。

       但是为什么我们再架构时将那一条线给去掉了么？

       我个人感觉是为了架构的清晰。在用设计模式的时候，有些东西还是需要取舍的。出现了BLL中的东西很简单，在外观中直接return一下也是可以接受的，这样，UI层与BLL层的耦合就解开了，替代的是一个接口更加清晰的外观层。