Fa ?ade模式在代码生成工具中的应用

摘 要：随着软件系统项目的越来越庞大和越来越复杂，对软件的要求越来越高。为了提高系统的可重用性，通常会把一个大的系统分成很多个子系统，然后再把一个子系统分成很多个更小的子系统，一直分下去直至各个小型模块。这样虽然提高了重用性，但提高了系统的复杂性，为了解决这一问题，可以通过软件设计模式中的Fa?ade模式去解决。本文主要阐述了Fa?ade模式的概念，通过代码生成工具这一实际应用模拟了其实现过程，并总结了该模式的特点和应用范围。

【关键词】设计模式 Fa?ade模式 代码生成工具

1 引言

在软件系统开发的过程当中，为了提高系统的开发效率，经常需要使用代码生成工具根据配置文件来自动生成代码，一般都是按照开发结构来实现的常见的基础功能，比如说对数据库的增删改查操作，这样就可以把主要精力放在系统的业务逻辑的实现上。现在假设使用代码生成出来的每个模块都具有基本的三成架构，分别为表现层、逻辑层和数据层，那么代码生成工具里面就应该有相应的代码生成处理模块。另外还需要一个配置管理的模块，通过配置来通知代码生成工具每个模块究竟需要生成哪些层的代码。

如果不使用软件设计模式去处理的话，就会产生一个问题，那就是客户端为了使用生成代码的功能，必须要与生成代码子系统内部的多个模块进行交互。对于客户端而言，增加了复杂度，使得客户端不能简单的使用生成代码的功能。而且如果其中的某个模块发生的改变，还可能会引起客户端也要随着变化。可以通过Fa?ade模式实现让让子系统外部的客户端在使用子系统的时候，既能简单的使用子系统内部的模块功能，而又不用客户端去与子系统内部的多个模块进行交互。

2 Fa ?ade模式的定义与实现

2.1 Fa?ade模式概念

Fa?ade模式，又称外观模式，就是为子系统中的一组模块提供一个统一的高层接口，使得子系统更加容易使用。这里所说的接口就是客户端与被访问的系统之间的一个通道，并不一定是指Java中的 interface。它在外观模式里面通常指的的是类，称为Fa?ade。外观模式就是通过引入这么一个Fa?ade类，在这个类里面定义客户端需要的简单方法，然后再这些方法的实现里面，由Fa?ade类再去分别调用内部的多个模块来实现功能，从而让客户端变得简单，客户端只需要和Fa?ade类交互就可以了。

Fa?ade模式的目的不是为了给子系统添加新的功能接口，而是为了让外部减少与子系统内部多个模块的交互，松散耦合，从而让外部能够更简单的使用子系统。外观主要负责组合已有的功能来实现客户需要，而不是添加新的实现。表面上看仅仅是将客户端的代码搬到Fa?ade里面，但实质发生了变化，Fa?ade是位于系统里面的，就相当于屏蔽了外部客户端和系统内部模块的交互，不但方便了客户端的调用，而且封装了系统内部的实现细节。另外Fa?ade的功能还可以被多个客户端调用，实现了功能的共享，也就是复用性。

2.2 Fa?ade模式的实现

现在假设子系统中有三个模块，分别是 AModule、BModule和CModule，它们分别有一个方法，此时的整体结构如图1所示。

外观模式的调用顺序如图2所示。

实现外观模式，只需要添加一个Fa?ade对象，然后再里面实现客户端需要的功能就可以了。

新添加一个Fa?ade对象：

public class Fa?ade{

public void generate（）{

new AModule（）.generate（）；

new BModule（）.generate（）；

new CModule（）.generate（）；

}

}

客户端实现：

public class Client{

public static void main（String[] args）{

new Fa?ade（）.generate（）；

}

}

3 Fa?ade模式特点

（1）松散耦合。Fa?ade模式松散了客户端与子系统的耦合关系，让子系统内部的模块具有更好的可扩展性和可维护性。

（2）简单易用。Fa?ade模式让子系统使用更加简单，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟外观交互就可以了，相当于外观类为客户端提供了一站式服务。

更好的划分了访问的层次。通过合理使用Fa?ade，更好的划分了访问的层次。有些方法是对系统外部的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到外观中，这样既方便客户端使用，也很好的隐藏了内部的实现细节。

（3）选择多样性。虽然有了外观，但如果有需要，外部还是可以绕开Fa?ade，而直接调用某个具体模块的接口，这样就能实现兼顾组合功能和细节功能。

4 总结

Fa?ade模式的本质是“封装交互，简化调用”。Fa?ade封装了子系统外部和子系统内部多个模块的交互过程，从而简化了外部的调用。外观模式很好的体现了“最少知识原则”。如果使用外观模式，客户端通常需要和子系统内部的多个模块交互，客户端和这些模块之间都有依赖关系，任意一个模块的变动都可能会引起客户端的变动。使用外观模式后，客户端只需要和外观类交互，而不需要去关心子系统内部模块的变动情况，客户端只和这个外观类有依赖关系。这样一来，客户端不但简单，而且这个系统具有更好的可扩展性和可维护性。当系统内部多个模块发生变化的时候，这个变化可以被这个外观类吸收和消化，并不需要影响到客户端，也就是说可以在不影响客户端的情况下实现系统 内部的维护和扩展。

如果希望为一个复杂的子系统提供一个简单接口的时候，可以考虑使用外观模式，使用外观对象来实现大部分客户需要的功能，从而简化客户的使用。如果想要让客户程序和抽象类的实现部分松散耦合，也可以考虑使用外观模式，使用外观对象来将这个子系统与客户端进行分离，从而提供子系统的独立性和可移植性。如果要构建多层结构的系统，同样可以考虑使用外观模式，使用外观对象作为每层的入口，这样可以简化层之间的调用，也可以松散层之间的依赖关系。

参考文献

[1]李丹.基于外观模式的数据库访问层的设计与实现[J].电脑知识与技术，2008（08）.

[2]王浩，刘红梅.Facade模式与Adapter模式的区别及联系[J].科技信息（学术研究），2008（09）.

[3]陈臣，王斌.研磨设计模式[M].清华大学出版社，2011.

作者单位

南京工程高等职业学校 江苏省南京市 211135