作者:Soroush Khanlou,原文链接,原文日期:2016-09-27
译者:saitjr;校对:CMB;定稿:CMB
可以说 Swift 是 Objective-C 的后继之人,毕竟也算是师出同门。但是他们语法看来不像,用起来也不像,给人的感觉也不一样。有些在 Objective-C 上用得好端端的案例,在 Swift 上却看起来怪怪的,如方法命名。在 Objective-C 中,方法名尽量完整:
objective-c
[string dataUsingEncoding:NSUTF8StringEncoding];
在 Swift 2.2 中,这样调用看着就没那么优雅:
string.dataUsingEncoding(NSUTF8StringEncoding)
在 Swift 3 中,这个方法看起来就顺眼多了:
string.data(using: .utf8)
所以,像 Swift 3 中这样的命名方式,才是 Swift 的正确姿势。而 Objective-C 的方式也只适用于 Objective-C。我觉得这篇文章应该能帮你在新世界中修炼你的方法命名习惯。
无论是三方框架,还是平时开发中编写的代码,都应该更新为更为 Swift 的方式。下面,我将着重说一下代理的命名。
Swift 中代理的理解和 Objective-C 并不完全相同。Objective-C 偏向于 “发送者” 与 “接收者”。Apple 的 Objective-C 文档也倾向于这种方式。比如 UIResponder
的 isFirstResponder
方法,文档上是这样解释的:
Returns a Boolean value indicating whether the receiver is the first responder.
返回一个接收者是否是第一响应者的标识(布尔值)。
所以,在设置 target-action 的时候,参数名理所当然的称为 sender
:
objective-c
- (void)buttonTapped:(UIButton *)sender {
代理方法的定义规则和这个类似:在 Objective-C 中,代理方法的第一个参数总是发送者。让我们来看看为什么会这样:如果你(接收者,即实现代理方法的对象)是多个相同类型对象的代理,那么你需要这个参数来进行区分。所以代理方法提供了第一个参数,方便分别处理。(译注:例如多个 UITextField
的 delegate
都是 self
的时候,就需要进行区分是哪个 UITextField
调用的代理方法)。
下面我会用到 Backchannel SDK 中的例子,为了简单起见,我简化了一些类名。
这个 SDK 中代理方法分为两大类。第一类是事件触发的代理:
objective-c
- (void)messageFormDidTapCancel:(BAKMessageForm *)messageForm;
在 Swift 中,翻译为:
func messageFormDidTapCancel(_ messageForm: BAKMessageForm)
这要放在 Swift 3 中就不那么顺眼了。在 Swift 3 中,应该去调冗余部分(messageFrom
重复了),并且第一个参数应该有别名,而不应该用下划线代替。
第二类是事件触发,并且还带有部分数据的代理方法。对于这类,我举了以下两个例子:
objective-c
- (void)messageForm:(BAKMessageForm *)messageForm didTapPostWithDraft:(BAKDraft *)draft;
- (void)messageForm:(BAKMessageForm *)messageForm didTapAttachment:(BAKAttachment *)attachment;
在 Swift 中,翻译为:
func messageForm(_ messageForm: BAKMessageForm, didTapPostWithDraft draft: BAKDraft)
func messageForm(_ messageForm: BAKMessageForm, didTapAttachment attachment: BAKAttachment)
简直辣眼睛。为啥两个方法都叫 messageFrom
?并且这个方法开头的名词也不合常理:一般建议名词是方法返回的对象类型(比如 NSString
的 data(using:)
,就是返回的 Data
)。但是这个例子中,却并不需要返回任何 “message form”。这里指的 “message form”其实应该是第一个参数的名字,真是个令人纠结的方法名。
其实这两种类型的代理方法,都可以通过将“sender”移到行末,把动词提到最前来解决命名的问题。对于第一个例子来说,是 sender 想告诉代理点击取消事件(didTapCancel
),而不是 messageFormDidTapCancel
,所以应该改为:
func didTapCancel(messageForm: BAKMessageForm)
这样看起来好多了。事件的名称被提在了最前作为方法名,能很直观的看出方法的作用。我觉得,最好再将介词作为参数别名,这样调用的时候就更优雅了:
func didTapCancel(on messageForm: BAKMessageForm)
目前我还没找到关于介词的使用规范。不过我会在不同情况下,选择使用“on”,“for”,“with”,“in”。用户是点击在表单“上”的,所以我觉得这里用“on”比较合适。
接下来再来看看,代理方法有数据返回的情况。将动词提到最前,选择合适的介词就能有效解决这个问题了。
之前是:
func messageForm(_ messageForm: BAKMessageForm, didTapPostWithDraft draft: BAKDraft)
而更 Swift 化的是:
func didTapPost(with draft: BAKDraft, on messageForm: BAKMessageForm)
和
func didTap(attachment: BAKAttachment, on messageForm: BAKMessageForm)
这种命名规则只是我归纳出来的,并没有经过他人印证,但我觉得这要比现在代理方法命名的规则要好得多。之后,我可能还会自己的 Swift 代理方法中使用这种规则。
下面列举了 UITableView
的 delegate 与 data source 方法,以及这些方法在未来可能的样子:
func numberOfSections(in tableView: UITableView) -> Int
numberOfSections
遵循了前文提到的规则,看起来很优雅。
但其余的方法看起来就不那么好了:
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)
更为漂亮的命名是:
func numberOfRows(inSection section: Int, in tableView: UITableView) -> Int
func cellForRow(at indexPath: IndexPath, in tableView: UITableView) -> UITableViewCell
func didSelectRow(at indexPath: IndexPath, in tableView: UITableView)
本文由 SwiftGG 翻译组翻译,已经获得作者翻译授权,最新文章请访问 http://swift.gg。
网友评论