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

外观模式

外观设计模式和适配器差不多,不过它门对对象控制的粒度不同,适配器一般只是控制一个系统和客户端的对接。外观则是用来抽象多个系统一起工作。

外观一般具有多个子系统,所以外观应持有多个子系统的引用,同构向高层提供抽象接口实现封装。外观一般是可以多次使用的,比如一个庞大的系统中,可以多次使用外观来进行封装,然后再对外观使用外观封装达到多层抽象的目的。

使用场景

子系统正逐渐变得复杂。应用模式的过程中演化出来许多类。可以使用外观为这些子系统类提供一个较简单的接口。

可以使用外观对子系统进行分层。每个子系统级别有一个外观作为入口点。让它们通过其外观进行通信,可以简化它们的依赖关系。

Demo

因为也是接口适配,只不过是应用场景不同,差异并不是很大,就不详细描述了。

用打的的场景来模拟外观模式,打的存在司机开车和计价两个系统,用Faced进行封装,提供

driveToLocation:接口

#import <Foundation/Foundation.h>

@interface Taximeter : NSObject

-(void)start;
-(void)stop;

@end

#import "Taximeter.h"

@implementation Taximeter

-(void)start
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

-(void)stop
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

@end

#import <Foundation/Foundation.h>

@interface Car : NSObject

-(void) releaseBrakes;
-(void) changeGears;
-(void) pressAccelerator;
-(void) pressBrakes;
-(void) releaseAccelerator;

@end

#import "Car.h"

@implementation Car

-(void) releaseBrakes
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

-(void) changeGears
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

-(void) pressAccelerator
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

-(void) pressBrakes
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

-(void) releaseAccelerator
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}

@end

Faced

#import <Foundation/Foundation.h>

@interface Faced : NSObject

-(void)driveToLocation:(CGPoint)x;

@end

#import "Faced.h"
#import "Taximeter.h"
#import "Car.h"
@implementation Faced

-(void)driveToLocation:(CGPoint)x
{
    Taximeter *meter = [Taximeter new];
    [meter start];

    Car *car = [Car new];
    [car releaseBrakes];
    [car changeGears];
    [car pressAccelerator];

    [car releaseAccelerator];
    [car pressBrakes];
    [meter stop];
}

@end

客户端和结果

[[Faced new] driveToLocation:CGPointZero];

2015-07-26 11:06:38.004 Faced[656:20064] start
2015-07-26 11:06:38.005 Faced[656:20064] releaseBrakes
2015-07-26 11:06:38.005 Faced[656:20064] changeGears
2015-07-26 11:06:38.006 Faced[656:20064] pressAccelerator
2015-07-26 11:06:38.006 Faced[656:20064] releaseAccelerator
2015-07-26 11:06:38.006 Faced[656:20064] pressBrakes
2015-07-26 11:06:38.006 Faced[656:20064] stop
时间: 2024-11-06 07:26:34

Objective-C设计模式——外观Faced(接口适配)的相关文章

设计模式(7)--适配式模式与外观模式

转换接口. 引入新原则: " 最少知识"原则   作用为 外观模式 面向对象的适配器:将一个接口转换成另一个接口,以符合客户的期望. 对象适配器  与  类适配器 OO原则:(1)封装变化 (2)多用组合,少用继承 (3)针对接口编程,不针对实现编程 (4)为交互对象之间的松耦合设计而努力 (5)类应该对扩展开放,对修改关闭.(6) 依赖抽象,不要依赖具体类.(7)只和朋友交流. OO模式: 适配器模式-:将一个类的接口,转换成客户期望的另一个接口.适配器让原本接口不兼容的类可以合作无

设计模式【8】:外观设计【接口适配】

