Java首席语言架构师谈JavaBeans的setter可变性

21-08-27 banq

Java 程序员是否应该放弃属性setter方法,并对其领域对象进行不可变的建模
Java首席语言架构师Brian Goetz认为:“问题中隐含的非此即彼,这会暗示只有一种正确的方法可以对程序中的数据进行建模,这有点误导。(banq注:是误导还是判断误导的依据已经过时?),我们的同事 Alex Buckley,Java 语言和 JVM 的规范负责人,喜欢说令人惊讶的事情之一是 Java 设法将所有默认设置都弄错了,但仍然成功了(banq注:都做错了,却成功了,只能说明运气好,上下文为王,时势造英雄,矮子里面选将军,如果Go语言同时与Java诞生,则结果不一定如此)。”
Goetz 认为:在 Java 中:可变性的默认设置是错误的;可访问性的默认设置是错误的;类是否可扩展的默认设置是错误的。然而,不知何故,我们设法在这些错误中幸存下来了。
JavaBeans 命名约定有点不幸,对于通用开发来说,这是一个糟糕的约定。这是在可视化编辑器中命名可视化组件的一个相当有针对性的约定,您可以将按钮和标签之类的东西拖放到画布上,并且您有可以编辑前景色和字体等内容的属性表有你,可以通过反思发现。(banq注:终于承认JavaBeans过时了,其诞生的上下文是为了前端显示GUI,但是Java现在只能用在后端,谁还在浏览器里运行JavaFX或Applet?)
命名约定是构建这些 UI 组件的好方法——结果证明这种GUI不是一个关键的 Java 用例。然而,不知何故,我们继续使用该命名约定,即使它与大多数业务领域对象的匹配度如此差。
由于这些约定,可变性被大大过度使用和高估,不变性是管理复杂性的工具,因为它让我们可以将注意力集中在项目中实际上必须复杂的部分。
解决答案是记录Record:记录是一种语言特征,它认识到不变性的重要性,记录使将数据建模为数据变得更容易,并且密封sealed类型和模式匹配正在将 Java 推向更多面向数据的编程模型。
随着我们使用越来越多的小型服务、微服务和功能即函数,程序变得越来越小。更多的代码更接近网络边际,开发人员将处理不再是 Java 对象,而是一些未绑定的 XML 或 JSON 或其他字符串的数据。我们想将该数据建模为普通数据。Java 语言正朝着更容易做到这一点的方向发展。



 

猜你喜欢