强制<T>是否会与Guava的Optional <T>一起成为有用的补充?

bra*_*ter 0 java null interface guava notnull

我正在查看Guava的Optional类及其理由,我想知道在表示不能为null的值时,类似的类是否快速失败会有所帮助.我找不到任何关于这个想法的讨论,所以我想我会问这里.

我的第一次尝试将尝试保持Guava使用的风格,一个Mandatory<T>暴露静态工厂of(T t).NullPointerException如果使用null参数调用,则抛出此方法.

我特别感兴趣的是在空处理方面确定接口方法的语义.我认为是否接受空参数是一个应该在接口中可以指定的设计决策,以便可以相应地设计客户端代码并避免重复前置条件检查逻辑.因此,使用此类的接口可能具有类似的方法

fire(Mandatory<Employee> employee);

并且客户可以打电话

fire(Mandatory.of(unfortunateEmployee));

我怀疑强制类型很容易找到使用方面等在调用之前挂钩进一步检查,如果这样的标记方法参数不应该为空是绝对重要的.

我也考虑过基于注释的方法,fire(@NotNull Employee employee)但是我看到的实现需要额外的验证器连线.

所以,问题......这个想法在任何地方都存在吗?如果没有,我是否错过了一些明显破坏它的东西?或者更好的想法来实现这一目标?

Lou*_*man 6

fire(Mandatory<Employee> employee);
Run Code Online (Sandbox Code Playgroud)

如果你有一个带有这个签名的方法,你仍然可以打电话fire(null); 它只是你有一个null类型Mandatory<Employee>而不是类型Employee.你根本没有提高安全性; 你刚刚添加了一个冗余的包装层.

如果你想强制要求一个参数,那么好的做法是使用eg Preconditions.checkNotNull作为你方法中的第一件事,NullPointerException如果值为null ,则立即抛出a .