Java Getter 和 Setter 完整指南：受控访问的艺术

信息技术数字 » 程序设计 » Java Getter 和 Setter 完整指南：受控访问的艺术

在面向对象编程领域，Java 仍然是最流行、最广泛教授的语言之一，这主要归功于其对封装和数据访问管理等概念的清晰定义。该框架中的两个关键要素是被称为 getter 和 setter 的方法，它们是控制对象内部数据如何被操作和公开的基本组件。

本文将以自然易懂的方式，结合实际示例，深入探讨Java 中 getter 和 setter 的用途、优势，以及相关的争议。我们将详细分析它们的实现方式、重要性，以及在哪些情况下应该使用它们，在哪些情况下应该避免使用它们。此外，我们还将汇总当前关于最佳实践和最差实践的观点，以便您在设计自己的 Java 类时做出明智的选择。

Java 中的 getter 和 setter 是什么？

在 Java 中，封装原则要求我们将类的属性标记为私有属性，从而保护它们的安全。这可以防止从对象外部随意访问或修改这些属性，确保系统状态的安全性和一致性。然而，这些属性通常需要从外部进行查询或修改。这时就需要使用getter 和 setter方法——专门用于获取（get）或修改（set）这些私有字段值的公共方法。

这种模式非常常见，以至于像 IntelliJ IDEA 或 Eclipse 这样的集成开发环境 (IDE) 允许你自动生成它们。例如，对于一个简单的类：

具有 getter 和 setter 的基本类示例

公共类 Person { 私有字符串名称； 私有 int 年龄； 公共字符串 getName() { 返回名称； } 公共 void setName(String name) { this.name = name; } 公共 int getAge() { 返回年龄； } 公共 void setAge(int age) { this.age = age; } }

在此模型中， `getNombre()`和`setNombre(String nombre)`方法允许您以受控的方式访问和修改 ` name`属性。其主要优势在于，您可以在这些方法中添加逻辑或验证，从而确保数据始终保持一致并满足特定条件。

为什么要使用 getter 和 setter？封装和访问控制

使用getter 和 setter的经典原因是需要保护类的内部数据。当属性是公共的时，程序中的任何位置都可以修改它们，这可能导致不一致或意外的状态。

例如，我们来看一个带有公共属性的Cat类：

公共类 Cat { 公共字符串名称；公共整数年龄；公共整数体重；}

在这种情况下，任何外部代码都可以执行以下操作：

猫 cat = new Cat(); cat.name = ""; cat.age = -1000; cat.weight = 0;

这会完全暴露类的内部结构，并允许无效值。通过将属性设为私有，并仅公开受控的公共方法，我们可以添加限制：

public void setAge(int age) { if (age >= 0) { this.age = age; } else { System.out.println("错误！年龄不能为负数！"); } }

这样可以防止猫的年龄出现像 -1000 这样的荒谬值，并将验证逻辑集中在一处。如此一来，如果程序的多个部分需要修改年龄，它们都将经过相同的验证流程。

Java 中 getter 和 setter 的优点

这种模式有几个优点：

• 隐私权政策：通过将属性设为私有，可以防止不加区分的访问和修改。
• 集中验证：设置者可以在分配值之前进行检查，以确保满足业务或完整性规则。
• 未来的灵活性- 如果您在任何时候需要更改某条数据的内部表示形式（例如，根据出生日期计算年龄），您可以在 getter 中进行更改，而无需更改使用它的其余代码。
• 框架兼容性：许多 Java 框架和库（例如 Hibernate、Spring、JSON 序列化器/反序列化器）都需要 getter 和 setter 才能正常工作。

使用 getter 和 setter 可以促进代码的长期演进和维护，允许在不破坏类的公共接口的情况下修改内部逻辑。

实例与典型结构

回到几个热门网站提出的例子，教程中经常会出现Account类来阐释这个概念：

类帐户{ 私人双倍余额; 私人双倍限制; 公共双倍getBalance（）{ 返回余额; } 公共无效setBalance（双倍余额）{ this.balance = balance; } 公共双倍getLimite（）{ 返回限制; } 公共无效setLimite（双倍限制）{ this.limit = limit; } }

这种结构虽然实用，但最近却因助长方法的泛滥而受到批评，而这些方法在很多情况下是毫无用途的。最常见的问题之一是不加区分地生成 getter 和 setter，而没有评估它们对于设计或业务逻辑是否真正必要。

