探究PaLM 2如何工作的完整指南 _PaLM

译者 | 李睿
审校 | 重楼
在不断发展的JAVA开发世界中，开发人员不断寻找工具和代码库来简化代码编写过程。其中一个工具是Project Lombok，通常简称为Lombok 。这个Java库提供了代码生成功能，有望简化开发人员的工作。然而，与任何强大的工具一样，也需要注意避开一些设计缺陷。

文章插图
本文将以Lombok为重点深入研究代码设计的世界，探讨Lombok看似方便的注释(例如Builder和Log)可能并不像看起来那么完美的原因。此外还将强调封装的重要性，并讨论Lombok的Data和NotNull注释如何导致意想不到的挑战。无论是经验丰富的开发人员还是开始走上编码之旅的新手，本文都将提供具有价值的见解，以增强他们的工程技能。
Lombok的优点在深入研究潜在的缺陷之前，有必要认识到Lombok的优点。Lombok提供了几个可以显著简化代码编写的注释：

Log注释：Lombok的Log注释允许开发人员快速生成日志代码，减少对样板代码的需求。
Builder注释：Builder注释通过开发增强代码可读性的构建器方法，简化了复杂对象的创建。

封装的挑战Lombok的应用并不是一帆风顺的。Lombok带来的最重要的挑战之一与封装概念有关。封装是面向对象编程的基本原则，强调将数据(属性)和对数据进行操作的方法(函数)捆绑到一个称为类的单元中。它有助于维护数据完整性，并保护数据免受未经授权的访问。

数据注释：Lombok的数据注释虽然看起来很方便，但可能导致“贫血模型” 。贫血模型是一个术语，用于描述主要存储几乎没有行为的数据的对象。该注释为类中的所有字段生成getter和setter方法，通过将内部状态暴露给外部操作，有效地破坏了封装。

考虑这样一个场景，其中有一个带有敏感信息(如密码字段)的User类。应用Data注释将自动为密码字段生成getter和setter方法，从而可能允许对敏感数据进行未经授权的访问。这可能导致安全漏洞和数据完整性问题。

NotNull注释：另一个挑战来自Lombok的NotNull注释。这里给出的建议是一些来自Java 8的带有Objects.requireNonNull的显式API 。

为了解决Null值的问题，Java8和更高版本提供了一个内置的解决方案。Objects.requireOnNull方法允许开发人员显式检查Null值，并在遇到Null值时抛出NullPointerException 。这种方法提供了一种清晰简洁的方法来处理Null检查，确保基本字段不会未初始化。
以下是如何使用Objects.requireOnNull的示例：
Javapublic void setUser(User user) { this.user = Objects.requireNonNull(user, "User must not be null"); }

通过使用Objects.requireOnNull，开发人员可以更稳健地执行Null检查，即使不依赖Lombok的NotNull注释。
增强代码模板和IDE支持同样需要注意的是，即使不使用Lombok，开发团队也可以在集成开发环境（IDE）中增强代码模板。例如，流行的Java IDE IntelliJ IDEA为生成构建器模式提供了原生支持。开发人员可以创建自定义代码模板，或者使用IDE特定的功能来生成符合他们首选编码标准的代码。
通过利用IDE特性和定制模板，开发团队可以获得Lombok的许多好处，例如减少样板代码和改进代码可读性，同时保持对生成代码的完全控制。
执行最佳实践的挑战在理想情况下，开发人员可以使用像Arch Unit这样的工具来强制执行编码最佳实践，并防止使用不安全的注释。然而，事实表明，这说起来容易做起来难。通过自动化工具避免特定的Lombok注释可能面临挑战或限制。这给代码审查和开发人员带来了更大的责任，以捕捉和纠正潜在的问题。
使用Lombok的权衡像任何工具一样，Lombok从代码设计的角度进行了权衡。它提供了便利，并减少了样板代码，但是也会给数据封装带来风险，并且在代码审查期间需要额外的警惕。在项目中使用Lombok的决定应该经过深思熟虑，需要考虑应用程序的特定需求以及开发团队对Lombok的特性和潜在缺陷的熟悉程度。
结语总之， Lombok是一个强大的工具，可以显著提高Java开发中的代码可读性，并减少样板代码。但是必须谨慎使用它，特别是在数据封装方面。了解潜在的缺陷(例如Data和NotNull注释)对于维护代码完整性和安全性至关重要。