当编写一个新的 swift 类时,当(不)使用隐式展开的选项而不是简单的选项时,我仍然不是 100% 舒服。据我所知,如果您从未期望它的值为零,则将某些内容分配为隐式解包(并且可选)应该可以。如果它为零,则这是一个异常事件,应该会导致运行时错误。
以这个包含两个文本字段成员变量的简单登录视图为例:
class SignInFieldView : UIView {
var emailField: UITextField!;
var passField: UITextField!;
required init(coder aDecoder: NSCoder) {
super.init(coder: aDecoder);
commonInit();
}
convenience override init(frame: CGRect) {
self.init(frame: frame);
commonInit();
}
func commonInit() {
layoutEmail();
layoutPass();
}
// MARK: Layout Text Fields
func layoutEmail() {
let rect = CGRect(x: bounds.origin.x, y: bounds.origin.y, width: bounds.size.width, height: (bounds.size.height * 0.5));
emailField = UITextField(frame: rect);
addSubview(emailField);
}
func layoutPass() {
let rect = CGRect(x: bounds.origin.x, y: bounds.origin.y + (bounds.size.height * 0.5), width: bounds.size.width, height: (bounds.size.height * 0.5));
passField = UITextField(frame: rect);
addSubview(passField);
}
}
在上面的类中,emailField 和 passField 都被归类为隐式展开的选项,因为我从不期望它们在其超级视图的整个生命周期中为零。我不将它们分配为常量,因为我希望它们的初始化取决于超级视图的状态(框架/边界/等)。我省略了额外的代码以保持这个示例的简洁。
对初始化成员使用隐式解包选项是否正确且有效?
我会远离隐式展开的选项unless使用它们是有充分理由的。如果可能,使用非可选,否则使用可选。如果使用不当,隐式解包将非常危险,因为它们会绕过编译器检查并生成运行时异常。
何时使用隐式展开的情况的非详尽列表:
- 当有一个 API 返回隐式解包的
- 来解决类实例之间的强引用循环 problem
- 当你有一个类/结构属性(根据设计)永远不会为零,但它不能在初始化程序中设置
后一种用法的典型案例是UIViewController
,当一个属性在viewDidLoad
方法而不是在初始化程序中 - 使用隐式解包是有意义的。
在这种情况下,不要使用隐式解包:
- 因为这很酷
- 因为它可以让您保存键盘上的按键操作
- 当你不能100%确定是否使用它时
在您的具体情况下,虽然属性是在初始化器中实例化的,但它们依赖于超类初始化,因此将它们声明为隐式解包是有意义的。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)