详述 IOS 之代理模式(Objective-c)

1. 什么是代理模式?
代理模式是在 IOS 中经常遇到的一种设计模式,那什么叫做代理模式呢? 举个例子:有一个婴儿,他本身不会自己吃饭和洗澡等等一些事情,于是婴儿就请了一个保姆,于是婴儿和保姆之间商定了一个协议,协议中写明了保姆需要做什么事情, 而保姆就是这个代理人, 即:婴儿和保姆之间有个协议,保姆继承该协议,于是保姆就需要实现该协议中的条款成为代理人。

2. 为什么使用代理模式?
A 完成一件事,但是自己不能完成,或是自己完成这件事情要花费非常大的精力,于是他找个代理人 B 替他完成这个事情,他们之间便有个协议 (protocol),B 继承该协议来完成 A 代理给他的事情。

3. 代理模式实例分析
这里举个顾客与经销商的例子。顾客与经销商之间存在联系,顾客的买卖行为要通知经销商,经销商获取顾客买东西的通知,并作出相应处理。

相关文件内容组织如下图所示(采用分栏显示):
Customer 类表示顾客,ViewController 类表示经销商。
这里写图片描述

这里写图片描述

由上述所知,顾客的经销商是一个完全给定的对象,经销商对象已经被写死了,就是当前的 ViewController。客户与当前经销商的紧密联系阻碍了客户与其他经销商联系的途径,此时便是使用代理的时候,具体文件内容改变后如下图所示(采用分栏显示):
同样的,Customer 类表示顾客,ViewController 类表示经销商。
这里写图片描述

这里写图片描述

此时,经销商成为一个代理,这个代理可以服务于任何支持这种协议的对象。

@property (nonatomic,weak) id<CustomerDelegate> delegate;

注意点

1.在是使用代理模式的时候,经常需要将代理对象传递出去,所以会用到 @class 将代理对象所属的类提前声明。

@class Customer;

@protocol CustomerDelegate <NSObject>
@required
- (void)customer:(Customer *)customer buyItemCount:(NSInteger )count;
@end

@interface Customer : NSObject
//经销商
@property (nonatomic,weak) id<CustomerDelegate> delegate;
//顾客买卖行为
- (void)buyItemCount:(NSInteger )count;
@end

@class :只是告诉编译器,这是一个类,声明类。而在实现类中如果要用到被引用类中的实体变量和方法,在 .m文件中需要使用#import来包含被引用类的头文件。

2.使用代理的时候为避免循环引用,需用 weak 指示代理变量。

@property (nonatomic,weak) id<CustomerDelegate> delegate;

3.在让代理执行某种方法的时候,需验证代理对象是否存在,以及该代理对象是否能够相应某种方法。

if (self.delegate && [self.delegate respondsToSelector:@selector(customer:buyItemCount:)]) {
        [self.delegate customer:self buyItemCount:count];
    }

如果单纯只验证代理对象是否存在而不验证该代理对象能否相应相应方法,在执行时若代理并没有实现指定方法,则会导致程序崩溃。

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值