外观设计模式

外观设计模式

外观设计模式向复杂的子系统提供了简单的接口,相比将一系列的类和他们的接口暴露给用户,你只需要暴露一些简单的未定义的API。

接下来的图片解释了这一概念。

使用这些API接口的人完全没有意识到你这下面隐藏的复杂性,在有一系列类,特别是他们使用很复杂或者难以理解的时候,这个模式是非常好的。

外观设计模式使用从接口层面去使用,在实现技术上隐藏而将代码解藕了。它也减少了你外部的代码对于内部子系统代码的依赖性。它在外观模式可能要进行
改变的情况下也是很有用的,因为外观的类仍然可以保持相同的API当背后的情况发生了变化时。比如,有一天你想改变背后的服务代码,你不用去改变这些代码
因为这些API不会改变。

如何使用外观设计模式

目前你有PersistencyManager类去本地保存album的数据,而HTTPClient去处理远程的数据交流。工程里面的其他代码不应该意识到这个逻辑。

要实现这个LiabraryAPI你应该hold住PersistencyManager和HTTPClient的一个实例。然后LiabraryAPI会暴露一个简单的接口去访问这些服务。

小贴士:通常一个单例会在app的整个生命周期都会存在,你不应该持有过多的单例指针指向其他物体,因为它们在app关闭之前不会被释放。这个设计应该是像下面的这个图这样。

LiabraryAPI 会暴露给其他代码,但是会隐藏PersistenceManager和HTTPClient针的复杂性。

打开LiabraryAPI.h,添加#import “album.h”,接下来添加这些方法的人声明到里面。

- (NSArray *)getAlbums;  
   
- (void)addAlbum:(Album *)album atIndex:(int)index;  
   
- (void)deleteAlbumAtIndex:(int)index;

从现在开始,这些方法将会被你暴露给外部使用。

打开LiabraryAPI.m文件。加入

#import "HTTPClient.h"  
   
#import "PersistencyManager.h"

这是你导入这些类唯一的地方,记住:你的复杂的系统只能由你的API唯一的访问。现在,添加这些私有变量通过类扩展。(在@implementation上方)。

@interfaceLibraryAPI ()  
   
{  
   
    HTTPClient *client;  
   
    PersistencyManager *manager;  
   
    BOOL isOnLine;  
   
}

isOnline决定了服务器石油应该根据album表中的变化进行更新,例如添加或者删除albums.

你需要在init里面对它们进行初始化。在LiabraryAPI.m文件中添加下面代码:

-(id)init  
   
{  
   
    if (self = [superinit]) {  
   
        client = [[HTTPClientalloc]init];  
   
        manager = [[PersistencyManageralloc] init];  
   
        isOnLine = NO;  
   
    }  
   
    returnself;  
   
}

HTTPClient这个并不会真正的和一个服务器配合工作,在这里只是为了演示外观设计模式,所以isOnline总是NO。接下来在LiabraryAPI.m文件中添加这些方法。

-(NSArray *)getAlbums  
   
{  
   
    return [managergetAlbums];  
   
}  
   
 - (void)addAlbum:(Album *)album atIndex:(int)index  
   
{  
   
    [manageraddAlbum:album atIndex:index];  
   
    if (isOnLine) {  
   
                [clientpostRequest:@"/api/addAlbum"body:[album description]];  
   
    }  
   
}  
   
    
- (void)saveAlbums  
   
{  
   
    [managersaveAlbums];  
   
}  
   
- (void)deleteAlbumAtIndex:(int)index  
   
{  
   
    [managerdeleteAlbumAtIndex:index];  
   
    if (isOnLine) {  
   
        [clientpostRequest:@"/api/deleteAlbum"body:[@(index) description]];  
   
    }  
   
}

看一下这个

- (void)addAlbum:(Album *)album atIndex:(int)index

方法,这个类首先本地更新数据,然后如果由网络连接,就远程更新,这就是外观模式的魅力,如果在你系统以外的类加入了一些新的album,它不知道,也不需要去知道,这些复杂性都被隐藏在下面了。

提醒:当为你的子系统中的类设计一个外观模式,记住没有什么做什么去阻止客户端去直接访问这些隐藏的属性,不要假设所有的外部客户端都需要向你在外观模式下使用它们的方法那样去使用它们。

编译和运行你的程序,你会看见如下的空白的黑色屏幕。

你需要做点事情去在屏幕上去显示album的数据-那就是接下来的下一个设计模式:装饰设计模式。Decorator.

时间: 2024-10-08 10:27:59

外观设计模式的相关文章

php设计模式之Proxy(代理模式)和Facade(外观)设计模式

