是否有任何理由在Swift中使用选择器？

具体来说，当一个任务可以用选择器或不用选择器补充时，是否有任何（客观）理由偏好一种方式而不是另一种方式？是否有任何理由在Swift中使用选择器？

A）使用选择：

let timer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(timerAction()), userInfo: nil, repeats: true) 

dynamic func timerAction() { 
    print("foo")  
}

B）没有选择器：

例如，一个NSTimer可以以两种方式运行上的间隔的方法

let timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in 
    self.timerAction() 
} 

func timerAction() { 
    print("foo") 
}

两个版本是完全有效的，那么是否有任何（客观）理由相互偏好？

来源

2017-05-26 Brandon Bradley

块版本是一个iOS10 +方法只适用于您的情况。如果您的目标是iOS9，则无法使用它。 – Larme

@Larme有趣。两者都在macOS 10.12上工作，但我不能早些讲话。 –

@BrandonBradley只需查看文档。在MacOS 10.12和iOS 10.0中添加了块版本的Timer.scheduledTimer。 – rmaddy

目标/选择器设计是早期的Objective-C在API前一天封闭的行李。

如果苹果今天要重做所有这些API，那么整个目标/选择器设计将消失，并全部用块/闭包代替。更新的Apple API支持此想法。示例 - 旧的UIAlertView使用了一个委托。较新的UIAlertController仅使用闭合/块来执行警报操作。

使用闭包（Swift）或块（Objective-C）比使用目标/选择器方法更受欢迎。

这里有问题，使用目标/选择：

可怕的 “无法识别选择” 错误。
需要为选择器创建额外的顶级方法。
在选择器方法中指定错误参数和数据类型的可能性。
在设置需要目标/选择器的对象时，丢失所有当前上下文。

与所有这些相反的是使用闭包/块表单的好处。

可能的是，随着时间的推移，很多代理版本的API将被弃用，并被闭包/块版本所取代。如果你有选择，我建议现在使用闭包/块表单以避免稍后更新，更不用说它只是更简单的解决方案。

来源

2017-05-26 23:27:52 rmaddy

是否有任何理由在Swift中使用选择器？

回答

相关问题