前面已经提到过,接收回应包的模式采用的是观察者,在iOS下面,我们可以直接使用NSNotificationCenter(NNC),NNC简化了观察者,将观察对象与一个全局唯一的字符串绑定在一起,比如我定义登录,获取信息,登出三个回应包对应的字符串
而工厂模式的工厂基类需要满足按照不同的回应包类型生成不同的特定工厂,而各个工厂将生成不同的回应包(重载基类的方法),定义如下:
其中的buildXXX分别解析不同类型的字段,在解析前会检查待解析数据流的长度,成功解析后数据流的指针(迭代器)向后移动相应的长度,解析失败将返回nil,各个子类生成器重载build方法生成各自的Response 现在再回到前面的发送回应包的地方,此时回应包已经生成,简单的执行如下代码即可:
extern NSString *const LoginCommandNotification;
extern NSString *const QueryInfoCommandNotification;
extern NSString *const LogoutCommandNotification;
在发送特定的回应包给NNC之前还需要按照返回的包类型创建一个对象,这里使用工厂模式是比较自然的选择,原因是随着程序的开发,其回应包的类型肯定会不断的修改和增加,为了不影响客户端的代码,需要将返回包抽象,由工厂模式负责生产具体返回包
这里的返回包只需要满足可以发送给NNC就可以了,即满足拥有一个全局唯一的字符串,于是返回包的抽象类定义如下:
@interface Response:NSObject
@property (noatomic, copy, readonly) NSString *notificationID;
@end而工厂模式的工厂基类需要满足按照不同的回应包类型生成不同的特定工厂,而各个工厂将生成不同的回应包(重载基类的方法),定义如下:
@interface ResponseCreator
// 生成特定的工厂对象
+(ResponseCreator*)responseCreatorWithType:(int)type;
// 需要子类重载的方法
-(Response*)responseWithData:(Byte*)data withLength:(unsigned)len;
@end
-(Response*)responseWithData:(Byte*)data withLength:(unsigned)len;在ResponseCreator中保持着与其所有子类的联系,比如在responseCreatorWithType:的实现中有个switch-case语句,选择合适的工厂类,也可以使用类工厂的方式,从ResponseCreator中根据type直接返回Response的实例,但这样的话,其switch-case语句过于复杂,按照前面的方式可以将生成response的具体过程放到具体工厂中去实现,使得代码容易理解和维护,考虑到Response的构建过程需要解析数据流,各个特定的Response其解析的过程可以重用,我们使用生成器(Builder
Pattern)来生成Response,Builder的父类如下:@interface ResponseBuilder:NSObject
@property (nonatomic, retain, readonly) Response *response;
-(id)initWithData:(Byte*)data length:(unsigned)len;
-(int)build;
-(ResponseBuilder*)buildByte;
-(ResponseBuilder*)buildShort;
-(ResponseBuilder*)buildUnsigned;
-(ResponseBuilder*)buildString;
@end其中的buildXXX分别解析不同类型的字段,在解析前会检查待解析数据流的长度,成功解析后数据流的指针(迭代器)向后移动相应的长度,解析失败将返回nil,各个子类生成器重载build方法生成各自的Response 现在再回到前面的发送回应包的地方,此时回应包已经生成,简单的执行如下代码即可:
[[NSNotificationCenter defaultCenter] postNotificationName:response.notificationID
object:response];
447

被折叠的 条评论
为什么被折叠?