Proxy(代理模式)和Facade(外观)设计模式它们均为更复杂的功能提供抽象化的概念,但这两种实现抽象化的过程大不相同 Proxy案例中,所有的方法和成员变量都来自于目标对象,必要时,该代理能够对它所传递的数据进行修改或检查魔术方法使得Proxy的实现变的简单,Proxy模式的一类应用时用来记录方法的访问信息还可以利用Proxy的类确定代码的范围或调试程序中存在的问题 <?php class LoggingProxy{ private $target; //传递进去一个对象 public f

IOS设计模式第三篇之外观设计模式

外观设计模式: 这个外观设计模式提供了一个单独的接口给复杂的子系统.而不是暴露用户的一组类和API,你仅仅暴露一个简单的同一的API. 下面的图片解释这个概念: API的用户根本不知道后面系统的复杂性.这种模式是理想的在处理大量的类,特别是当他们复杂的使用或者很难理解的时候. 这个外观设计模式使用系统的接口和你隐藏的实现来分离代码.他也减少了依赖外部代码的子系统运作.这也是有用的如果在外观设计模式的类可能会改变,外部类可以保留相同的API同时改变幕后的事情. 例如有一天你可能想替换你的服务器端,

外观设计模式 (Facade)

目的:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使 外观设计模式使用场合: 1. 在设计初期阶段,应该有意识的将不同的两个分层.层与层之间建立外观 Facade 在开发阶段,子系统往往因不断的重构演化而变得越来越复杂.增加外观 Facade可以提供一个简单的接口,减少他们之间的依赖. 在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展,可以为新系统开发一个 Facade 类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,

二十二、外观设计模式

1. 外观设计模式介绍 显示生活中有一个种电视万能遥控器,只要和电视配对好了以后,就可以正常使用,不同型号的电视,只要一旦适配,所有的操作模式一模一样. 这就是一种外观适配模式.表面上都是同一个遥控器,实际上不同型号的电视,不同的操作,发出的型号可能各不相同.但是对于用户来说,没有任何差别. 定义 要求一个子系统的外部和其内部的通信必须通过一个统一的对象进行.门面模式提供一个高层次的接口,使得子系统更易使用. 2. 外观设计模式使用场景 为一个复杂的子系统提供简单.固定的接口.比如我们常用的加载

设计模式第9篇:外观设计模式

一.外观设计模式所解决的问题 外观设计模式为子系统中的一组接口提供统一的接口,这种统一的接口屏蔽了直接调用子系统时的逻辑关系,使得调用子系统时更容易. 二.外观设计模式用例 假如一个应用中有两个接口MysqlHelper.class和OracleHelper.class,两个接口功能分别是连接mysql和oracle数据库,然后生成HTML报表或者PDF报表,代码说明如下: MysqlHelper.class和OracleHelper.class import java.sql.Connecti

C++外观设计模式模式(三)

3.外观模式总结 引入了外观类.解除了客户类与子系统的耦合性.客户类不须要直接操作子系统,而是由外观类负责处理,对client而言是透明的,客户类仅仅须要操作外观类就能够了,符合"迪迷特法则".假设多个地方须要Facade.也就是说外观能够实现功能的共享,也就是实现复用.相同的调用代码仅仅用在Facade里面写一次就好了.不用在多个调用的地方反复写.假设某个系统模块须要改动.仅仅须要改动这个系统模块就能够了,对client无影响,维护性好.另一个潜在优点.对使用Facade的人员来说,

java语言实现结构型设计模式—外观模式

一.描述 外观模式又叫门面模式,就是对一个复杂的系统进行包装,该系统对外的接口统一由外观类提供.当一个复杂的系统需要对外提供接口时,就需要将对外提供的接口统一封装在一个外观类中供外系统使用.外观模式最大的特点就是将细粒度的对象包装成粗粒度的对象,应用程序通过访问这个外观对象来完成细粒度对象的调用.这样应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性. 总的来说,外观模式就是为子系统对外提供的一组接口,这组接口提供一个统一的界面,使得其它

设计模式——外观

外观设计模式比较简单,我们平时就会用的比较多. 本质就是为了上层更加方便的使用某个系统,提供一个中间的.总结性的.相对较统一的中间层.使得系统更加易用(上层只需要使用中间层调用系统的功能就好). 为啥叫外观模式:外观是指低一层(或者被调用层)系统的抽象出来的,对外的接口.外界其实只是使用这个接口就可以使用整个系统,也就是外界只看得到中间这层,中间层表达了被使用系统的外观. 外观模式中最重要的角色:中间层(中介.接口) 使用场景: 豆浆机 买房子中介 我们常用的tools.Utils类 api 两

Objective-C设计模式——外观Faced(接口适配)

外观模式 外观设计模式和适配器差不多,不过它门对对象控制的粒度不同,适配器一般只是控制一个系统和客户端的对接.外观则是用来抽象多个系统一起工作. 外观一般具有多个子系统,所以外观应持有多个子系统的引用,同构向高层提供抽象接口实现封装.外观一般是可以多次使用的,比如一个庞大的系统中,可以多次使用外观来进行封装,然后再对外观使用外观封装达到多层抽象的目的. 使用场景 子系统正逐渐变得复杂.应用模式的过程中演化出来许多类.可以使用外观为这些子系统类提供一个较简单的接口. 可以使用外观对子系统进行分层.