我的观点是，在某些地方，我们知道该变量根本不会为零，但由于某种原因，我们无法在类的 init 函数中实例化它，因此我们必须将其设为可选。
我也知道我们可以使用可选的绑定或防护技术来轻松摆脱它。
但在我看来，由于隐式解包/强制解包而让应用程序因一些非常愚蠢的错误而崩溃对于开发阶段的开发人员来说是有益的.
我的例子是：
class TopStoriesViewModelTests: XCTestCase {
var viewModel: TopStoriesViewModel!
override func setUp() {
super.setUp()
viewModel = TopStoriesViewModel(interactor: MockTopStoriesInteractor())
}
func testArticleDidVisited() {
viewModel.visited = xxxxxx
}
}
在这种情况下我可以使TopStoriesViewModel a ?然后保护它或者让它在每个测试用例中，但我觉得这是没有必要的。我知道我可能会使用viewModel?.xxx也。但这不是重点。
我的问题是，在某些特定情况下（例如我给出的示例），强制解包/隐式解包是有益的，这一点我是否正确。
当然。有许多强制展开的正确用途，其中崩溃只会在开发早期发生，因为已经犯了错误，一旦修复，崩溃就不会再发生。
一个常见的示例是访问资源包中的图像。一行例如：
let imagePath = Bundle.main.path(forResource: "image", ofType: "png")!
如果开发人员忘记瞄准目标，那么在早期开发中应该会崩溃image.png适当地。一旦正确定位，该行就不会崩溃，因此没有理由处理可选路径。
其他常见的例子是奥特莱斯。它们通常是隐式展开的，因为当它们在视图控制器的代码中使用时，它们已经被附加了。崩溃可能意味着插座连接不正确。问题解决了，就不用再担心了。无需处理警卫或其他可选检查。
最后一个例子（还有更多可能性）。当从表视图中使单元格出列时，将结果单元格强制转换为自定义单元格类型。不需要看守。我总是在这里看到使用守卫的代码as?如果转换失败则抛出致命错误。只是强制施放。使用更少的代码也会发生同样的崩溃。一旦表格视图和故事板正确，强制投射就不会失败。
话虽如此，新的 Swift 开发人员应该避免!键盘上的字符一段时间。知道何时安全使用它是一项需要学习的技能。
如果潜在的崩溃完全由开发人员控制，并且崩溃只能因为开发人员犯了错误而发生，那么使用!可能是合适的。
如果潜在的崩溃可能是由意外数据（JSON 解析、用户输入等）引起的，那么永远不要使用!。在这些情况下进行防御性编码。
tl;dr - 是的，在很多情况下，强制展开、强制转换和隐式展开变量是正确的选择。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
