java8 ::关键字_社区帖子：Java中的最终关键字

java8 ::关键字

在2013年的一项新功能中，我们重点介绍社区成员的博客文章。 本周的帖子来自白天在英国的Java开发人员Alex Collins ，晚上则来自Clojure，Python，Grails或Android黑客。 原始帖子可以在这里找到。

尽管许多人不愿在Java代码中使用final关键字，但我发现它充满了新鲜空气。 在编写代码时，也许我倾向于谨慎，保守和安全：不变性是此类示例中的一个。 在这篇文章中，我认为最好使用它，就像避免疑惑使其更有效地解决问题一样。

因此，当人们问为什么我在代码中声明尽可能多的final时，不变性是我引用的最强烈的理由，但是就许多方面而言，final的使用确实有一些警告。


最终变量

根据Java语言规范 ：

可以将变量声明为final。 最终变量只能分配一次。 声明变量final可作为有用的文档，其值不会改变，并有助于避免编程错误。

如果将最终变量赋值给它，则是编译时错误，除非在赋值之前肯定未赋值（第16节）。

这意味着局部或类作用域，如果您声明变量final，则必须将其赋值，并且（根据某些规则）编译器会抱怨后续尝试。

对我来说，这很有用，因为如果某些事情无法改变，那为什么要这么做呢？ 如果我可以让编译器可靠，一致地为我做些事情，那为什么不呢？ 再说一次：如果一个值不应该改变，那么请确保它不会改变。


可读性

某些人可能发现以下代码比使用final的等效代码更具可读性：

public float calculateAverageAge(Collection personCol) {
    float ageSum = 0;
    for (Person p : personCol) {
        ageSum += p.getAge();
    }
    return ageSum / personCol.size();
}

但是，当我们比较时，几乎没有什么区别：



话虽如此，这句老话“对代码的读取次数要比对代码的读取次数更多”，这是一个有力的理由。 虽然我个人觉得这不是实际上是不可读的，但我冒险涉足主观性的参数，我们都知道是徒劳的。 也许只是因为您不习惯它而使它的可读性更差？ 也许如果这很平常，那我们永远不会有问题。 如果它是一个屏幕房地产的问题： 最终有相同数量的字母为C关键字信息常量和有那些谁认为使用常量是很好的做法太; 更不用说我们不再是80个字符宽的终端的时代了。


不变性

我认为可以说软件很复杂是公平的。 在可能的情况下降低复杂度使解决方案的推理变得更容易。 因此，更易于推理的解决方案更易于在编程级别上实现。

对任何给定代码库中的复杂性的攻击是状态的改变：系统逻辑某些方面所依赖的某些实体的属性更改导致必须考虑的内容增加。 有人可能会争辩说，减少状态突变会降低复杂性，因此这会导致更简单的解决方案。 在这里， final可以提供帮助。 我的参考不能改变。 递归地，该对象引用内的属性无法更改，这反过来意味着我对使用这些对象的兴趣不足为奇，也无需多加理会。 这是一个可以级联的解决方案。 [更新：如reddit所述，final关键字不会扩展到对象实例的字段，这与C在结构上的<pre> const </ pre>不同。 我故意在后续帖子中省略了此信息！]如果您不同意：将“更简单”替换为“简单”，然后重新考虑。

再说一次：如果某些事情无法改变，那为什么要让它改变呢？ 在声明5个引用并且只能更改（重新分配）引用的代码块中，这就是我们必须担心的问题。 在更多情况下，单元测试应该涵盖这一点。 是新程序员在编写代码6个月后阅读该代码的地方。


功能编程

在函数式编程世界中，纯净的想法是基本原则。 如果函数没有副作用，则它们是纯函数。 它们本质上是等幂的：相同的输入产生相同的输出。 相比之下，面向对象世界至少没有相同的做法。

为了满足封装要求，我们提供了变量器 ，该变量器提供了对象某些属性的接口。 再加上抽象，这些允许更改对象的内部结构而不会强迫其客户端更改。 但问题就出在这里。 编译时间的变化只是变化的一小部分。 同样值得关注的是该依赖项的语义。 如果不必重新编译代码，那很好，但是该链接背后的实际意图如何？ 逻辑改变了吗？ 这有什么影响？ 我怎么知道？

无论哪种情况，答案都是没有测试或没有分析代码就无法分辨。 我认为这不是一个大问题：随着变化，我们需要断言其有效性。 如果我们可以鼓励代码“按计划行事”，那么我们有更简单的解决方案。 如果不存在副作用，那么我们的简单性还有另外一个特点。 吻，对吗？


结论

争论在专业软件开发“舞台”上做绝对事情的理由从来都不容易。 人们要么通过艰苦的方式学习，要么通过团队合作学习到这些绝对规则很少而且相差甚远。 同样，盲目地应用概念或模式或在不适合解决方案的地方应用也会导致问题。

尽管如上所述，但我还是争辩说，降低复杂性始终是解决方案所要解决的问题，有时这是不可避免的。 那么，为什么不减少它，让我们将精力花在复杂的元素上，无法进一步稀释的组件上？

翻译自: https://jaxenter.com/community-post-the-final-keyword-in-java-105499.html

java8 ::关键字