外观模式及其改进（二）：抽象外观类的引入

      在通用的外观模式结构图中，如果需要增加、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则，因此我们可以通过引入抽象外观类来对系统进行改进，在一定程度上解决该问题。在引入抽象外观类之后，客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的。引入抽象外观类的外观模式结构如图4所示：

图4  引入抽象外观类的外观模式结构图

      如果需要将图3中的加密类CipherMachine改为另一个加密类，例如NewCipherMachine，势必会导致外观类EncryptFacade源代码发生修改，违反开闭原则。通过引入抽象外观类，重构后的系统设计方案如图5所示：

图5  引入抽象外观类之后的文件加密模块结构图

      在图5中，客户类Client针对抽象外观类AbstractEncryptFacade进行编程，可以将具体外观类类名存储在XML等格式的配置文件中，如下代码所示：

<?xml version="1.0"?>
<config>
    <className>EncryptFacade</className>
</config>

      引入抽象外观类之后，客户类针对抽象外观类编程，更换具体外观类时只需修改配置文件，无须修改源代码，符合开闭原则。

【作者：刘伟  http://blog.csdn.net/lovelion】