Java应该在哪里判断List是否为空

Java应该在哪里判断List是否为空

目录前言一个问题解决方案更好的方案总结

前言

在新的一年，我又重新回到了java技术栈(我肯定是疯了！)。有句诗说得好，不识庐山真面目，只缘身在此山中。我仍然喜欢函数式编程，但我现在需要离它远一点，这样才能更好地理解它。

在这篇博客中，我会分享一个在项目中遇到的问题，看看能不能有更好的解决方案。

一个问题

我们有一个函数，返回的是一个Panel List

public Optional&lhttp://t;List> generatePanels() {

...

return panels;

}

在Controller层，如果Panel List为空，我们就返回404

Optional> panels = generatePanels();

if(!panels.filter(panelList -> !panelList.isEmpty()).isPresent()){

throw new NotFoundError("There is no panel")

}

工程里调用这个函数的地方很多且逻辑一样，这也就意味着会有很多这样的重复代码。

解决方案

我们可以把判断Panel List是否为空的逻辑挪到generatePanels 函数里面

public Optional> generatePanels() {

...

return panels.filter(panelList -> !panelList.isEmpty());

}

这样调用该函数的地方不需要再做非空判断，我们也可以直接把Optional传给框架，由框架决定是否返回404。

但这里有一个隐式上下文，也就是我们约定generatePanels只要返回结果，就一定会返回一个非空的Panel List。我们需要时刻牢记这个约定，否则我们无法回答下面的质疑

Optional> panels = generatePanels();

Panel firstPanel;

if(panels.isPresent()){

firstPanel = panels.get().get(0); // List可能为空，这个操作会引起bug

}

我们当然可以添加一个测试来保证generatePanels永远返回非空的Panel List，我们也可以添加详尽的文档来解释这个函数的逻辑，但人们往往会忘记或忽略这些。就像超速，我们总是在提醒人们不要超速，甚至还制定了法律，但每年还是有很多人死于超速。

更好的方案

对于超速，更好的方案是从物理层面加以限制，例如在制造汽车的时候就使其速度不能超过60 km/h。

对于我们面临的问题，更好的方案是从编译器层加以限制，使其返回一个NonEmptyList。这样我们不需要额外记住任何信息，这个函数的签名就已经告诉我们它会做的事情。

以Scala代码为例

def Option[NonEmptyList[Panel]] generatePanels() {

...

val panels: Option[List[Panel]] = ...

panels.flatMap(x=> NonEmptyList.fromList(x))

}

这样我们可以很安全的拿到List的第一个元素

val panels: Option[NonEmptyList[Panel]] = generatePanels();

var firstPanel Panel;

if(panels.isSome()){

firstPanel = panels.get().head;

}

总结

我们不应该仅仅依靠人们的脑子，我们要充分利用编译器。一个正确的函数签名可以从bug和debug中拯救我们。

在函数式编程中，我们总是在讨论side-effect。以上面的场景为例，如果函数返回了一个List，但我们真实的目的其实是返回一个非空List，那么对于调用者来说，非空的判断逻辑就是side-effect, 因为它无法从函数签名中看出来。从这个角度讲，也许我们应该允许问题中的重复代码存在，也就是说在每个调用的地方去判断Panel List是否为空。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。