实例解析设计模式中的外观模式在iOS App开发中的运用

外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义 一个高层接口,这个接口使得这一子系统更加容易使用。

下面给大家展示一下类的结构图,想必大家一看就明白了:

其实这个模式中,没有类与类之间的继承关系,只是进行了简单的类引用,统一了对外的接口而已。看起来是不是很简单?废话不多说了,下面简单向大家展示一下代码吧!

注意:本文所有代码均在ARC环境下编译通过。

SubSystemOne类接口

代码如下:

#import <Foundation/Foundation.h>

@interface SubSystemOne:NSObject
-(void)MethodOne;
@end

SubSystemOne类实现

代码如下:

#import "SubSystemOne.h"

@implementation SubSystemOne
-(void)MethodOne{
    NSLog(@"子系统方法一");
}
@end

SubSystemTwo类接口

代码如下:

#import <Foundation/Foundation.h>

@interface SubSystemTwo:NSObject
-(void)MethodTwo;
@end

SubSystemTwo类实现

代码如下:

#import "SubSystemTwo.h"

@implementation SubSystemTwo
-(void)MethodTwo{
    NSLog(@"子系统方法二");
}
@end

SubSystemThree类接口

代码如下:

#import <Foundation/Foundation.h>

@interface SubSystemThree:NSObject
-(void)MethodThree;
@end

SubSystemThree类实现

代码如下:

#import "SubSystemThree.h"

@implementation SubSystemThree
-(void)MethodThree{
    NSLog(@"子系统方法三");
}
@end

SubSystemFour类接口

代码如下:

#import <Foundation/Foundation.h>

@interface SubSystemFour:NSObject
-(void)MethodFour;
@end

SubSystemFour类实现

代码如下:

#import "SubSystemFour.h"

@implementation SubSystemFour
-(void)MethodFour{
    NSLog(@"子系统方法四");
}
@end

Facade类接口

代码如下:

#import<Foundation/Foundation.h>

@class SubSystemOne;//此处@class关键字的作用是声明(不是定义哦)所引用的类
@class SubSystemTwo;
@class SubSystemThree;
@class SubSystemFour;
@interface Facade :NSObject{
@private SubSystemOne *one;
@private SubSystemTwo *two;
@private SubSystemThree *three;
@private SubSystemFour *four;
}
-(Facade*)MyInit;
-(void)MethodA;
-(void)MethodB;
@end

Facade类实现

代码如下:

#import "Facade.h"
#import "SubSystemOne.h"
#import "SubSystemTwo.h"
#import "SubSystemThree.h"
#import "SubSystemFour.h"

@implementation Facade
-(Facade*)MyInit{
    one= [[SubSystemOne alloc]init];
    two= [[SubSystemTwo alloc]init];
    three= [[SubSystemThree alloc]init];
    four= [[SubSystemFour alloc]init];
    return self;
}
-(void)MethodA{
    NSLog(@"\n方法组A() ---- ");
    [one MethodOne];
    [two MethodTwo];
    [three MethodThree];
    [four MethodFour];
}
-(void)MethodB{
    NSLog(@"\n方法组B() ---- ");
    [two MethodTwo];
    [three MethodThree];
}
@end

Main()方法调用

代码如下:

#import <Foundation/Foundation.h>
#import "Facade.h"

int main (int argc,const char * argv[])
{
    @autoreleasepool{
        Facade *facade = [[Facade alloc]MyInit];
        [facade MethodA];
        [facade MethodB];
    }
    return 0;
}

在开发软件时候,考虑使用外观模式的情况一般分为三种情况。第一种情况,设计初始阶段,应该要有意识的将不同的两个分层分离,层与层之间建立外观Facade,这样可以为复杂的子系统提供一个简单的接口,使得耦合大大降低。第二种情况,在开发阶段子系统往往因为不断的重构演化而变得越来越复杂,增加外观Facade可以提供一个简单的接口,减少它们之间的依赖。第三种情况,在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展了,如果有新的需求,那么可以为新系统开发一个外观Facade类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,让新系统与Facade对象交互,Facade与遗留代码交互所有复杂的工作,这样可以保持较低的耦合度。

实例进阶
目前你有 PersistencyManager 来在本地存储专辑数据,HTTPClient 处理远程通信。项目中其它的类跟这些逻辑都没关。

执行这个模式,只有 LibraryAPI 来保存 PersistencyManager 和 HTTPClient 的实例。之后,LibraryAPI 将会公开一个简单的 API 来访问这些服务。

