初始化中的隐式解包选项 - Swift

Tay*_*day 2 design-patterns optional ios swift

在编写一个新的swift类时,在使用隐式解包的选项而不是普通的选项时,我仍然不会100%感到舒服.据我所知,如果您从未期望它的值为零,那么分配一些隐式展开(和可选)的东西应该没问题.如果它是nil,则它是一个异常事件,应该导致运行时错误.

例如,这个简单的登录视图包含两个文本域成员变量:

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);
}
}
Run Code Online (Sandbox Code Playgroud)

在上面的类中,emailField和passField都被归类为隐式解包的选项,因为我从不期望它们在超级视图的整个生命周期中都是零.我不将它们指定为常量,因为我希望它们的初始化依赖于superview的状态(frame/bounds/etc).我遗漏了额外的代码来保持这个例子的清洁.

是否使用隐式解包的选项对初始化成员进行了正确有效的使用?

Ant*_*nio 5

除非有充分的理由使用它们,否则我会远离隐式解包的选项.如果可能,请使用非可选项,否则使用其他选项.如果使用不当,隐式展开会非常危险,因为它们会绕过编译器检查并生成运行时异常.

非详尽列表的情况何时使用隐式展开:

  • 当有一个API返回隐式解包时
  • 解决类实例之间强引用循环问题
  • 当你有一个类/结构属性(按设计)永远不会是nil,但它不能在初始化器中设置

后一种用法的典型情况是在a中UIViewController,当在viewDidLoad方法中而不是在初始化器中初始化属性时- 使用隐式展开是有意义的.

在这种情况下不要使用隐式解包:

  • 因为它很酷
  • 因为它可以让您在键盘上保存按键
  • 当你不是100%确定是否使用它

在您的特定情况下,虽然属性在初始化器中实例化,但它们依赖于超类初始化,因此将它们声明为隐式解包是有意义的.