一天一种设计模式之十一-----外观模式

一.外观模式简介

1. 外观模式属于结构型模式。

2. 外观模式为子系统中的一组接口提供了一个一致的界面，外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。

3. 当你要为一个复杂的系统提供一个简单的接口时，子系统每每由于不断演化而变的愈来愈复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具备可重用性，更容易对子系统进行定制，但这也会给那些不须要定制子系统的用户带来一些使用上的困难。

4. 外观模式为了解决3的痛点，提供了一个简单的缺省视图，这一视图对大多数用户来讲已经足够，而那些须要更多的可定制性的用户能够越过外观层。

5. 客户程序与抽象类的实现部分存在着很大的依赖性，引入外观模式能够将这个子系统与客户以及其余子系统分离，能够提升子系统的独立性和可移植性。

6. 优势：

1. 引入外观模式，客户对子系统的使用变得简单了。减小了与子系统的关联对象，实现了子系统与客户之间的松耦合。

2. 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类

3. 下降了大型软件系统中的编译依赖性，并简化了系统在不一样平台之间的移植过程。

7. 缺点：

1. 不能很好的限制客户使用子系统类，若是堆客户访问子系统作太多的限制则减小了灵活性和可变性。

2. 在不引入抽象外观类的状况下，增长新的子系统可能须要修改外观类或客户端的源码，违背了开闭原则。

8. 我的感受，外观类只不过把具体的业务逻辑模块化了，这样的聚合在层次鲜明，耦合自己比较低或者逻辑流程比较统一的业务中值得考虑，但但业务流转的太复杂有可能致使父系统上面又聚合父系统，这样层次关系会很乱。因此这种模式不值得在复杂多变的逻辑处理中推荐。
   

二.测试代码

public class WaiguanMoshiTest {
    public static void main(String[] args) {
        Facade facade=new Facade();
        facade.methodA();
        facade.methodB();
    }
}
interface ServiceA{
    void methodA();
}
interface ServiceB{
    void methodB();
}
interface ServiceC{
    void methodC();
}
class ServiceAimpl implements ServiceA{

    @Override
    public void methodA() {
        System.out.println("服務a");
    }
    
}
class ServiceBimpl implements ServiceB{

    @Override
    public void methodB() {
        System.out.println("服務b");
    }
    
}
class ServiceCimpl implements ServiceC{

    @Override
    public void methodC() {
        System.out.println("服務c");
    }
    
}
class Facade{
    ServiceA serviceA;
    ServiceB serviceB;
    ServiceC serviceC;
    public Facade(){
        serviceA=new ServiceAimpl();
        serviceB=new ServiceBimpl();
        serviceC=new ServiceCimpl();
    }
    public void methodA(){
        serviceA.methodA();
        serviceB.methodB();
    }
    public void methodB(){
        serviceB.methodB();
        serviceC.methodC();
    }
    public void methodC(){
        serviceC.methodC();
        serviceA.methodA();
    }
}