博客更新记录:首先感谢 Casa Taloyum 前辈对该篇博客错误的指出(或者说打脸😭哈哈),笔者对 AOP 理解错误影响到各位读者的阅读体验,在此深表歉意。Casa Taloyum 前辈指出该玩儿法应该叫做 Proxy 模式,笔者对其了解了一番,深以为然。 ———— 2018-4-24
一、写在前面
Proxy 设计模式:为其他对象提供一种代理以控制对这个对象的访问。
在 iOS 开发中,Proxy 设计模式的体现更多的是以单个代理的方式,笔者为了优雅的达到更深层次的模块化,基于消息转发间接的实现多代理。
喜欢看代码的可直接看 DEMO
Proxy 局部模块化 DEMO
二、更深层次模块化
在 iOS App 中,MVC 和 MVVM 是比较流行的架构模式,而当某个界面业务量达到一个程度过后,MVVM 甚至是 VIPER 模式都显得有些力不从心。
为了达到更高层次的模块化,往往会做其他方面的工作,比如将UITableView
等代理方法的实现独立出,然而代理方法里面的逻辑太多会导致独立出来的类仍然臃肿;更细化一点的法子是在代理方法里面将具体实现分离出去,由其他类完成。
不过,这些方式都不够优雅。
所以,这就是本文的目的,提供一种更深层次的模块化的方案。
三、实际应用
Proxy设计模式,在笔者之前的框架中已经有了应用,实现该框架难点就是:利用方法重定向实现多接收者的消息转发。
详情可看这篇文章,文章中间部分有对消息转发流程的简述:
iOS解决方案:文本输入控制(献上框架)
本文就不讲解消息发送机制了,在 Demo 中有封装 —— YBProxyManager,我们将利用它来做局部模块化。
在实际业务需求中,出场率很高的是UITalbeView
和UICollecitonView
等需要用大量代理方法配置的视图,当然这是苹果程序设计的惯例。当UI界面很复杂,业务逻辑相当多的时候,虽然把网络请求、数据处理、视图封装等都模块分离出去了,但是配置代理里面的逻辑太多,我们想要每一个类处理一部分代理方法。
Demo 以 UITableView 为例。
首先,创建实现 UITableView 代理的三个类:
@implementation TestTableViewDigitConfig
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return 20;
}
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 80;
}
@end
@implementation TestTableViewClickConfig
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
NSLog(@"click -- section:%ld, row:%ld", indexPath.section, indexPath.row);
}
@end
@implementation TestTableViewCellConfig
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:NSStringFromClass(UITableViewCell.class)];
if (!cell) {
cell.selectionStyle = UITableViewCellSelectionStyleNone;
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleValue1 reuseIdentifier:NSStringFromClass(UITableViewCell.class)];
}
cell.textLabel.text = [NSString stringWithFormat:@"第%ld行", indexPath.row];
return cell;
}
@end
如代码所见,这里将 tableView 的代理用三个类来分别实现,然后在 UIViewController 里面只需要写这些代码:
@interface TestVC ()
@property (nonatomic, strong) UITableView *tableView;
@property (nonatomic, strong) YBProxyManager *proxyManager;
@property (nonatomic, strong) TestTableViewDigitConfig *digitConfig;
@property (nonatomic, strong) TestTableViewClickConfig *clickConfig;
@property (nonatomic, strong) TestTableViewCellConfig *cellConfig;
@end
@implementation TestVC
#pragma mark life cycle
- (void)viewDidLoad {
[super viewDidLoad];
[self.view addSubview:self.tableView];
}
#pragma mark getter
- (UITableView *)tableView {
if (!_tableView) {
_tableView = [[UITableView alloc] initWithFrame:[UIScreen mainScreen].bounds style:UITableViewStylePlain];
_tableView.tableFooterView = [UIView new];
_digitConfig = [TestTableViewDigitConfig new];
_clickConfig = [TestTableViewClickConfig new];
_cellConfig = [TestTableViewCellConfig new];
_proxyManager = [YBProxyManager new];
[_proxyManager addTarget:_digitConfig];
[_proxyManager addTarget:_clickConfig];
[_proxyManager addTarget:_cellConfig];
_tableView.delegate = _proxyManager;
_tableView.dataSource = _proxyManager;
}
return _tableView;
}
@end
核心代码就是将 YBProxyManager 类的使用:
当你需要使用多个对象(target)来承接一些方法的实现,初始化 YBProxyManager 实例,将这些对象实例添加到
YBProxyManager 实例中(addTarget),最后将 YBProxyManager 实例作为这些方法的第一承接者。剩下的方法分发工作就交给该类了。
代码请看 DEMO,不复杂。
网友评论
521也许不止是有爱情😂
目的是达到模块细化,而不是复用,而复用部分就是消息转发的处理,既YBProxyManager。
你说的cell与tableview密切关系,在所有代理里面就有反tableivew,数据源的处理方面确实要麻烦一点,但是在逻辑超多的情况下,模块细化带来的收益远大于多处理一个数据源。其实经常考虑架构方面的东西,这些设计方式都是灵活的,只是这里提出的多代理方式模块划分比较优雅
_tableView.dataSource = _aopManager;
这两行会有警告,强迫症不会考虑。而且有可能漏掉 @required 的方法。