分享

IOS设计模式浅析之外观模式(Facade)

 昵称10504424 2014-01-14

引言  

  在项目开发中,有时候会遇到这样的一种情景:已有系统的各个子系统之间,随着业务需求的发展,有了比较紧凑的耦合关系。现在需要利用这些子系统的功能,为移动端提供业务处理。我们该怎么应对这样的业务需求呢?这就是本章外观模式所要解决的问题。

  进入正式讲解前,我们先来分析一下两种应对如上业务需求的方式:

  方式一:移动端直接调用各个子系统的功能,和各个子系统之间形成紧耦合的关系,如下图所示:

  方式二:提供一个高层接口,该高层接口负责和子系统进行交互,并向移动端提供需要使用的接口,如下图所示:

  从上面两种方式的图式结构可以看到,对移动端来说,方式二比方式一要好用很多,因为在方式二中,移动端不需要知道各个子系统的逻辑,只需要和高层接口交互就可以了。实际上方式二,就是我们这里要说的外观模式了。

定义

  “为子系统中的一组接口提供一个统一的接口。外观模式定义了一个更高层次的接口,这个接口使得这一子系统更加容易使用。”

  最初的定义出现于《设计模式》(Addison-Wesley,1994)。

  这个定义,通过上面引言的图示讲解,应该很好理解了,这里再分析一下定义中的两个重要角色:

  外观角色:就是引言图示中的“高层接口”,客户端可以调用这个角色的方法;另外,该角色知道相关的子系统的功能和责任。

  子系统角色:可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。每一个子系统都可以被客户端直接调用,或者被外观角色调用。

结构图

示例

  生活中,应用外观模式的例子很多,比如去饭馆吃饭,我们不需要关注菜的选料、烹调等过程,只需要和服务员进行交互:服务员给我们菜谱(相当于就是外观模式的高级接口),我们选菜(调用接口),就可以享受美食。

  这里,我们用另一个生活中的例子来进行解说。不知道大家有没有通过旅行社报团出去旅游的经历?这是一个很好的外观模式的应用。我们选择好景点之后,旅行社会帮我们联系大巴、旅馆、饭店、景点门票以及景点服务等事情,这些事情我们都不需要亲自去安排,这就是外观模式的便利之处:可以使得客户端的接口更简单。

  下面列出应用外观模式实现旅行社报团旅游的结构图:

  如果不应用外观模式,我们(上图中的Client),就得自己去联系交通工具、预定旅馆、饭馆、景点门票等,相信这样的旅程,大家会感觉很累。有了外观角色(上图中的Facade),它会帮我们去处理这些事情。完整代码大家可以下载查看,这里只贴出部分源码。

  Facade.m(部分源码):

  从源码可以看到,外观类调用了交通工具类、旅馆类、饭馆类、景点类。下面看看客户端调用代码:

  客户端代码只需要和外观类进行交互。

  下载源码

小结

  通过上面的讲解,我们来分析一下外观模式的特点:

  根据外观模式的特点,我们可以在以下情况中使用Facade模式:

  返回目录

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多