我一直在研究Java流和函数式编程。想出了一种重写小的“用户登录”代码的方法。
这是我的登录方法；如果来自查询的用户为空，则在过滤器上处理空指针异常。
public ResponseEntity login(User request) {
User dbUser = userRepo.findByEmail(request.getEmail());
if (!aes.matches(request.getPassword(), dbUser.getPassword()))
return ResponseEntity.status(403).build();
return logUserIn(dbUser);
}
private ResponseEntity logUserIn(User dbUser) {
dbUser.setPassword(null);
jwtHandler.setJwtCookie(dbUser);
return ResponseEntity.ok(dbUser);
}
并且通过使用流；
public ResponseEntity login(User request) {
return Stream.of(userRepo.findByEmail(request.getEmail()))
.filter(dbUser -> aes.matches(request.getPassword(), dbUser.getPassword()))
.map(this::logUserIn)
.findFirst()
.orElse(ResponseEntity.status(403).build());
}
private ResponseEntity logUserIn(User dbUser) {
dbUser.setPassword(null);
jwtHandler.setJwtCookie(dbUser);
return ResponseEntity.ok(dbUser);
}
我不知道是否应该以这种方式使用流。是吗如果我在项目的重要部分使用类似的逻辑，以后会遇到麻烦吗？
[大多数情况下，您会遇到麻烦。 “根本”的问题是，两种写法都可以作为“最佳选择”辩解，而Java社区总体上强烈倾向于第二种形式。出于同样的原因，对name_variables_like_this也是个坏主意（社区决定约定为nameThemLikeThis）。打破常规将意味着您的代码很难被他人阅读，而他人编写的代码对于您来说则更难阅读。另外，当您尝试与其他代码进行交互时，您可能会遇到磨擦。
例如，现在（以及可预见的将来），'lambdas'（带有::和->的东西）不是异常透明的，不是控制流透明的，不是可变的局部变量透明的。] >
这里只有3个可行的选择：
以某种方式编写所有代码，以使这3个透明胶片与never
不相关，无论您要写什么。这对我来说听起来是不可能的。即使您以某种方式进行管理，也存在其他库。从java.*开始，该代码不是为这种代码样式设计的。混合代码样式，当您没有立即看到透明胶片是相关的时，使用lambda样式，否则使用较为必要的样式（如果您认为可能）。这对我来说听起来很愚蠢。当一个样式可以涵盖所有用例时，为什么要混合两种样式？
具有lambda样式的线条，向后弯曲以解决这3个透明胶片所困扰的问题，将这些胶片“降级”为AtomicX变体，使用此类构造来传递异常，并使用布尔标志来携带中断和继续控制外部等植物的流动。这只是编写丑陋的代码，只是因为您对新奇的闪亮锤子特别着迷，并且坚持将所有问题都视为钉子，不是吗？
那是..试图猜测当您与其他代码和其他程序员进行交互时会发生什么。这个片段，在真空中，只有你吗？嗯，都很好。无论您喜欢哪个社区，与其他代码的摩擦以及保持一致的样式都无关紧要。