Java 8之后的那些新特性(一):局部变量var

2022-04-15 08:29:48 浏览数 (1)

本周开始,我将开启一个新的系列,这个系列是关于Java的。

在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发展出了新的能让代码更简洁的语法特性。

一起来随我一起了解一下,究竟有哪些新的语言特性值得我们关注吧。

这是第一篇,我来说一下局部变量var这个特性吧。

变量与常量

在声明变量这个事情上,大家所熟知的Java变量申明方式是:

代码语言:javascript复制
//变量
EntityRepository entityRepository = new EntityRepositoryJPA();
//常量
final String httpMethod = "post"

Java变量申明的方式是类 名称的方式来进行申明 ,如果是常量,则以final关键字来申明。

我们可以对比下其它语言的变量申明方式

Kotlin中是以var声明变量,val申明常量

代码语言:javascript复制
//变量
var entityRepository = EntityRepositoryJPA()
//常量
val httpMehod = "post"

TypeScript是以let来声明变量,const来申明常量

代码语言:javascript复制
//变量
let entityRepository = new EntityRepositoryJPA()
//常量
const httpMethod = "post"

Swift中是由var定义变量,let来定义常量

代码语言:javascript复制
//变量
var entityRepository = EntityRepositoryJPA()
//常量
let httpMethod = "post"

从上面对比可以看出,相较于Java的类型 名称的定义方式,新的语言都偏好关键字 名称的模式。

类型推定

事实上,现代编程语言,都非常喜欢最大限度地使用类型推定,也就是关键字 名称这种模式。

类型推定的基本原则是:只要通过上下文能猜测到的,就不需要明确声明它的类型

因为,一个显而易见的点是,这样的代码确实更简洁。

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

代码语言:javascript复制
//使用(关键字   名称)的模式重写

//变量
var entityRepository = new EntityRepositoryJPA();

依据类型自动判定的逻辑,编译器和我们程序员,都会很显而易见的猜测到,entityRepository的类型是EntityRepositoryJPA类的实例。

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

代码语言:javascript复制
//使用旧有模式
Collector<String, ?, Map<String, Long>> byOccurrence
     = groupingBy(Function.identity(), counting());

//使用var来重写
var byOccurrence = groupingBy(Function.identity(), counting());

语法解析

所以,Java 10引进了局部变量var这个关键字,最显著的一个原因就是:简化代码

很难说这个特性没有借鉴其它现代主流语言,我认为肯定是参考与借鉴了的。

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

•var关键字只能在方法中使用,不能在方法参数,类属性等上使用•var是变量的含义,没有简化常量的关键字

其中,最大的一个受限就是,你只能在方法中的局部变量中使用var这个关键字

代码语言:javascript复制
   @Test
    void 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语言的程序员来说,这个特性的缺点表现为如下:

1.Java程序员并不习惯这个风格

如果是前端 ,移动端的程序员,他们使用的主要编程语言都基本上是关键字 名称的模式,会对这种风格非常熟悉。

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

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

我们都非常喜欢自己熟悉的风格,不是么?

2.局部的优化而非全局性转变

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

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

3.影响了代码的可读性

好吧,我们都知道,简洁性与可读性可能有时候方向不太一样;越简洁,有时候越难以阅读,啰嗦一点,可能读起来更容易理解。

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

关于这一点,IDEA这个工具为了强化可读性,提供了一个非常有意思的工具辅助。参照下面的图

看到没,IDEA自动把var的类型显示出来了。

为什么IDEA要这么干?肯定是因为Java程序员不太熟悉这种风格,用这种方式来帮助和提醒程序员。

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

参照如图所示:

可见,这个提示是特意为Java准备的,非常贴心。

值得赞赏的进步

在我知道Java有局部变量以后,受到我过往使用其它语言的影响,我确实很快转变过来了,这种转变几乎不费什么成本。而且从我的编码感觉上来看,这种确实令代码更简洁,这是肯定的。

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

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

当然,一切都由你自己随心所欲来决定了。

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

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

仅凭我们对Java的热爱,我们也确实值得跟随我们喜欢的这门语言,不要再停留在八年前的版本了,不是么?

下一篇,我将继续聊聊Java 8之后的有意思的新特性。

0 人点赞