相信做App开发的同学，对于一些第三方的统计分析、错误收集等SDK应该都不陌生。就目前而言市面上也有许多相同功能的产品，眼花缭乱，让人无法抉择选哪一款SDK才是最靠谱的。那就随便先选一款试试用吧！
那么问题来了：如果项目都快做完了结果发现这款SDK实在坑爹，不仅扩展性差，还经常让App Crash，那你是不是会想到替换掉这个SDK？
OK，那我们就换另一个试试，下载SDK下来，一看，傻眼了，设计风格，封装模块完全不一样，于是乎我们就到项目中全局搜索找到之前的SDK代码干掉，然后重新再到各种地方用新的SDK来写新的逻辑来替换，关键的是，中间还不知道会产生多少bug，漏掉多少未修改的代码，总之始终会有一种不靠谱的感觉。
换一次还算好的，如果之后团队壮大了，这些数据分析之类的东西突然想自己做了，毕竟这些有价值的数据并不想这么拱手让给一个第三方的公司嘛~这个时候你是不是就只想说：『呵呵』
所以这个时候适配器模式就起到作用了~
何为适配器模式
GoF对于适配器模式的解释如下：
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。
个人通俗理解：
适配器：顾名思义，将不兼容的转换为兼容，如电源适配器，将全世界各种不相同的电压转换成相同的电压输出给目标设备。
这里可以将目标设备理解为『接口』，世界各种电压可以理解为『产生相同功能的类』，电源适配器可以理解为『需要实现的适配器类』。
适配器模式产生的效果是：在不修改代码或者修改极少代码的情况下，快速的切换源（数据源、内容源等）。
就像电源适配器一样，去到不同国家，同一个设备只需要不同的电源适配器就可以使用当前国家的电源，而不需要取拆卸机器。
使用真实场景
如文章开头所讲，被某盟的SDK坑了之后（确实在某些状况下让App Crash，产生原因初步判断是滥用performSelector，不考虑对象被释放的情况而产生的Crash），产生替换念想而思考，如果将来替换岂不是又要苦逼我们自己？
于是乎为了将来的轻松就必须动动脑子去设计代码了，于是有了今天的适配器模式实战。
懒的程序员才是好程序员，所以才会有所谓的『面向对象』，所谓的『设计模式』。
代码
首先我们先定义好目标接口，在iOS也就是Protocol
针对统计分析这一个大模块，我先设计了KTRUserAnalysisProtocol、KTRUserEvent、KTRAutoUpdate等几个协议，通过这些协议我们可以实现我们想要的功能。
如KTRAutoUpdate中，定义的方法如下：
/**
* 检查更新
*
* @param ower 拥有者，用于判断拥有者是否存在
* @param finished 检查更新完成后回调函数
* @param result 是否为自动检查（若为自动检查则需要检查网络环境）
* @param isSilent 是否静默方式检查更新
*/
- (void)checkUpdateWith:(id)ower isAuto:(BOOL)result isSilent:(BOOL)isSilent callBack:(KTRUserAnalysisVoidBlock)finished;
- (void)checkUpdateWith:(id)ower isAuto:(BOOL)result callBack:(KTRUserAnalysisVoidBlock)finished;
- (void)checkUpdateWith:(id)ower callBack:(KTRUserAnalysisVoidBlock)finished;
/**
* 判断是否有更新
*
* @return 当checkUpdateWith检查完毕之后，一般情况会保存结果到UserDefault中，在后续其他UI中可以直接使用而不必网络检查
*/
- (BOOL)appIsNeedUpdate;
通过这些方法我就可以进行各种类型的更新检测了。
定义好Protocol之后需要做的就是创建目标基类（抽象类），犹豫Objective-C没有抽象类的概念所以，只能自己使用特殊的方法来代替，那就是在方法体中使用：
- (void)checkUpdateWith:(id)ower isAuto:(BOOL)result isSilent:(BOOL)isSilent callBack:(KTRUserAnalysisVoidBlock)finished
{
NSAssert(NO, @"具体适配器必须实现该方法");
}
这样子类在没有重载方法而调用该方法的时候就会报运行时错误，从而强制其实现。
紧接着就是实现具体的Adapter了，在这个项目中我命名为KTRUMAdapter
实现过程没有什么太多需要讲的，因为各自的业务不一样，实现也就不一样没有什么可参考性，但是这里，有一点是比较好玩的，也就之解决前说的UM的SDK没有考虑对象释放而产生的Crash。
- (void)checkUpdateWith:(id)ower isAuto:(BOOL)result isSilent:(BOOL)isSilent callBack:(KTRUserAnalysisVoidBlock)finished
{
self.updateOwer = ower;
self.updateCallback = finished;
//判断是否wifi环境
if ([self networkStatus] == ReachableViaWiFi || !result)
{
//如果为静默方式检查，则调用appSilentUpdate
if (isSilent) {
[MobClick cancelPreviousPerformRequestsWithTarget:self selector:@selector(appSilentUpdate:) object:nil];
[MobClick checkUpdateWithDelegate:self selector:@selector(appSilentUpdate:)];
return;
}
self.checkUpdateTips = YES;
__weak typeof (self)weakSelf = self;
//如果友盟检测更新10秒后无响应则自动回调
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(10 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
if (weakSelf.checkUpdateTips)
{
//取消请求
[MobClick cancelPreviousPerformRequestsWithTarget:self selector:@selector(appUpdate:) object:nil];
if(finished)
{
finished();
}
weakSelf.checkUpdateTips = NO;
}
});
[MobClick checkUpdateWithDelegate:self selector:@selector(appUpdate:)];
}
else
{
self.updateCallback = finished;
}
}
/**
* 友盟检查更新回调函数
*
* @param appInfo
*/
- (void)appUpdate:(NSDictionary *)appInfo
{
self.checkUpdateTips = NO;
if (self.updateOwer)
{
[self alertUpdateView:appInfo];
if (self.updateCallback)
{
self.updateCallback();
}
}
}
在设计的时候我使用单例模式来实现的Adapter，为的就是在App运行过程中不被释放，这样就可以保证UM的回调不会因为找不到对象而回调方法Crash，然后在单例里面判断调用该方法的对象是否还存在，存在则继续回调，如果不存在则略过当前方法。
在iOS中其实是没有必要创建这个抽象类的，直接使用Protocol然后用delegate的方式也就能够完成基类的工作。
但是为了更加方便给客户端使用，抽象类是一个不错的选择，因为在客户端只需要如此使用：
KTRUserAnalysis *userAnalysis = [KTRUserAnalysis sharedInstanceWithAdapter:[[KTRUMAdapter alloc]init]];
BOOL result = [[KTRUserAnalysis sharedInstance] appIsNeedUpdate];
后续如果要换掉Adapter，就仅仅改掉此处就皆大欢喜了。当然前提是，先要实现另一个Adapter。
总结
适配器模式的有点很多，如：将客户端与适配者解耦、使客户端调用更加简明（只需要调用定义的接口方法）。但同样也有缺点，在写适配器的时候为适应目标接口，可能会有比较复杂实现过程；无端端多出许多的类，使结构又复杂了一些。
所以在使用的时候需要因情况而定，不要生搬硬套盲目的使用设计模式。