Gof上的官方定义:外观模式为子系统中一组不同的接口提供统一的接口.外观定义了上层接口,通过降低复杂度和隐藏子系统间的通信及依存关系,让子系统易于使用. 其实这个设计模式我们很常见,一般我们使用第三方类的时候都会有这种模式,使用第三方时我们只需要引用第三方的其中改一个文件就能满足很多功能的使用.我只这个文件就是讲子系统的一些方法归并到了这个文件中,从而使使用者上手更快. 以后应该多使用这种设计模式,一方面可以增加项目的可读性,项目的易维护性,更重要的是多人协作开发时可以提高开发效率. 设计模式[

设计模式【6】:适配器模式【接口适配】

pcDuino3下支持mmc启动,官方的Uboot是采用SPL框架实现的,因为内部的SRAM空间达到32K,我们完全可以在这32K空间内编写一个完整可用小巧的bootloader来完成引导Linux kernel的目的. 我们首先介绍下SPL框架,可以先看下<GNU ARM汇编--(十八)u-boot-采用nand_spl方式的启动方法>和<GNU ARM汇编--(十九)u-boot-nand-spl启动过程分析>,NAND_SPL也算是SPL框架下的一种模式. 当使用Nand f

设计模式【7】:桥接模式【接口适配】

1,定义 Gof23设计模式中是这样定义桥接设计模式:桥接模式的目的是把抽象层次结构从其实现中分离出来,使其能够独立变更.抽象层定义了供客户端使用的上层的抽象接口.实现层次结构定义了供抽象层次使用的底层接口.实现类的引用被封装于抽象类的实例中时,桥接就形成了. 我们用一个游戏的例子去理解这个桥接模式,比如,我们假如魂斗罗一代,魂斗罗二代界面没多大变化,可以共用一套底层接口. 上面这个图:左侧部分Abstraction是抽象类,右侧部分是实现类. 按照定义,实现类应该是实现具体的底层接口,我们都知

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

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

设计模式 外观模式 一键电影模式

转载请标明出处:http://blog.csdn.net/lmj623565791/article/details/25837275 这个模式比较简单,嘿嘿,简单写一下. 老样子,先看 外观模式(Facade Pattern)定义:提供一个统一的接口,用来访问子系统中的一群接口,外观定义了一个高层的接口,让子系统更容易使用.其实就是为了方便客户的使用,把一群操作,封装成一个方法. 举个例子:我比较喜欢看电影,于是买了投影仪.电脑.音响.设计了房间的灯光.买了爆米花机,然后我想看电影的时候,我需要

浅谈Python设计模式 - 外观模式

声明:本系列文章主要参考<精通Python设计模式>一书,并且参考一些资料,结合自己的一些看法来总结而来. 外观模式 外观模式的核心在于将复杂的内部实现包装起来,只向外界提供简单的调用接口.类似现实世界中的电脑,开机按钮可以说就是一个简单的调用接口,帮用户屏蔽了复杂的内部电路. 外观设计模式 -- 有助于隐藏系统的内部复杂性,并且通过一个简化的接口向客户端暴露必要的部分.本质上,外观是在已有复杂系统之上实现的一个抽象层. 本来想引用书中的例子,但是其整个代码被复杂化,不好理解.然后在网上看到一

机房重构包图(从三层+实体到三层+实体+外观+工厂+接口+SQLHelper)

刚刚开始接触三层的时候,我只做了两个登录小窗体的例子.画了简单的包图,可以说,为后面机房重构留下了大量的工作(因为三层理解没有深度,也没有理解出自己的东西).不过,欠下的总要还的.在做机房重构的时候,问题出现了.如果只用三层+实体,我能做出来,但是,要求重构不能只用三层+实体,那么,就要好好分析一下了. 首先说说三层+实体:就是表现层(U层)直接调用业务逻辑层(B层)的逻辑,业务逻辑层在直接访问数据层(D层),在把数据返回到B层后返回到U层.首先,只用三层+实体做程序时,灵活性不够高.如果想换数

Objective C设计模式之外观模式facade

一个框架中如果包含的类比较多,或者功能比较复杂的情况下,可以通过一个较辅助类为一些常用的情况提供简单的接口.这样客户在使用这个框架的时候既可以比较简单的应付常见的场景,又可以使用框架中的内实现符合自己要求的功能.这就好比买电脑的时候,即可以买品牌机,又可以自己买配件组装.下面就拿买电脑来举例. 假设电脑由显示器.主板.CPU.内存和显卡组成.当然,实际远远不止这些.每个设备都有许多的参数需要选择,我们给它们分别定义一个类去完成选择的工作. //选择显示器@interface Display :