Antes de que pueda describir los casos de uso de los opcionales implícitamente sin envolver, ya debe comprender qué son los opcionales y los opcionales implícitamente sin envolver en Swift. Si no lo hace, le recomiendo que primero lea mi artículo sobre opciones
Cuándo usar una opción opcional sin envolver implícitamente
Hay dos razones principales por las que uno crearía un Opcional implícitamente sin envolver. Todo tiene que ver con la definición de una variable a la que nunca se accederá nilporque, de lo contrario, el compilador Swift siempre lo obligará a desenvolver explícitamente un Opcional.
1. Una constante que no se puede definir durante la inicialización
Cada constante de miembro debe tener un valor para cuando se complete la inicialización. A veces, una constante no se puede inicializar con su valor correcto durante la inicialización, pero aún se puede garantizar que tenga un valor antes de acceder.
El uso de una variable Opcional soluciona este problema porque un Opcional se inicializa automáticamente nily el valor que eventualmente contendrá seguirá siendo inmutable. Sin embargo, puede ser una molestia desenvolver constantemente una variable que usted sabe con certeza que no es nula. Los opcionales sin envoltura implícitamente logran los mismos beneficios que un opcional con el beneficio adicional de que uno no tiene que desenvolverlo explícitamente en todas partes.
Un gran ejemplo de esto es cuando una variable miembro no se puede inicializar en una subclase de UIView hasta que se carga la vista:
class MyView: UIView {
@IBOutlet var button: UIButton!
var buttonOriginalWidth: CGFloat!
override func awakeFromNib() {
self.buttonOriginalWidth = self.button.frame.size.width
}
}
Aquí, no puede calcular el ancho original del botón hasta que se cargue la vista, pero sabe que awakeFromNib se llamará antes que cualquier otro método en la vista (que no sea la inicialización). En lugar de forzar que el valor se desenvuelva explícitamente sin sentido en toda su clase, puede declararlo como Opcionalmente sin envolver opcional.
2. Cuando su aplicación no puede recuperarse de un ser variable nil
Esto debería ser extremadamente raro, pero si su aplicación no puede continuar ejecutándose si se nilaccede a una variable , sería una pérdida de tiempo molestarse en probarla nil. Normalmente, si tiene una condición que debe ser absolutamente cierta para que su aplicación continúe ejecutándose, usaría un assert. Un Opcional implícitamente sin envolver tiene una aserción para nil integrada directamente en él. Incluso entonces, a menudo es bueno desenvolver lo opcional y usar una afirmación más descriptiva si es nula.
Cuándo no utilizar un opcional implícitamente desenvuelto
1. Variables de miembro calculadas perezosamente
A veces tiene una variable miembro que nunca debe ser nula, pero no se puede establecer en el valor correcto durante la inicialización. Una solución es usar un Opcional implícitamente sin envolver, pero una mejor manera es usar una variable perezosa:
class FileSystemItem {
}
class Directory : FileSystemItem {
lazy var contents : [FileSystemItem] = {
var loadedContents = [FileSystemItem]()
// load contents and append to loadedContents
return loadedContents
}()
}
Ahora, la variable miembro contentsno se inicializa hasta la primera vez que se accede a ella. Esto le da a la clase la oportunidad de llegar al estado correcto antes de calcular el valor inicial.
Nota: Esto puede parecer contradecir el n. ° 1 desde arriba. Sin embargo, hay una distinción importante que hacer. Lo buttonOriginalWidthanterior debe establecerse durante viewDidLoad para evitar que alguien cambie el ancho de los botones antes de acceder a la propiedad.
2. En todas partes
En su mayor parte, se deben evitar las opciones implícitas sin envolver porque si se usa por error, toda la aplicación se bloqueará cuando se acceda a ella nil. Si alguna vez no está seguro de si una variable puede ser nula, use siempre un Opcional normal de forma predeterminada. Desenvolver una variable que nunca es segura no nilhace mucho daño.
if someOptional.