LibraryAPI 将会公开给其它代码,但是它隐藏了 APP 中 HTTPClient 和 PersistencyManager 的复杂部分。

打开 LibraryAPI.h,在顶部引入面文件:

#import "Album.h"
接下来,在 LibraryAPI.h下面添加如下方法:

代码如下:

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

现在,这些方法都公开给了其它类。

在 LibraryAPI.m 文件引入如下两个文件:

#import "PersistencyManager.h"
#import "HTTPClient.h"
只有在这个地方你才会需要引入这些类。记住:你的 API 将会是你「复杂」系统的唯一的接入点。

现在添加一些私有属性在你的类的扩展里(在 @implementation 上面)

代码如下:

@interface LibraryAPI () {
    PersistencyManager *persistencyManager;
    HTTPClient *httpClient;
    BOOL isOnline;
}
@end

isOnline 用来判断,如果专辑列表数据发生变化是否能够更新到服务器,例如添加或者删除专辑。

你现在需要在 init 方法中初始化这些变量,在 LibraryAPI.m 中添加下面代码:

代码如下:

- (id)init
{
    self = [super init];
    if (self) {
        persistencyManager = [[PersistencyManager alloc] init];
        httpClient = [[HTTPClient alloc] init];
        isOnline = NO;
    }
    return self;
}

这个 HTTP 客户端在这里并不真正的工作,它只是在外观设计里面起一个示范用法的作用,所以 isOnline 永远是 NO 了。

接下来,在 LibraryAPI.m 里面添加下面三个方法:

代码如下:

- (NSArray*)getAlbums
{
    return [persistencyManager getAlbums];
}

- (void)addAlbum:(Album*)album atIndex:(int)index
{
    [persistencyManager addAlbum:album atIndex:index];
    if (isOnline)
    {
        [httpClient postRequest:@"/api/addAlbum" body:[album description]];
    }
}

- (void)deleteAlbumAtIndex:(int)index
{
    [persistencyManager deleteAlbumAtIndex:index];
    if (isOnline)
    {
        [httpClient postRequest:@"/api/deleteAlbum" body:[@(index) description]];
    }
}

看一下 addAlbum:atIndex:。这个类首先更新本地数据,如果联网,它再更新远端服务器。这就是外观设计的长处;当一些系统外的类添加了一个新专辑,它不知道─也不需要知道─复杂的内部系统。

提示:当在你的子系统里设计一个外观类的时候,记住没有任何东西可能阻止客户访问这些「隐藏」类。要多写些防御性的代码,不要想当然的认为所有客户都会用同样的方式使用你的外观类。
运行你的程序,你会看一个黑底空白内容的屏幕,像下面这样:

(0)

