外观模式以及FishiGUI子系统外观模式的实现

问题：得到得分析模型中，适配器子系统有两个分析类，一个是负责程序启动和消息分发的操作系统适配器，另一个是负责图形操作的绘图接口类，在这样的设计里，着两个类该如何对外提供接口呢?难道需要从公共抽象类中继承出来么

外观模式：

外观模式可以为一个子系统中的多个类提供统一的接口，外观模式定义了一个高层次的接口，并使一个子系统更易于使用；把一个组件单元构建成一个子系统有助于减少软件的复杂性，而且可以使子系统和其他的组件的通信更简洁和更容易控制，最大幅度地降低组件之间的耦合度。在面向对象设计的领域里，达到这一目标的最好的方法就是引进一个外观类，让它为子系统的通用功能提供一个简单的一致的公共接口

子系统的接口不一定是具体的外观类，它和外观类之间的关系可能会有两种：

子系统的接口是一个抽象类，不包含任何属性和具体的实现，其中定义的所有的接口函数都是纯虚函数：外观类是该抽象类的派生类，隐藏在子系统中，在这种实现中，客户程序所看到的只有一个纯粹的接口，而具体的实现都被外观类封装到了子系统的内部

子系统的接口就是外观类的头文件（对于C++语言而言），客户程序可能会看到一些外观类的私有属性和私有方法

第一种方法比较纯粹，如果子系统的接口可以被多个子系统公用，就会有不同的派生类，此种情况使用该方法非常有用；第二种方法比较简单和直接

外观类一般应该以单件类的形式出现，这样客户程序就可以通过单件类的静态方法获得子系统的唯一接口实例，另外外观类一般要负责创建和销毁子系统中的其他的相关对象，管理其他对象的生命周期，当客户程序调用外观类中的几口函数时，外观类必须知道每一个特定的请求应该发送给子系统中哪个类或者对象

除了外观类以外，子系统中的其他类实现了子系统的各项具体功能，但是它们不能依赖于外观类，即不能调用外观类中的接口方法

FIshiGUI适配器子系统的外观模式实现：

适配器子系统可以得到两个具体的实现类-----FG_OSAdaptor类和FG_OSDrawInterface类，其中前者负责FishiGUI系统的启动和操作系统消息的转发，后者负责将绘图调用转发给操作系统中的绘图接口

适应不同的需求同时支持多种环境，的问题只要把FG_OSAdaptor类和FG_OSDrawInterface类实现为抽象类，即只把两者看做纯粹的几口，然后对每种具体的操作系统都从FG_OSAdaptor类和FG_OSDrawInterface类中继承出特定的派生类，将只与具体系统相关的属性和方法实现在派生类中，该问题即可解决

外观类：

如果添加一个外观类，那么它的职责就是把框架层对适配器子系统的调用请求发送给具体的操作系统适配器类或具体的绘图接口类，然后再由后者进一步将调用转发给操作系统或者底层绘图接口，这个外观类的职责不是很多，完全可以和并带其他的类中，因此可以将适配器类FG_OSAdaptor来承担外观类的职责，而FG_OSAdaptor类的头文件可以作为整个适配器子系统的接口直接输出，框架层的客户程序通过FG_OSAdaptor类来访问整个适配器子系统的功能

至于实例化FG_OSDrawInterface类的解决是：FG_OSAdaptor类中只包含指向FG_OSDrawInterface类的指针，而具体的创建绘图接口类的任务则交给FG_OSAdaptor类的派生类来完成；

由于FG_OSAdaptor类是一个外观类，客户程序的所有调用都必须通过他传入子系统，所以必须在FG_OSAdaptor中把绘图接口中的所有绘图函数重新定义一边