Antes que eu possa descrever os casos de uso dos Opcionais Implicitamente Desembrulhados, você já deve entender o que são os Opcionais e os Opcionais Implicitamente Desembrulhados no Swift. Caso contrário, recomendo que você leia primeiro meu artigo sobre opcionais
Quando usar um opcional não implicitamente desembrulhado
Há duas razões principais para criar um Opcional Implicitamente Desembrulhado. Tudo tem a ver com a definição de uma variável que nunca será acessada quando nil, caso contrário, o compilador Swift sempre o forçará a desembrulhar explicitamente um opcional.
1. Uma constante que não pode ser definida durante a inicialização
Cada constante de membro deve ter um valor no momento em que a inicialização é concluída. Às vezes, uma constante não pode ser inicializada com seu valor correto durante a inicialização, mas ainda é possível garantir um valor antes de ser acessada.
O uso de uma variável Opcional contorna esse problema porque um Opcional é inicializado automaticamente nile o valor que eventualmente conterá ainda será imutável. No entanto, pode ser uma tarefa difícil desembrulhar constantemente uma variável que você sabe com certeza não é nula. Opcionais implicitamente desembrulhados alcançam os mesmos benefícios que um opcional com o benefício adicional de que não é necessário desembrulhá-lo explicitamente em todos os lugares.
Um ótimo exemplo disso é quando uma variável de membro não pode ser inicializada em uma subclasse UIView até que a visualização seja carregada:
class MyView: UIView {
@IBOutlet var button: UIButton!
var buttonOriginalWidth: CGFloat!
override func awakeFromNib() {
self.buttonOriginalWidth = self.button.frame.size.width
}
}
Aqui, você não pode calcular a largura original do botão até que a exibição seja carregada, mas você sabe que awakeFromNibisso será chamado antes de qualquer outro método na exibição (que não seja a inicialização). Em vez de forçar o valor a ser explicitamente desembrulhado sem sentido em toda a sua classe, você pode declará-lo como um Opcional Implicitamente Desembrulhado.
2. Quando seu aplicativo não pode se recuperar de um ser variável nil
Isso deve ser extremamente raro, mas se o aplicativo não puder continuar em execução se uma variável for nilacessada, seria um desperdício de tempo se preocupar em testá-lo nil. Normalmente, se você tem uma condição que deve ser absolutamente verdadeira para que seu aplicativo continue em execução, use um assert. Um opcional não implicitamente desembrulhado possui uma afirmação de nada embutida nele. Mesmo assim, geralmente é bom desembrulhar o opcional e usar uma afirmação mais descritiva, se for nulo.
Quando não usar um opcional implicitamente desembrulhado
1. Variáveis de membro calculadas preguiçosamente
Às vezes, você tem uma variável de membro que nunca deve ser nula, mas não pode ser definida com o valor correto durante a inicialização. Uma solução é usar um opcional implicitamente desembrulhado, mas a melhor maneira é usar uma variável lenta:
class FileSystemItem {
}
class Directory : FileSystemItem {
lazy var contents : [FileSystemItem] = {
var loadedContents = [FileSystemItem]()
// load contents and append to loadedContents
return loadedContents
}()
}
Agora, a variável de membro contentsnão é inicializada até a primeira vez que é acessada. Isso dá à classe a chance de entrar no estado correto antes de calcular o valor inicial.
Nota: Isso pode parecer contradizer o número 1 acima. No entanto, há uma distinção importante a ser feita. O buttonOriginalWidthacima deve ser definido durante o viewDidLoad para impedir que alguém altere a largura dos botões antes que a propriedade seja acessada.
2. Em todo lugar
Na maioria das vezes, os Opcionais Implicitamente Desembrulhados devem ser evitados porque, se usado incorretamente, todo o seu aplicativo falhará quando for acessado enquanto nil. Se você nunca tiver certeza se uma variável pode ser nula, sempre use o Opcional normal. Desembrulhar uma variável que nunca é nilcertamente não dói muito.
if someOptional.