相关推荐

  • IOS开发中的设计模式汇总

    iOS开发学习中,经常弄不清楚ios的开发模式,今天我们就来进行简单的总结和探讨~ (一)代理模式 应用场景:当一个类的某些功能需要由别的类来实现,但是又不确定具体会是哪个类实现. 优势:解耦合 敏捷原则:开放-封闭原则 实例:tableview的 数据源delegate,通过和protocol的配合,完成委托诉求. 列表row个数delegate 自定义的delegate (二)观察者模式 应用场景:一般为model层对,controller和view进行的通知方式,不关心谁去接收,只负责发布

  • iOS应用运用设计模式中的Strategy策略模式的开发实例

    在写程序的时候,我们经常会碰到这样的场景:把一堆算法塞到同一段代码中,然后使用if-else或switch-case条件语句来决定要使用哪个算法?这些算法可能是一堆相似的类函数或方法,用以解决相关的问题.比如,一个验证输入数据的例程,数据本身可以是任何数据类型(如NSString.CGFloat等),每种数据类型需要不同的验证算法.如果能把每个算法封装成一个对象,那么就能消除根据数据类型决定使用什么算法的一堆if-else或switch-case语句. 我们把相关算法分离为不同的类,称为策略模式

  • 详解iOS应用的设计模式开发中Mediator中介者模式的使用

    何为中介者模式? 面向对象的设计鼓励把行为分散到不同对象中,这种分散可能导致对象之间的相互关联.在最糟糕的情况下,所有对象都彼此了解并相互操作. 虽然把行为分散到不同对象增强了可复用性,但是增加的相互关联又减少了获得的益处.增加的关联使得对象很难或不能在不依赖其他对象的情况下工作.应用程序的整体行为可能难以进行任何重大修改,因为行为分布于许多对象.于是结果可能是创建越来越多的子类,以支持应用程序中的任何新行为. 中介者模式:用一个对象来封装一系列对象的交互方式.中介者使各对象不需要显式地相互引用

  • iOS App的设计模式开发中对State状态模式的运用

    1.概述 在软件开发过程中,应用程序可能会根据不同的情况作出不同的处理.最直接的解决方案是将这些所有可能发生的情况全都考虑到.然后使用if... ellse语句来做状态判断来进行不同情况的处理.但是对复杂状态的判断就显得"力不从心了".随着增加新的状态或者修改一个状体(if else(或switch case)语句的增多或者修改)可能会引起很大的修改,而程序的可读性,扩展性也会变得很弱.维护也会很麻烦.那么我就考虑只修改自身状态的模式. 例子1:按钮来控制一个电梯的状态,一个电梯开们,

  • iOS App设计模式开发中策略模式的实现示例

    这次介绍一下策略模式(Strategy Pattern),相比之下是一种比较简单的模式.它也叫政策模式(Policy Pattern). 策略模式使用的就是面向对象的继承和多态机制,其他的没有什么玄机.策略模式适合使用在: 1. 多个类只有在算法或行为上稍有不同的场景. 2. 算法需要自由切换的场景. 3. 需要屏蔽算法规则的场景. 使用策略模式当然也有需要注意的地方,那么就是策略类不要太多,如果一个策略家族的具体策略数量超过4个,则需要考虑混合模式,解决策略类膨胀和对外暴露问题.在实际项目中,

  • iOS App开发中使用设计模式中的单例模式的实例解析

    一.单例的作用 顾名思义,单例,即是在整个项目中,这个类的对象只能被初始化一次.它的这种特性,可以广泛应用于某些需要全局共享的资源中,比如管理类,引擎类,也可以通过单例来实现传值.UIApplication.NSUserDefaults等都是IOS中的系统单例. 二.单例模式的两种写法 1,常用写法 #import "LGManagerCenter.h" static LGManagerCenter *managerCenter; @implementation LGManagerCe

  • 深入解析设计模式中的装饰器模式在iOS应用开发中的实现

    装饰器模式可以在不修改代码的情况下灵活的为一对象添加行为和职责.当你要修改一个被其它类包含的类的行为时,它可以代替子类化方法. 一.基本实现 下面我把类的结构图向大家展示如下: 让我们简单分析一下上面的结构图,Component是定义一个对象接口,可以给这些对象动态地添加职责.ConcreteComponent是定义了一个具体的对象,也可以给这个对象添加一些职责.Decorator,装饰抽象类,继承了Component,从外类来扩展Component类的功能,但对于Component来说,是无需

  • iOS App设计模式开发中对迭代器模式的使用示例

    何为迭代器模式? 迭代器提供了一种顺序访问集合对象中元素的方法,而无需暴漏结构的底层表示和细节.遍历集合中元素的职能从集合本身转移到迭代器对象.迭代器定义了一个用于访问集合元素并记录当前元素的接口.不同的迭代器可以执行不同的策略. 例子 说了这么多,下面给大家展示一下类关系图. 上图中Client的右边是迭代器,左边是具体迭代的类型,在迭代器内部对具体需要迭代的类型进行了引用,还算不难理解吧,呵呵.其实,看起来是为了对具体类型进行解耦.好啦,下面给出具体的代码实现,简单的模拟了迭代器模式. 注意

  • 实例解析设计模式中的外观模式在iOS App开发中的运用

    外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义 一个高层接口,这个接口使得这一子系统更加容易使用. 下面给大家展示一下类的结构图,想必大家一看就明白了: 其实这个模式中,没有类与类之间的继承关系,只是进行了简单的类引用,统一了对外的接口而已.看起来是不是很简单?废话不多说了,下面简单向大家展示一下代码吧! 注意:本文所有代码均在ARC环境下编译通过. SubSystemOne类接口 复制代码 代码如下: #import <Foundation/Foundation.

  • 实例讲解设计模式中的命令模式在iOS App开发中的运用

    命令模式封装一个请求或行为作为一个对象.封装的请求比原的更加灵活,可以在对象之间传递,储存,动态修改,或放入一个队列. 那么让我们简要的说一下命令模式的特点. 它能比较容易地设计一个命令队列: 在需要的情况下,可以较容易地将命令记入日志: 允许接收请求地一方决定是否要否决请求: 可以容易地实现对请求地撤销和重做: 由于加进新地具体命令类不影响其他的类,因此增加新的具体命令类很容易: 把请求一个操作的对象与知道怎么执行一个操作的对象分隔开. 下面给出基本的类结构图: 上面这张图是命令模式的类结构的

  • 设计模式开发中的备忘录模式在iOS应用开发中的运用实例

    何为备忘录模式? 在响应某些事件时,应用程序需要保存自身的状态,比如当用户保存文档或程序退出时.例如,游戏退出之前,可能需要保存当前会话的状态,如游戏等级.敌人数量.可用武器的种类等.游戏再次打开时,玩家可以从离开的地方接着玩.很多时候,保存程序的状态真的不需要什么特别巧妙的方法.任何简单有效的方法都可以,但是同时,保存信息应该只对原始程序有意义.原始程序应该是能够解码它所保存文档中的信息的唯一实体.这就是备忘录模式应用于游戏.文字处理等程序的软件设计中的方式,这些程序需要保存当前上下文的复杂状

  • 举例讲解设计模式中的原型模式在iOS应用开发中的作用

    1 前言 在许多面向对象的应用程序中,有些对象的创建代价过于大或者过于复杂.要是可以重建相同的对象并作轻微的改动,事情会容易许多.我们可以通过轻微的改动重用已有的对象,以适应程序中的特定情况.今天我们就来学习一下该模式. 2 详述 2.1 定义 应用于"复制"操作的模式成为原型(Prototype)模式.复制(cloning)指用同一模具生产一系列的产品.模具所基于的物品称为原型.尽管产品是用同一模具复制的,但是某些属性,如颜色与尺寸,可以稍有不同,但是他们还是属于同一类. 2.2 何

  • Java 代码实例解析设计模式之监听者模式

    代码展示 Main:测试类 ObServer:每个被监听的对象实现该接口,重写该方法,完成自己的业务 public interface ObServer { /** * 当某一个被监控的对象发生变化时 * 所有实现该方法处理方法 */ void exceptionHandler(); } Subject:监听者容器 public interface Subject { /** * 添加被观察对象 */ void add(ObServer obServer); /** * 通知所有被观察者完成自己

  • iOS App开发中UIViewController类的使用教程

    一.引言 作为MVC设计模式中的C,Controller一直扮演着项目开发中最重要的角色,它是视图和数据的桥梁,通过它的管理,将数据有条有理的展示在我们的View层上.iOS中的UIViewController是UIKit框架中最基本的一个类.从第一个UI视图到复杂完整项目,都离不开UIViewController作为基础.基于UIViewController的封装和扩展,也能够出色的完成各种复杂界面逻辑.这里旨在讨论UIViewController的生命周期和属性方法,在最基础的东西上,往往会

  • iOS App开发中扩展RCLabel组件进行基于HTML的文本布局

    iOS系统是一个十分注重用户体验的系统,在iOS系统中,用户交互的方案也十分多,然而要在label中的某部分字体中添加交互行为确实不容易的,如果使用其他类似Button的控件来模拟,文字的排版又将是一个解决十分困难的问题.这个问题的由来是项目中的一个界面中有一些广告位标签,而这些广告位的标签却是嵌在文本中的,当用户点击文字标签的位置时,会跳转到响应的广告页. CoreText框架和一些第三方库可以解决这个问题,但直接使用CoreText十分复杂,第三方库多注重于富文本的排版,对类似文字超链接的支

  • Objective-C的缓存框架EGOCache在iOS App开发中的使用

    EGOCache简介 EGOCache is a simple, thread-safe key value cache store. It has native support for NSString, UI/NSImage, and NSData, but can store anything that implements <NSCoding>. All cached items expire after the timeout, which by default, is one da

  • iOS App开发中使cell高度自适应的黑魔法详解

    在使用 table view 的时侯经常会遇到这样的需求:table view 的 cell 中的内容是动态的,导致在开发的时候不知道一个 cell 的高度具体是多少,所以需要提供一个计算 cell 高度的算法,在每次加载到这个 cell 的时候计算出 cell 真正的高度. 在 iOS 8 之前 没有使用 Autolayout 的情况下,需要实现 table view delegate 的 tableView(tableView: UITableView, heightForRowAtInde

随机推荐