第28条:通过协议提供匿名对象
本条要点:(作者总结)
- 协议可在某种程度上提供匿名类型。具体的对象类型可以淡化成尊从某协议的 id 类型,协议里规定了对象所应实现的的方法。
- 使用匿名对象来隐藏类型名称(或类名)。
- 如果具体类型不重要,重要的是对象能够响应 (定义在协议里的)特定方法,那么可使用匿名对象来表示。
协议定义了一系列方法,遵从此协议的对象应该实现它们(如果这些方法不是可选的,那么就必须实现)。于是,我们可以用协议把自己所写的 API 之中的实现细节隐藏起来,将返回的对象设计为遵从此协议的纯 id 类型。这样的话,想要隐藏的类名就不会出现在 API 之中了。若是接口背后有多少不同的实现类,而你又不想指明具体使用哪个类,那么可以考虑用这个办法-因为有时候这个些类可能会变,有时候它们无法容纳于标准的类继承体系中,因而不能以某个公共基类来统一表示。
此概念经常称为 “匿名对象”(anonymous object),这与其他语言的 “匿名对象” 不同,在那些语言中,该词是指以内联形式所创建出来的无名类(这个概念在某些语言中也叫“匿名类”(anonymous class)),而此词在 Objective-C 中则不是这个意思。第 23 条解释了委托与数据源对象,其中就曾用到这种匿名对象。例如,在定义 “受委托”(delegate) 这个属性时,可以这样写:
@property (nonatomic, weak) id<EOCDelegate> delegate;
由于该属性的类型是 id<EOCDelegate>,所以实际上任何的对象都能充当这一属性,即便该类不继承自 NSObject 也可以,只要遵循 EOCDelegate 协议就行。对于具备此属性的类来说,delegate 就是 “匿名的”(anonymous)。如有需要,可以在运行期查出此对象所属的类型。然而这样做不太好,因为指定属性类型时所写的那个 EOCDelegate 契约已经表明此对象的具体类型无关紧要了。
NSDictionary 也能实际说明这一概念。在字典中,键的标准内存管理语义是 “设置时拷贝”,而值的语义则是 “设置时保留”。因此,在可变版本的字典中,设置键值对所用的方法的签名是:
- (void)setObject:(id)object forKey:(id<NSCopying>)key;
表示键的那个参数其类型为 id<NSCopying>,作为参数值的对象,它可以是任何类型,只要遵从 NSCopying 协议就好,这样的话,就能向该对象发送拷贝消息了。
这个 key 参数可以视为匿名对象,与 delegate 属性一样,字典也不关心 key 对象所属的具体类,而且它也决不应该依赖于此。字典对象只要能确定它可以给此实例发送拷贝消息就行了。
处理数据库连接(database connection)的程序也用这个思路,以匿名对象来表示从另一个库中所返回的对象。对于处理连接所用的那个类,你也许不想叫外人知道其名字,因为不同的数据库可能要用不同的类来处理。如果没有办法令其继承自同一基类,那么就得返回 id 类型的东西了。不过我们可以把所有数据库连接都具备的那些方法放到协议中,令返回的对象遵从此协议。协议可以这样写:
@protocol EOCDatabaseConnection
- (void)connect;
- (void)disconnect;
- (BOOL)isConnected;
- (NSArray *)performQuery:(NSString *)query;
@end
然后,就可以用 “数据库处理器”(database handler)单例来提供数据库连接了。这个单例的接口可以写成:
#import <Foundation/Foundation.h>
@protocol EOCDatabaseConnection;
@interface EOCDatabaseManager : NSObject
+ (id)sharedInstance;
- (id<EOCDatabaseConnection>)connectionWithIdentifier:(NSString *)identifier;
@end
这样的话,处理数据库连接所用的类名就不会泄漏了,有可能来自不同框架的那些类现在均可以经由一个方法来返回了。使用此 API 的人仅仅要求所返回的对象能用来连接、断开并查询数据库即可。这一点很重要。本例中,处理数据库连接所用的后端代码可能使用了各种第三方库来连接不同类型的数据库(例如 MySQL、PostgreSQL 等)。由于这些类都在多个第三方库里,所以也许没办法令所有的连接类都继承自同一基类。因此,可以创建匿名对象这些第三方类简单包裹一下,使匿名对象成为其子类,并遵从 EOCDatabaseConnection 协议。然后,用 “connectionWithIdentifier:” 方法来返回这些类对象。在开发后续版本时,无须改变公共 API,即可切换后端的实现了。
有时对象类型并不重要,重要的是对象没有实现这些方法,在此情况下,也可以用这些 “匿名类型”(anonymous type )
来表达这一概念。即便实现代码总是使用固定的类,你可能还是会把它写成遵从某协议的匿名类型,以表示类型在此处并不重要。
CoreData 框架里也有这种用法。查询 CoreData 数据库所得的结果由名叫 NSFetchedResultsController 的类来处理,如有需要,处理时还会把数据分区。在负责处理查询结果的控制器中,有个 sections 属性,用以表示数据分区。此属性是个数组,但其中的对象却没有指明具体类型,只是说这些对象都遵从了 NSFetchedResultsSectionInfo 协议。下面这段代码通过控制器来获取数据分区信息:
1 NSFetchedResultsController *controller = /* some controller */; 2 NSUInteger section = /* section index to query*/; 3 4 NSArray *sections = controller.sections; 5 id<NSFetchedResultsSectionInfo> sectionInfo = sections[section]; 6 NSUInteger numberOfObjects = sectionInfo.numberOfObjects;
sectionInfo 是个匿名对象。设计此种 API 时,要把 “通过对象能够访问数据分区信息” 这一功能于接口中清晰地表达出来。在幕后,此对象可能是由处理结果的控制器所创建的内部状态对象(internal state object)。没必要把表示此种数据的类对外公布,因为使用控制器的人绝对不用关心查询结果中的数据分区是如何保存的,他们只需要知道可以在这些对象上查询数据就行了。我们可以把 section 数组中返回的内部状态对象视为遵从 NSFetchedResultsSectionInfo 协议的匿名对象。使用者只要明白这种对象实现了某些特定的方法即可,其余实现细节都隐藏起来了。
END