设计模式总结篇系列:外观模式(Facade)

张三自从毕业后开始做软件开发,做着做着发现不爽了,钱赚不了太多,头发也白了。于是拿着一点小资本,想着做点小生意。瞅着眼前的餐饮行业还不错,于是打算开一家餐馆。开参观可不是一件容易的事,仅仅行政类的审批流程就不少。至少包括办理卫生许可证,办理税务登记,办理工商登记等。

我们先来看一下行政审批接口:

1 interface Executive{
2
3 public void approve();
4
5 }

卫生局类的定义:


1 class HealthOffice implements Executive{
2
3 @Override
4 public void approve() {
5 System.out.println("卫生局通过审批");
6 }
7
8 }

税务局类的定义:


1 class RevenueOffice implements Executive{
2
3 @Override
4 public void approve() {
5 System.out.println("税务局完成登记,定时回去收税");
6 }
7
8 }

工商局类的定义:


1 class SaicOffice implements Executive{
2
3 @Override
4 public void approve() {
5 System.out.println("工商局完成审核,办法营业执照");
6 }
7
8 }

好了,现在客户端需要上场了:


 1 public class FacadeTest {
2
3 public static void main(String[] args) {
4 System.out.println("开始办理行政手续...");
5
6 HealthOffice ho = new HealthOffice();
7 RevenueOffice ro = new RevenueOffice();
8 SaicOffice so = new SaicOffice();
9
10 ho.approve();
11 ro.approve();
12 so.approve();
13
14 System.out.println("行政手续终于办完了");
15 }
16
17 }

当然,上面的各个方法不一定都是实现同一个接口的,只是在这个例子中巧合了下。

我们发现,对客户端而言,想要的最终目的和关心的是办理完开饭店的行政审批手续,如果以办理行政手续为一个子系统来看的话,我们发现,上面的设计中客户端直接与子系统内的多个模块进行了交互,对客户端而言,比较麻烦,使得客户端不能简单的使用系统功能,且随着子系统模块的变换客户端可能也需要随着变化。

我们可以通过外观模式来解决上述问题,外观模式的一般描述是:外观模式定义了一个高层的功能,为子系统中的多个模块协同的完成某种功能需求提供简单的对外功能调用方式,使得这一子系统更加容易被外部使用。

利用外观模式对上述类进行重定义。定义一个外观类:


 1 class ApproveFacade {
2
3 public ApproveFacade() {
4
5 }
6
7 public void wholeApprove() {
8 new HealthOffice().approve();
9 new RevenueOffice().approve();
10 new SaicOffice().approve();
11 }
12
13 }

客户端调用:


 1 public class FacadeTest {
2
3 public static void main(String[] args) {
4 System.out.println("开始办理行政手续...");
5
6 ApproveFacade af = new ApproveFacade();
7 af.wholeApprove();
8
9 System.out.println("行政手续终于办完了");
10 }
11
12 }

看,通过外观模式后客户端调用够简单了吧。

外观模式的目的不是给予子系统添加新的功能接口,而是为了让外部减少与子系统内多个模块的交互,松散耦合,从而让外部能够更简单地使用子系统。

外观模式的本质是:封装交互,简化调用。

设计模式总结篇系列:外观模式(Facade),布布扣,bubuko.com

时间: 2024-10-05 19:51:03

设计模式总结篇系列:外观模式(Facade)的相关文章

【转】设计模式(九)外观模式Facade(结构型)

设计模式--外观模式Facade(结构型): 1. 概述 外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性.例子1:一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计. 2. 问题 为了降低复杂性,常常将系统划分为若干个子系统.但是如何做到各个系统之间的通信和相互依赖关系达到最小呢? 3. 解决方案 外观模

设计模式(结构型)之外观模式(Facade Pattern)

