iOS 设计模式-外观模式

简介: 1.外观模式简介外观模式(Facade)在开发过程中的运用频率非常高,尤其是在现阶段各种第三方SDK充斥在我们的周边,而这些SDK很大概率会使用外观模式。

1.外观模式简介

外观模式(Facade)在开发过程中的运用频率非常高,尤其是在现阶段各种第三方SDK充斥在我们的周边,而这些SDK很大概率会使用外观模式。通过一个外观类使得整个系统的接口只有一个统一的高层接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节。当然,在我们的开发过程中,外观模式也是我们封装API的常用手段,例如网络模块、ImageLoader模块等。

2.外观模式定义

外观模式又叫门面模式。外观模式为子系统中一组不同的接口提供统一的接口。外观模式定义了上层接口,通过降低复杂度和隐藏子系统间的通信及依存关系,让子系统更易于使用。

3.外观模式的使用场景

3.1  为一个复杂子系统提供一个简单接口。子系统往往因为不断演化而变得越来越复杂,甚至可能被替换。大多数模式使用时都会产生更多、更小的类,在这使子系统更具可重用性的同时也更容易对子系统进行定制、修改,这种易变性使得隐藏子系统的具体实现变得尤为重要。Facade可以提供一个简单统一的接口,对外隐藏子系统的具体实现、隔离变化。

3.2 当你需要构建一个层次结构的子系统时,使用Facade模式定义了子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过Facade接口进行通信,从而简化了它们之间的依赖关系。

4.外观模式的UML 图

img_f1b5e1d94a9af08b2d8af8845c9d75a3.jpe
网络图片

5.角色划分

外观角色(Facade):是模式的核心,他被客户client角色调用,知道各个子系统的功能。同时根据客户角色已有的需求预订了几种功能组合

子系统角色(Subsystem classes):实现子系统的功能,并处理由Facade对象指派的任务。对子系统而言,facade和client角色是未知的,没有Facade的任何相关信息;即没有指向Facade的实例。

6.Demo 实践

  业务场景如下:

          有一位乘客需要乘坐出租车,出租车司机为驾驶出租车的一组复杂接口提供了一个简化了的接口。如图:

img_be06e84ebc5fdb16fa722b22e4c725da.jpe
参考书中的图

 通过此图可以看出整个出租车服务作为一个封闭系统,包括一名出租车司机(外观角色)、一辆车(子系统角色)、一个计价器(子系统角色)。同系统交互的唯一途径是通过CabDriver中定义的接口driveToLocation:x。一旦乘客(客户client角色)向出租车司机发出driveToLocation:x消息。CabDriver就会收到消息。司机需要操作两个子系统---Taximeter(计价器)和Car。CabDriver先启动(start)Taximeter,让他开始计价,然后司机对汽车会松刹车(releaseBrakes)、换挡(changeGears)、踩油门(pressAccelerator),把车开走。直到到达了地点x,CabDriver会松油门(releaseAccelerator)、踩刹车(pressBrakes)、停止(stop)Taximeter,结束行程。

      一切都发生于发给CabDriver的一个简单的driveToLocation:x命令之中。无论两个子系统有多么复杂,它们隐藏于乘客的实现之外。因为CabDriver是在为出租车子系统中的其他复杂接口提供了一个简化的接口。CabDriver像“外观”一样,处于乘客与出租车子系统之间。

参考代码地址:https://github.com/zhiyoukaifa/Pattern

总结:

             外观模式是一个高频率使用的设计模式,它的精髓就在于封装二字。通过一个高层次结构为用户提供统一的API入口,使得用户通过一个类型就基本能够操作整个系统,这样减少了用户的使用成本,也能够提升系统的灵活性。

  优点:

     1.对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。

       2.实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。

      3.降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。

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


  缺点:

         1.外观类接口膨胀。由于子系统的接口都有外观类统一对外暴露,使得外观类的API接口较多,在一定程度上增加了用户使用成本。

         2.不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。

         3.在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。


参考书籍:

         《Objective-C编程之道 iOS设计模式解析》

         《Android源码设计模式解析与实战》

参考链接:

           https://www.cnblogs.com/wuchanming/p/4483140.html

目录
相关文章
|
4月前
|
设计模式 API 数据安全/隐私保护
探索设计模式的魅力:外观模式简化术-隐藏复杂性,提供简洁接口的设计秘密
外观模式是一种关键的设计模式,旨在通过提供一个简洁的接口来简化复杂子系统的访问。其核心价值在于将复杂的内部实现细节封装起来,仅通过一个统一的外观对象与客户端交互,从而降低了系统的使用难度和耦合度。在软件开发中,外观模式的重要性不言而喻。它不仅能够提高代码的可读性、可维护性和可扩展性,还能促进团队间的协作和沟通。此外,随着业务需求和技术的发展,外观模式能够适应变化,通过修改外观对象来灵活调整客户端与子系统之间的交互方式。总之,外观模式在软件设计中扮演着举足轻重的角色,是构建高效、稳定且易于维护的软件系统的关键
129 1
探索设计模式的魅力:外观模式简化术-隐藏复杂性,提供简洁接口的设计秘密
|
4月前
|
设计模式 Java
23种设计模式,外观模式的概念优缺点以及JAVA代码举例
【4月更文挑战第6天】外观模式(Facade Pattern)是一种使用频率非常高的结构型设计模式,其核心思想是为子系统中的一组接口提供一个一致的界面。外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。简而言之,外观模式就是客户端与复杂子系统之间的一个简单而统一的接口
64 3
|
4月前
|
设计模式 存储 uml
C++ 设计模式实战:外观模式和访问者模式的结合使用,派生类访问基类的私有子系统
C++ 设计模式实战:外观模式和访问者模式的结合使用,派生类访问基类的私有子系统
55 1
|
1月前
|
设计模式 存储 Java
【九】设计模式~~~结构型模式~~~外观模式(Java)
文章详细介绍了外观模式(Facade Pattern),这是一种对象结构型模式,通过引入一个外观类来简化客户端与多个子系统之间的交互,降低系统的耦合度,并提供一个统一的高层接口来使用子系统。通过文件加密模块的实例,展示了外观模式的动机、定义、结构、优点、缺点以及适用场景,并讨论了如何通过引入抽象外观类来提高系统的可扩展性。
【九】设计模式~~~结构型模式~~~外观模式(Java)
|
2月前
|
设计模式 JavaScript 前端开发
js设计模式【详解】—— 外观模式
js设计模式【详解】—— 外观模式
25 2
|
4月前
|
设计模式
设计模式-外观模式
设计模式-外观模式
46 0
|
3月前
|
设计模式 Java
Java设计模式:外观模式之优雅门面(九)
Java设计模式:外观模式之优雅门面(九)
|
3月前
|
设计模式 Java
Java设计模式之外观模式详解
Java设计模式之外观模式详解
|
3月前
|
设计模式
外观模式-大话设计模式
外观模式-大话设计模式
|
4月前
|
设计模式 Go 开发工具
Golang设计模式——03外观模式
Golang设计模式——03外观模式
36 0