乐趣区

关于云原生:云原生应用架构设计与开发实战MK

云原生利用架构设计与开发实战

download 链接:https://pan.baidu.com/s/18vOi…
提取码:sfm2
– 来自百度网盘超级会员 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 这个关键字

@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 语言的程序员来说,这个个性的缺点体现为如下:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

退出移动版