POJO（纯Java对象）的定义并不要求有getter和setter方法。实际上，在我的当前项目中，我并没有使用getter和setter方法。我的方法是：除非有必要，否则不要提供getter和setter方法。到目前为止，我还没有找到真正需要getter和setter的情况。有些朋友告诉我：“如果将来需要某个功能，拥有getter和setter会很有帮助。”我的回答是：如果将来真的需要，我会提供getter和setter方法；我不想过早地预测任何事情。

对于可能提出的封装性方面的异议，这并不是一个有效的理由：提供getter和setter方法会以同样的方式破坏封装性，而且还会增加额外的（无用的）代码。Bugs也可能存在于getter和setter方法中。

以下是一个非常规领域类的示例：

public class SSHKey implements IsSerializable {
    public Long id;
    public Long userId;
    public String type;
    public String bits;
    public String fingerprint;
    public String comment;
    private SSHKey() { // required by gwt-rpc
    }
    public SSHKey(String text) throws InvalidSSHKeyException {
        // 构造函数负责验证和准备可管理的数据，这种逻辑不需要在getter和setter方法中
    }
    private String getBits(String[] parts) {
        return parts[1];
    }
    private String getComment(String[] parts) {
        // ...
    }
    private String getType(String[] parts) {
        // ...
    }
}

构造函数负责验证和准备可管理的数据，因此这种逻辑不需要在getter和setter方法中。如果几年前向我展示具有公共成员的对象，我可能不会喜欢它们；也许现在我做错了什么，但我正在进行实验，到目前为止还可以。

此外，您需要考虑您的类是否设计为可扩展的（因此，预见未来是要求的一部分），以及您是否希望您的对象是不可变的。只有使用getter和setter方法才能做到这些。

如果您的对象必须是不可变的，并且可以避免空构造函数，您只需将成员实例添加为final即可。

不幸的是，我不得不添加IsSerializable（类似于java.io.Serializable）和一个空构造函数，因为这是gwt所要求的。所以，您可能会告诉我“你看？你需要getter和setter方法”。嗯，我不太确定。

实际上，有一些JDBC框架也推广使用公共字段，比如iciql.com。这并不意味着该项目是正确的，但说明有些人正在思考这个问题。

我认为对于getter和setter方法的需要主要是文化问题。

我完全同意。创建所有getter和setter的想法源于一个观点，即你永远不能改变一个类的接口。敏捷开发的观点恰恰相反：你可以改变接口，并且更好地承担更改的成本，而不是发明一堆你不需要的东西。换句话说，YAGNI（You Aren't Gonna Need It）。详细的例子可以参考：https://agiletribe.wordpress.com/2016/03/07/brainless-getters-setters-are-a-waste

我喜欢这个答案，因为我最近自己遇到了getter和setter的讨论...并且对于具有冗余的getter和setter（而且其中许多甚至没有被使用）的代码进行调试和维护是多么糟糕有了相似的想法。赞同Luigi的观点！

POJO（Plain Old Java Object）是指Java类与JavaBeans或任何其他约定的类进行区分的术语。因此，按照定义，POJO不需要做任何事情。

“我一直在阅读《Clean Code》这本书，其中提到类不应该暴露其数据的内部状态，只应该暴露其行为。”这被称为封装原则，也是一个很好的原则。

对于一个非常简单和愚蠢的Java Bean，暴露其内部状态并提供getter和setter方法，是否值得将它们删除并将私有成员变量设置为公共的？这是一种可选的方法。有些项目可能禁止使用这种方法，而其他项目可能鼓励使用这种方法。个人而言，我更倾向于在某种程度上已经封装的类上使用这种方法，比如它们是包级私有的。

有人认为，某一天你的类可能会有额外的要求，而改变“API”将是不可能的。这与YAGNI原则相悖，并且很少会成为事实，即使是这样，它的成本也远远低于添加许多没有任何功能的方法。

然而，情况并非总是如此，如果你不使用访问器方法，你应该考虑一下如果以后需要更改会对项目产生什么影响。在所有地方使用访问器方法意味着您永远不需要担心这个问题。

总之，如果你确信访问器方法是无意义的，并且将来添加它们不会成为问题，我会说你应该根据自己的判断来决定。然而，如果你不确定以后是否可能成为问题，或者你不想担心这个问题，就使用访问器方法吧。

不同人对于是否需要在POJO中使用getter和setter方法有不同的观点。这取决于对象的生命周期和其是否需要对外部进行修改。

如果对象仅仅被用作数据结构，只需要以安全的方式（使用final）暴露字段即可。例如，下面是一个使用final字段的Person类的例子：

public class Person {
    public final String firstName;
    public final String lastName;
    
    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

在这个例子中，firstName和lastName字段都是使用final修饰的，这意味着它们在对象创建后不能被修改。因此，不需要为它们提供getter和setter方法。

然而，一些开发人员认为POJO应该提供getter和setter方法，以提供对字段的访问和修改。这样做的好处是，可以在getter和setter方法中添加额外的逻辑，例如验证输入值的有效性。另外，如果将来需要在POJO中添加字段，可以在不破坏现有代码的情况下进行修改。

以下是一个带有getter和setter方法的Person类的例子：

public class Person {
    private String firstName;
    private String lastName;
    
    public String getFirstName() {
        return firstName;
    }
    
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    
    public String getLastName() {
        return lastName;
    }
    
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

在这个例子中，firstName和lastName字段被声明为私有，并通过getter和setter方法提供对它们的访问和修改。

，是否需要在POJO中使用getter和setter方法取决于对象的生命周期和其对外部的暴露程度。如果仅仅需要作为数据结构使用，并且字段不需要对外部进行修改，那么可以只暴露字段而不提供getter和setter方法。但如果希望提供对字段的访问和修改，并且可能需要在将来进行修改或添加额外的逻辑，那么可以提供getter和setter方法。