Java 不推荐的方法，而不是不推荐的方法

一些java类需要具有带有公共getter和setter的私有属性才能正常工作。例如，JSFbean和JPA实体需要它们。如果没有这些库，可能有一些属性不应该有任何getter，当然也不应该有setter。此外，自定义代码通常不鼓励使用空构造函数。比如说

@Entity
public class MyEntity implements Serializable {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    public MyEntity() {}

    public Long getId() {
        return this.id;
    }

    public void setId(Long id) {
        this.id = id;
    }
}

在这个类中，方法setId不应该被手动代码调用。但是，该方法没有被弃用，因此@deprecated注释将是错误的

---

除了@Deprecated之外，还有其他方法告诉您不应该使用方法吗？

您可以使用该具体类支持的接口来隐藏getter和setter。这也会鼓励说，不要问，因为在接口上没有任何getter可以使用。构造函数的用法也可以隐藏在工厂中。

JPA实体不需要公共getter和setter。使用反射设置值（至少在使用EclipseLink或Hibernate时，您可能正在使用）

在这个特殊的例子中，你可以简单地把二传手排除在外，我已经养成了习惯，从来没有遇到过问题注意：当涉及属性和getter/setter时，请坚持Java命名约定。一些库/框架（imo错误地）依赖于此

至于这个问题的全局概念，我很惊讶我没有看到包含文档的建议。文档已经、现在和将来都可能是您与代码用户的最佳沟通方式

/**
 * WARNING! DO NOT USE THIS UNLESS YOU ARE GOD!
 * This will probably break stuff unless...
 * ....
 */
public void doEvilHackishThings()
{
    // Stuff happens here.
}

---

如果您正确地记录了代码，开发人员就会知道他们什么时候可能会破坏代码。确保你没有使用巫毒代码等。好的文档详细描述了它的作用和作用方式。任何头脑正常的开发人员都不会在不理解示例方法的邪恶原因的情况下使用它。

这个问题与JSF和JPA无关。尽管如此，这些框架还是值得一提的。你的例子不是很好。在这种情况下，您为什么不鼓励使用setter？它是一个实体对象，可以潜在地存储各种数据组合，当然您希望能够设置它的值。您不希望在初始化时设置它的唯一标识符后更改它。几乎每个实体都有一个接口？这并不罕见。EMF也这样做。