OC思考 | 为私有方法加前缀，真的有必要吗？

《Effective OC》第20条：为私有方法加前缀。

作者建议为私有方法加上前缀，理由有二：

1. 有助于调试，由于可以快速区分私有方法和公有方法；
2. 便于修改方法名。

第一点显而易见就不多说了。
第二点，公有方法因为别人要用，所以不能随意改（比如说假如masonry的接口频繁改动使用者一定受不了）；私有方法影响不到别人，可以随意改。你给私有方法加上前缀，就能快速区分哪些是公有方法哪些是私有方法，你也就因而知道了哪些方法可以改哪些不能改。

唉，我感觉这第二点就是第一点的扩展。

《Effective OC》在iOS开发者中无须置疑是一本非常权威的书了，看到这一条，你能否立即给私有方法加上前缀以提升自己代码的逼格呢？

至于我，尽管经常为了装逼之事而绞尽脑汁，但这个时候还是停下来思考了一番。

加前缀是为了更好的区分公有方法和私有方法。但问题是，日常开发中，很多时候，并没有那么多公有方法。比方一个controller，里面有十几个私有方法，但公有方法或者许只有一个构造方法，如：

- (instancetype)initWithGoodsID:(NSString *)goodsID;

甚至有时候都没有自己设置构造方法，只有一个生命周期方法viewDidLoad:。

这个时候，区分公有和私有的意义何在？

所有私有方法前面都加一个p_真的显得很多余，更关键的是，这反而降低了可读性。想象一下你去看你同事写的controller，方法列表一开展，呈现在眼前的一连串方法全是p_开头的，此时，你会不会情不自禁的说一句：“卧槽”？

萌新可能会觉得这种操作很规范很有逼格，但是肯定要把握好这个度，不要学到个知识就赶紧强行运用。

我一般只会在封装比较通用的库时才给私有方法加前缀，比方说我封装了一个toast（地址： CaiWanFeng/AlertToastHUD，强行推广一波哈哈哈），公有方法不少：

.h文件

这个时候，给私有方法加上前缀就真的是注重细节的表现了：

.m文件

就拿show toast那一堆方法来说，只有一个私有方法：

+ (void)p_showWithMessage:(NSString *)message image:(NSString *)imageName duration:(NSTimeInterval)duration style:(CQToastStyle)style;

这是一个全能show方法（关于全能方法可以查阅这本书的第16条），其它所有show方法都会调用它。

如果有一天我把这个库上传到CocoaPods，在升级这个库的时候，我能修改的就只有这个没有暴露出去的方法。即便我很长一段时间没有过问这个库，当初自己写的代码已经忘得差不多了，有一天忽然想起了它，并且想给它增加一个功能，当我再次阅读代码的时候，这个p_前缀，可以很好的提醒我只有这个是私有方法，其余方法你不能改，改了会影响到使用这个库的人。

这就是给私有方法加前缀的现实意义。

因而我觉得：“私有方法加前缀，便于修改方法名。”这一点更多的是说给准备封装组件、框架的开发者的。

私有方法加不加前缀得视情况而定，最终的衡量标准仍旧是代码的可读性，尽管影响不大，但你不得不承认这就是细节的表现。

逼格来自细节，强行装逼往往适得其反，只有无形装逼才能深入人心。

已是最前 目录 下一篇