外观模式:
提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。
有什么用处:
(1)实现了子系统与客户端之间的松耦合关系。
(2)客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。
用代码说话:
完成一件事,需要3个步骤:步骤A,步骤B,步骤C
public class ServiceA { public void methodA(){ System.out.println("步骤A"); } }
public class ServiceB { public void methodB(){ System.out.println("步骤B"); } }
public class ServiceC { public void methodC(){ System.out.println("步骤C"); } }
public static void main(String[] args) { ServiceA a = new ServiceA(); ServiceB b = new ServiceB(); ServiceC c = new ServiceC(); a.methodA(); b.methodB(); c.methodC(); }代码很简单,客户端为了完成这件事,分别调用了 步骤A、 步骤B、步骤C三个服务。从类与类之间耦合的关系来看,客户端对ServiceA、ServiceB、ServiceC都存在依赖关系。这是我们不愿意看到的,因为当服务方代码发现变化时,客户端也可能需要随之修改代码。同时,依赖过多的类,对应程序的复杂度、可维护性都是不好的体现。
由于以上原因,我们引入了外观模式。在服务端新建了一个Service类,作为外观类,提供统一的访问入口。
public class Service { private ServiceA a = new ServiceA(); private ServiceB b = new ServiceB(); private ServiceC c = new ServiceC(); public void service(){ System.out.println("Facade Pattern提供访问入口,解耦客户端程序调用"); a.methodA(); b.methodB(); c.methodC(); } }
这样依赖,客户端只需要依赖Service一个类,就能完成之前的功能
public static void main(String[] args) { Service service = new Service(); service.service(); }运行结果:
Facade Pattern提供访问入口,解耦客户端程序调用
步骤A
步骤B
步骤C
使用场景:
外观模式是一种很简单的设计模式,更应该是一种代码习惯。在以下情况下可以考虑使用外观模式:
(1)设计初期阶段,应该有意识的将不同层分离,层与层之间建立外观模式。
(2) 开发阶段,子系统越来越复杂,增加外观模式提供一个简单的调用接口。
(3) 维护一个大型遗留系统的时候,可能这个系统已经非常难以维护和扩展,但又包含非常重要的功能,为其开发一个外观类,以便新系统与其交互。
这个模式呢,有个最大的特点将细粒度的对象包装成粗粒度的对象,应用程序通过访问这个外观对象,来完成细粒度对象的调用,外观模式一般是分布式应用和系统架构中的应用服务层的设计中常用的方式,并且一般结合外观模式+DTO来完成服务层的设计,提供分布式应用服务的高效服务,外观模式我们可以这样理解,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性。