风险和不良做法：什么时候不应该过度使用 getter 和 setter？

自动生成所有 getter 和 setter 方法会导致所谓的贫血类或“傀儡类”，它们仅仅充当数据容器，自身没有逻辑。这可能会带来以下几个负面影响：

• 不必要的曝光：如果所有属性都可以从外部访问或修改，那么封装所寻求的一些保护就会丢失。
• 分散的复杂性：当从系统中的多个点访问和修改属性时，很难集中业务规则或验证。
• 糟糕的领域模型：业务逻辑应该驻留在域实体内，而不是分散在服务或系统的其他部分。

例如，使用 `setBalance()` 设置银行账户余额可能并不合理：最好提供更具体的函数，例如 `deposit()` 或 `withdraw()`，这些函数封装了相应的规则（例如，取款时检查账户限额）。这样可以使代码更清晰、更健壮。

公共 void 存款（double x）{ this.balance += x; } 公共 void 获取（double x）{ if (this.balance + this.limit >= x) { this.balance -= x; } else { 抛出新的 IllegalArgumentException（“超出限制！”）; } }

这可以防止外部操纵平衡，维护系统的完整性。

实现 getter 和 setter 的良好做法

根据多篇技术文章和博客中分享的经验，对于合理使用 getter 和 setter 有几点建议：

• 不要为所有属性自动生成它们. 仅当您的模型或架构确实需要它们时才添加它们。
• 仅在必要时包含验证并非所有属性都需要复杂的控制，但影响逻辑的属性则需要。
• 考虑不变性 对于某些对象。您可以创建不可变的类（例如，具有 final 属性且没有 setter），从而减少错误和调试难度。
• 权衡框架的需求：有时您需要包含这些方法才能使 Hibernate 或 Jackson 等工具正常工作，但如果可能的话，请尝试将这些要求与您的主逻辑隔离开来。

简而言之，应将getter和setter用作控制机制，而不是自动解决方案。每个属性和方法都应该为你的类增添实际价值。

现代替代方案和模式

Java 和设计模式的演变为传统的 getter 和 setter 的使用提供了有趣的替代方案：

• 简单数据结构的公共类：如果只是简单的“数据载体”，没有逻辑，可以使用具有公共属性的类，避免重复代码。
• 使用 Lombok 等库：您可以使用@Getter 和@Setter 等注释标记您的类，以自动生成方法并减少样板。
• 促进不变性：通常最好创建一旦创建就无法改变其状态的对象，这样就无需设置器并可防止难以追踪的错误。

例如，对于不可变实体，您可以实现如下操作：

公共类 Person { 私有最终字符串名称； 私有最终整数年龄； 公共 Person(String name，int age) { this.name = Objects.requireNonNull(name); this.age = Objects.requireNonNull(age); } 公共字符串 getName() { 返回名称； } 公共 int getAge() { 返回年龄； } }

这里只有一个 getter 方法，并且对象在创建后永远无法更改其状态。对于不应被修改的实体，强烈建议使用此技术。

框架和库环境中的 getter 和 setter

Getter 和 Setter 方法并非总是出于设计原因而使用；有时，某些框架会要求它们。例如，像 Hibernate 这样的 ORM 库或对象序列化/反序列化工具（例如 ` what is BLOB`）要求实体必须具有用于访问属性的公共方法。因此，许多开发人员被迫添加这些方法，即使仅仅是为了满足这些技术要求。

另一方面，像 Spring 这样的框架也影响了 setter 的泛滥，尤其是在依赖项配置阶段（setter 注入）。然而，建议尽可能优先使用构造函数注入，因为它可以确保对象始终以一致的状态创建，并最大限度地减少由对象不完整导致的错误。

你应该总是创建 getter 和 setter 吗？最后的想法

答案并非总是肯定的：并非所有属性都需要访问器方法，也并非所有类都需要getter和setter方法。此外，滥用这些方法会使代码更加脆弱、安全性更低，并且与面向对象编程原则相悖。

您可以分析是否确实需要公开数据，或者是否有更好的机制来封装逻辑并维护状态控制。设计类时，务必确保信息以可控的方式流动，避免在未评估其影响的情况下自动生成方法。

这场争论远不止于简单的代码问题。了解何时以及如何使用封装、应用验证、提倡不可变性以及理解框架的上下文，都是创建健壮、可扩展且易于维护的 Java 代码的关键因素。要充分利用封装，但始终要考虑过度使用封装的风险以及 Java 中现有的替代方案。