重复空检查的最佳实践答案

【问题标题】：Best practice for repeated null checks重复空检查的最佳实践
【发布时间】：2021-09-27 12:00:59
【问题描述】：

我的应用有一个公共区域，以及一个用户必须经过身份验证的区域，例如一个带有聊天的页面。在最低级别，我有我的 authenticationService，我可以通过在其中检查 null 来检查用户是否经过身份验证：

authenticationService.currentUser

当我更新此功能以实现空值安全时，我将此变量声明为：

User? _currentUser;

然而，在聊天组件中，我也经常需要访问用户，因为我知道用户必须已经通过身份验证才能访问此区域，所以我使用“！”非常喜欢：

authenticationService.currentUser!

此外，我在一些入口点上使用 assert 至少在开发过程中捕获错误：

assert(authenticationService.currentUser != null);

有没有比使用“！”更好的方法？在这些领域有很多，基本上在这里禁用了 null 安全性并希望最好？

【问题讨论】：

如果您知道该变量永远不会为空，则不要将其声明为可为空。可以使用late关键字：late User _currentUser;
但是如果用户没有通过身份验证则为空...
您可以从名为 AnonimousUser 的用户创建子类并在开始时分配它。用户 _currentUser = AnonimousUser();然后稍后如果用户登录您更改它： _currentUser = User();并将 authenticationService.currentUser != null 更改为 authenticationService.currentUser 是 AnonimousUser 或将 isAnonimous() 方法添加到类

【解决方案1】：

我会避免直接访问 _currentUser 变量，而是通过两个不同的 getter：

User get currentUser => 
    _currentUser ?? (throw StateError("Not authenticated"));

bool get isAuthenticated => _currentUser != null;

这使状态逻辑对一些方法保持本地化，现在您自己的工作是确保仅在知道 currentUser 已通过身份验证时才读取它。这与现在没有什么不同，如果你犯了一个错误，你只会得到一个比! 更易读的错误。

（由于您的变量名为 _currentUser 并且您的代码正在执行 .currentUser，因此您可能已经有一个包装变量的 getter）。

【讨论】：

我喜欢这样，调用命名方法而不是检查 null 以查看用户是否经过身份验证更明确，访问用户时不再断言，并且在发生错误时显式错误。你说得对，我什至已经得到了吸气剂。