最近拜读了<Objc Zen Book>这本书:
英文原版地址
中文翻译版
里面讲的东西比较杂, 算是Objc的编程技巧, 只是一些在写Objc代码时需要注意的点, 包括代码风格, 命名规范, API设计和类设计等等. 这里只是列出了我个人认为对我很有帮助的点, 写Objc代码的同学都值得去看看. 当然, 我们并不需要全盘接受作者的观点, 因此即使遇到不赞同的点, 跳过即可, 不必太过在意.
不过说实话这本书写的方式不是特别友好, 因为用了很多比较艰涩的词语, 如果英语不够好就需要不断查单词, 并不像一些很有名的计算机技术书籍, 都是用的比较常见的词汇, 英语不好让各位贱笑了.
可变对象:
任何可变对象的属性, 其内存管理必须是copy的, 这样可以确保其封装性, 避免在对象不知情的时候改变值.
同同时, 应该避免暴露在公开接口中的可变对象, 一旦如此, 就表示允许类的使用者任意改变类的内部,
这样会破坏封装性. 可以提供只读属性来返回对象的不可变副本:
<code>
/* .h */
@property (nonatomic, readonly) NSArray *elements
/* .m */
- (NSArray *)elements {
return [self.mutableElements copy];
}
</code>
懒加载:
一般我们会在初始化方法中, 把成员变量都初始化出来, 但是有些成员变量比较耗资源, 如:NSDateFormatter, 而且不一定什么时候才会用到,
因此可以使用懒加载策略: 重写getter方法:
<code>
- (NSDateFormatter *)dateFormatter{
if (!_dateFormateer)
{
// 初始化变量
}
}
</code>
但是这种做法存在争议, 需要仔细考虑是否要lazy loading
关于接口:
如果要设计一个RSS订阅的功能, 最差的情况是所有的逻辑和UI都写在一起, 成为了MVC(Massive Viewcontroller)
稍微好点的设计是数据获取和UI展示分离, 如:
<code>
// 数据解析器
@interface ZOCFeedParser : NSObject
@property (nonatomic, weak) id <ZOCFeedParserDelegate> delegate;
@property (nonatomic, strong) NSURL *url;
- (id)initWithURL:(NSURL *)url;
- (BOOL)start;
- (void)stop;
@end
// UI展示
@interface ZOCTableViewController : UITableViewController
- (instancetype)initWithFeedParser:(ZOCFeedParser *)feedParser;
@end
// 使用protocol来回调给UI 数据分析的情况
@protocol ZOCFeedParserDelegate <NSObject>
@optional
- (void)feedParserDidStart:(ZOCFeedParser *)parser;
- (void)feedParser:(ZOCFeedParser *)parser didParseFeedInfo:(ZOCFeedInfoDTO *)info;
- (void)feedParser:(ZOCFeedParser *)parser didParseFeedItem:(ZOCFeedItemDTO *)item;
- (void)feedParserDidFinish:(ZOCFeedParser *)parser;
- (void)feedParser:(ZOCFeedParser *)parser didFailWithError:(NSError *)error;
@end
</code>
以上实现有个问题是代码的复用性还不是很好, 目前这个Parser可能解析的是网络数据,
假如现在需要从本地数据源解析, 则没有多少代码可以复用, ViewController的代码也要修改,
因此可以改进为面向protocol:
<code>
// 分析器的protocol
@protocol ZOCFeedParserProtocol <NSObject>
@property (nonatomic, weak) id <ZOCFeedParserDelegate> delegate;
@property (nonatomic, strong) NSURL *url;
- (BOOL)start;
- (void)stop;
@end
// 分析器回调的protocol
@protocol ZOCFeedParserDelegate <NSObject>
@optional
- (void)feedParserDidStart:(id<ZOCFeedParserProtocol>)parser;
- (void)feedParser:(id<ZOCFeedParserProtocol>)parser didParseFeedInfo:(ZOCFeedInfoDTO *)info;
- (void)feedParser:(id<ZOCFeedParserProtocol>)parser didParseFeedItem:(ZOCFeedItemDTO *)item;
- (void)feedParserDidFinish:(id<ZOCFeedParserProtocol>)parser;
- (void)feedParser:(id<ZOCFeedParserProtocol>)parser didFailWithError:(NSError *)error;
@end
</code>
如此一来, 即使更换了parser的实现, UI上面不用做任何修改
利用代码块:
代码块如果在闭合的圆括号内的话, 会返回最后语句的值:
<code>
NSURL *url = ({
NSString *urlString = [NSString stringWithFormat:@"%@/%@", baseURLString, endpoint];
[NSURL URLWithString:urlString];
});
</code>
这个特性可以使变量的作用域只在代码块中, 从而减少对其它作用域的污染, 从而缓解编程的世界性难题之一--变量命名
pragma 消除警告
#pragma clang diagnostic push // 准备压入一个警告消除标记
#pragma clang diagnostic ignored "-Warc-performSelector-leaks" // 警告消除标记
[myObj performSelector:mySelector withObject:name]; // 需要消除警告的代码
#pragma clang diagnostic pop // 弹出这个警告消除标记, 以免在别的地方也不警告了
除此之外 还有:
#pragma clang diagnostic ignored "-Wdeprecated-declarations" // 方法弃用警告
#pragma clang diagnostic ignored "-Wincompatible-pointer-types" // 不兼容指针警告
#pragma clang diagnostic ignored "-Wunused-function" // 没有使用的函数
一般命名规则是 "-W警告提示名"
如果一个变量未使用, 但是你有别的意图, 想要消除警告可以:
#pragma unused (variable)
Block
定义包含有block的接口时, 提供一个单独的block比分别提供成功和失败block要好些, 因为很多情况下成功和失败都需要执行一部分代码.
成功的数据对象和失败的错误对象都在参数中, 因此必须保证:
数据对象和失败对象其中之一为非空, 另一则为空.
在检查时, 我们一般会检查数据对象是否为空, 一来我们更关心数据, 二来, 苹果提供的一些同步接口在成功的情况下也会像NSError中写入一些垃圾值.Block作为属性要使用copy的内存管理方式, 确保在栈帧返回时block不会被释放掉而得不到执行(关于这点, 我做了很多次试验, 表明strong其实在各种情况下与copy的行为并无二致, 没有出现普遍认为的会被释放掉的说法, 但是还是推荐大家用copy, 可能在一些比较极端的点会出现问题, 而我并没有试验到)
weakself 和 strongself的选择:
a. 如果实例持有了这个block, 但是这个block又要使用self的方法, 则需要对self进行weak, 否则会造成循环引用
b. 如果需要保证block中self的方法一定要执行, 不允许block执行前实被释放, 则需要对weakself进行strong (我认为这里其实是暂时性造成了循环引用, 因为在一段时间内互相持有了, 这也是这么写的目的, 但是strongself是个局部变量, 在block执行完毕后会释放, 就自动打破了这个循环, 因此不会泄露. 不知道这么理解对不对, 因为Apple官方示例都是直接一个XXX *x = weakself;来持有, 但是这种做法在这本书中遭到了反对)
