拉钩教育-数据分析实战训练营

链接：https://pan.baidu.com/s/1DGD8...
提取码：sm0f
--来自百度网盘超级会员V4的分享
Java 8之后的那些新个性（一）：局部变量var

在IDEA中2021年的一个考察中，程序员中使用Java的版本中，Java 8仍是支流。新的长期反对版Java 11，Java 17并未有Java 8流行。

我并不认为肯定得使用新版的Java，但咱们也要意识到Java 8是在2014年公布的，距今已经是8年之久了。而在这8年中，类似Kotlin，Swift，TypeScript语言都在不断的更新优化自己的语言个性。

这使得Java 8相比起来，在让代码更简洁斯文上越来越有所差距。好在，Java并未停止它前进的步调，从Java 8之后的许多个版本，在借鉴参考其它语言优良的个性的基础之上，Java发展出了新的能让代码更简洁的语法个性。

变量与常量
在申明变量这个事件上，大家所熟知的Java变量申明形式是：

//变量
EntityRepository entityRepository = new EntityRepositoryJPA();
//常量
final String httpMethod = "post"
复制代码
Java变量申明的形式是类 + 名称的形式来进行申明 ，如果是常量，则以final关键字来申明。

咱们可能对比下其它语言的变量申明形式

Kotlin中是以var申明变量，val申明常量

//变量
var entityRepository = EntityRepositoryJPA()
//常量
val httpMehod = "post"
复制代码
TypeScript是以let来申明变量，const来申明常量

//变量
let entityRepository = new EntityRepositoryJPA()
//常量
const httpMethod = "post"
复制代码
Swift中是由var定义变量，let来定义常量

//变量
var entityRepository = EntityRepositoryJPA()
//常量
let httpMethod = "post"
复制代码
从下面对比可能看出，相较于Java的类型 + 名称的定义形式，新的语言都偏好关键字 + 名称的模式。

类型主动判定
事实上，古代编程语言，都非常喜爱最大限度的使用类型主动判定，也就是关键字 +名称这种模式。

类型推定的基本原则是：只需通过上下文能猜想到的，就不需要明确申明它的类型

因为，一个不言而喻的点是，这样的代码确实更简洁。

咱们如果用关键字 + 名称的写法来重写上述Java代码中的变量与常量定义，那咱们的代码就是是如此：

//使用(关键字 + 名称)的模式重写
//变量
var entityRepository = new EntityRepositoryJPA();
//常量
var httpMethod = "post"
复制代码
依据类型主动判定的逻辑，编译器和咱们程序员，都会很不言而喻的猜想到，entityRepository的类型是EntityRepositoryJPA类的实例，而httpMethod则是一个String类型。

当然，下面这个例子可能不太令人感觉到必要性，因为简洁不到哪去，但在一些简单的场景中，确实能简洁很多

//使用旧有模式
Collector<String, ?, Map<String, Long>> byOccurrence

 = groupingBy(Function.identity(), counting());

//使用var来重写
var byOccurrence = groupingBy(Function.identity(), counting());
复制代码
语法解析
所以，Java 10引进了局部变量var这个关键字，最显著的一个原因就是：简化代码

很难说这个个性没有借鉴其它古代支流语言，我认为必定是参考与借鉴了的。

但受限于Java过于长久的历史，这个个性相比其它语言，也只是个半吊子的实现，它有挺多的限度

var关键字只能在方法中使用，不能在方法参数，类参数等上使用
var是变量的含意，没有简化常量的关键字
其中，最大的一个受限就是，你只能在方法中的局部变量中使用var这个关键字

@Testvoid testEntityExists(){    var exists = repository.exists(User.class,-1L);    Assertions.assertFalse(exists);    var created = repository.save(randomUser());    exists = repository.exists(User.class,created.getId());    Assertions.assertTrue(exists);}

复制代码
如上代码所示，你只能在方法外部使用var，不能在其它地方使用这个关键字，而且它示意变量，对于常量，并无相应的关键字来简化。

缺点与影响
长处我就不说了，下面说了，最大的也基本上是最次要的长处是让代码更简洁。

还是来说缺点吧。

就我集体的经历来说，我认为，对于长期使用Java语言的程序员来说，这个个性的缺点体现为如下：

Java程序员并不习惯这个风格
如果是前端 ，移动端的程序员，他们使用的次要编程语言都基本上是关键字+名称的模式，会对这种风格非常熟悉。

比如对于我这样的，确实我在知道这个个性之后，非常喜爱这样，瞬间基本上就切换为这种模式了，因为我在其它语言中，都是这种风格，我习惯了关键字+名字的风格。

但一直从事Java的程序员并不一样，类名+名称的风格他们太熟悉了，对他们来说，这个半吊子个性并无特地使用的必要。

咱们都非常喜爱自己熟悉的风格，不是么？

局部的优化而非全局性转变
Java的这个转变，并非是全局性的，你在类的变量，方法参数中，并不能使用这种风格。

这导致这个转变的影响面比较小，可能进一步加剧了大家对这个个性的忽略。

影响了代码的可读性
好吧，咱们都知道，简洁性与可读性可能有时候方向不太一样；越简洁，有时候越难以浏览，啰嗦一点，可能读起来更容易理解。

这种风格，对于习惯了的人来说，并不存在浏览性上的减弱的影响，但对于Java程序员来说，感觉可读性还是会升高一些。

为什么IDEA要这么干？必定是因为Java程序员不太熟悉这种风格，用这种形式来帮助和提醒程序员。

但站在常常使用其它语言的人，比如我这样的来看，这种并无太多必要。事实上，在IDEA中使用Kotlin时，压根就没有这种提醒。

值得投诉的提高
在我知道Java有局部变量当前，受到我过往使用其它语言的影响，我确实很快转变过去了，这种转变几乎不费什么成本。而且从我的编码感觉上来看，这种确实令代码更简洁，这是必定的。

但对于那些从始至终使用Java的程序员来说，这种转变我认为需要一些成本。

但为了谋求代码的简洁性，这也是非常值得的。

当然，所有都由你自己随心所欲来决定了。

不过从这一点上来看，我倒是对Java这门语言另眼相看，它确实没有停止自己的步调，不断的借鉴与学习其它古代语言的一些新的好的做法，改进自身。

而从Java 8到现在最新的Java 17，这个语言都升级了这么多个版本，改进的当然不会是只这一点。