PS一句:最终还是选择CSDN来整理发表这几年的知识点,该文章平行迁移到CSDN.因为CSDN也支持MarkDown语法了,牛逼啊! [工匠若水 http://blog.csdn.net/yanbober] 阅读前一篇<设计模式(结构型)之装饰者模式(Decorator Pattern)>http://blog.csdn.net/yanbober/article/details/45395747 概述 一个客户类需要和多个业务类交互,而这些业务类经常会作为整体出现,由于涉及到的类比较多,导致使

设计模式(九)外观模式Facade(结构型)

1. 概述 外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性.例子1:一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计. 2. 问题 为了降低复杂性,常常将系统划分为若干个子系统.但是如何做到各个系统之间的通信和相互依赖关系达到最小呢? 3. 解决方案 外观模式:为子系统中的一组接口提供一个一致的界面,

设计模式总结篇系列:桥接模式(Bridge)

在实际类设计过程中,有时会遇到此类情况:由于实际的需要,某个类具有两个或两个以上的维度变化,如果利用继承将每种可能的变化情况都定义成一个类,一是会导致类膨胀的问题,二是以后不太好维护和并且违背类的设计原则.那么面对这种情况,类改如何设计呢?这就是本文所要讲到的桥接模式. 简单的讲,桥接模式是指:将抽象和行为划分开来,从而将各个可能变化的维度分离开来,各自独立成一个类,但是能够动态的组合. 貌似有点抽象,下面通过一个简单的例子来理解桥接模式. 我们可以通过Email发送信息,也可以手段短信发送信息

设计模式 - 外观模式(facade pattern) 详解

外观模式(facade pattern) 详解 本文地址: http://blog.csdn.net/caroline_wendy 外观模式(facade pattern): 提供了一个统一的接口, 用来访问子系统中的一群接口. 外观定义了一个高层接口, 让子系统更容易使用. 外观模式包含三个部分: 1. 子系统: 子类, 单个复杂子类 或 多个子类; 2. 外观(facade)类: 把子系统设计的更加容易使用; 3. 客户: 只需要调用外观类. 与适配器模式(adapter pattern)的

设计模式总结篇系列:策略模式(Strategy)

前面的博文中分别介绍了Java设计模式中的创建型模式和结构型模式.从本文开始,将分别介绍设计模式中的第三大类,行为型模式.首先我们了解下分为此三大类的依据. 创建型模式:主要侧重于对象的创建过程: 结构型模式:主要侧重于处理类或对象的组合: 行为型模式:主要侧重于类或对象之间的交互以及职责分配. 首先了解下策略模式的概念:定义了多个算法,并将它们封装起来(一般的是每个算法封装成一个单独的类),让算法独立于客户端而可以单独变化. 具体可以看一下下面的例子(以计算加.减.乘为例): 1. 对加.减.

研磨设计模式解析及python代码实现——(二)外观模式(Facade)

一.外观模式定义 为子系统中的一组接口提供一个一致的界面,使得此子系统更加容易使用. 二.书中python代码实现 1 class AModuleApi: 2 def testA(self): 3 pass 4 class AModuleImpl(AModuleApi): 5 def testA(self): 6 print "Now Call testA in AModule!" 7 class BModuleApi: 8 def testB(self): 9 pass 10 cla

设计模式之外观模式(Facade)摘录

23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式抽象了实例化过程,它们帮助一个系统独立于如何创建.组合和表示它的那些对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象.创建型模式有两个不断出现的主旋律.第一,它们都将关于该系统使用哪些具体的类的信息封装起来.第二,它们隐藏了这些类的实例是如何被创建和放在一起的.整个系统关于这些对象所知道的是由抽象类所定义的接口.因此,创建型模式在什么被创建,谁创建它,它是怎样被创建的,以

设计模式总结篇系列:代理模式(Proxy)

时代在发展,我们发现,现在不少明星都开始进行微访谈之类的,有越来越多的参与捐赠等.新的一天开始了,首先看下新的一天的日程安排: 1 interface Schedule{ 2 3 public void weiTalk(); 4 5 public void donation(); 6 7 } Schedule接口定义了今天的形成安排,主要包括微访谈和捐款.那么看一下实现此接口的明星类定义: 1 class Star implements Schedule { 2 3 @Override 4 pu