相信做App开发的同学,对于一些第三方的统计分析、错误收集等SDK应该都不陌生。就目前而言市面上也有许多相同功能的产品,眼花缭乱,让人无法抉择选哪一款SDK才是最靠谱的。那就随便先选一款试试用吧!
那么问题来了:如果项目都快做完了结果发现这款SDK实在坑爹,不仅扩展性差,还经常让App Crash,那你是不是会想到替换掉这个SDK?
OK,那我们就换另一个试试,下载SDK下来,一看,傻眼了,设计风格,封装模块完全不一样,于是乎我们就到项目中全局搜索找到之前的SDK代码干掉,然后重新再到各种地方用新的SDK来写新的逻辑来替换,关键的是,中间还不知道会产生多少bug,漏掉多少未修改的代码,总之始终会有一种不靠谱的感觉。
换一次还算好的,如果之后团队壮大了,这些数据分析之类的东西突然想自己做了,毕竟这些有价值的数据并不想这么拱手让给一个第三方的公司嘛~这个时候你是不是就只想说:『呵呵』
所以这个时候适配器模式就起到作用了~
何为适配器模式
GoF对于适配器模式的解释如下:
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。
个人通俗理解:
适配器:顾名思义,将不兼容的转换为兼容,如电源适配器,将全世界各种不相同的电压转换成相同的电压输出给目标设备。
这里可以将目标设备理解为『接口』,世界各种电压可以理解为『产生相同功能的类』,电源适配器可以理解为『需要实现的适配器类』。
适配器模式产生的效果是:在不修改代码或者修改极少代码的情况下,快速的切换源(数据源、内容源等)。
就像电源适配器一样,去到不同国家,同一个设备只需要不同的电源适配器就可以使用当前国家的电源,而不需要取拆卸机器。
使用真实场景
如文章开头所讲,被某盟的SDK坑了之后(确实在某些状况下让App Crash,产生原因初步判断是滥用performSelector,不考虑对象被释放的情况而产生的Crash),产生替换念想而思考,如果将来替换岂不是又要苦逼我们自己?
于是乎为了将来的轻松就必须动动脑子去设计代码了,于是有了今天的适配器模式实战。
如何使用适配器模式
一个适配器允许接口不兼容的类在一起工作。它把它自己包裹成一个对象,公开一个与这个对象相互作用的标准接口。
如果你熟习适配器模式,你会注意到苹果实施它的时候有一点不同的习惯─苹果使用协议 (protocols)。你可能熟习像 UITableViewDelegate, UIScrollViewDelegate, NSCoding 和 NSCopying 这样的协议。例子,NSCopying 的协议 (protocol),任何类都可以提供这样一个标准的复制方法。
我们提到的滚动区域是这样的:
现在开始,在项目导航的 View 文件夹上右击鼠标,选择 New File…,用 iOS\\Cocoa Touch\\Object-C class 模板创建一个新类。新类的名字叫 HorizontalScroller,选择它的子类为 UIView。
打开 HorizontalScroller.h 文件在 @end 后面插入如下代码:
定义个代理执行的方法,要在 @protocol 和 @end 之间,它们分为必要方法和可选方法。添加下面协议方法:
// 返回索引是 index 的视图
- (UIView*)horizontalScroller:(HorizontalScroller*)scroller viewAtIndex:(int)index;
// 当索引是 index 的视图被点击了,通知 delegate
- (void)horizontalScroller:(HorizontalScroller*)scroller clickedViewAtIndex:(int)index;
@optional
// 通知 delegate,显示初始化时索引是 Index 的视图。这个方法是可选的
// ask the delegate for the index of the initial view to display. this method is optional
// 如果没有被 delegate 执行,默认值是 0
- (NSInteger)initialViewIndexForHorizontalScroller:(HorizontalScroller*)scroller;
本文地址:https://www.stayed.cn/item/11624
转载请注明出处。
本站部分内容来源于网络,如侵犯到您的权益,请 联系我