考虑使用访问器是有充分理由的，因为没有属性继承。请参见下一个示例：

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

输出：

0
0
4

它可以用于延迟加载。假设所讨论的对象存储在数据库中，除非您需要，否则您不想获取它。如果该对象由getter检索，则内部对象可以为空，直到有人请求它，然后您可以在第一次调用getter时获取它。

我在交给我的一个项目中有一个基本页面类，它从几个不同的web服务调用加载一些数据，但这些web服务调用中的数据并不总是用于所有子页面。Web服务具有所有的优点，它开创了“慢”的新定义，因此如果不需要，您不想进行Web服务调用。

我从公共字段转到getter，现在getter检查缓存，如果缓存不存在，则调用web服务。因此，通过一点包装，许多web服务调用被阻止了。

因此，getter使我不必在每个子页面上找出我需要什么。如果我需要它，我打电话给吸气器，如果我还没有，它会帮我找到它。

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

编辑：我回答这个问题是因为有很多学习编程的人都在问这个问题，大多数答案在技术上都很好，但如果你是新手，就不那么容易理解了。我们都是新手，所以我想我会尝试一个更适合新手的答案。

两个主要的是多态性和验证。即使它只是一个愚蠢的数据结构。

假设我们有一个简单的类：

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

这是一个非常简单的类，它包含有多少液体，容量是多少（毫升）。

当我这样做时会发生什么：

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

嗯，你不会指望这会奏效，对吧？你想进行某种理智检查。更糟糕的是，如果我从未指定最大容量呢？哦，亲爱的，我们有问题。

但也有另一个问题。如果瓶子只是一种容器呢？如果我们有几个容器，所有容器都有容量和液体量，会怎么样？如果我们能做一个接口，我们就可以让程序的其他部分接受这个接口，而瓶子、偷工减料和各种各样的东西就可以互换使用了。那不是更好吗？由于接口需要方法，这也是一件好事。

我们最终会得到这样的结果：

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

太棒了现在我们把瓶子换成这个：

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

我将把BottleOverflowException的定义作为练习留给读者。

现在请注意这是多么的强大。我们现在可以通过接受LiquidContainer而不是Bottle来处理代码中的任何类型的容器。这些瓶子是如何处理这种东西的呢。您可以有在磁盘发生变化时将其状态写入磁盘的瓶子，也可以有保存在SQL数据库或GNU知道其他内容的瓶子。

所有这些都可以有不同的方法来处理各种各样的百日咳。瓶子只是检查，如果它溢出，就会抛出RuntimeException。但这可能是错误的做法。（关于错误处理有一个很有用的讨论，但我有意保持非常简单。评论中的人可能会指出这种简单方法的缺点。；）

是的，我们似乎从一个非常简单的想法迅速得到更好的答案。

请注意，您不能更改瓶子的容量。它现在被镶嵌在石头上。您可以通过将int声明为final来实现这一点。但如果这是一个列表，你可以清空它，添加新的东西，等等。你不能限制接触内脏的权限。

还有第三件事不是每个人都解决过：getter和setter使用方法调用。这意味着它们看起来像其他地方的正常方法。DTO和其他东西没有奇怪的特定语法，而是到处都有相同的语法。

OO设计的基本原则之一：封装！

它给您带来了许多好处，其中之一是您可以在幕后更改getter/setter的实现，但只要数据类型保持不变，任何具有该值的使用者都将继续工作。

我知道现在有点晚了，但我想有些人对表演感兴趣。

我做了一个性能测试。我写了一个类“NumberHolder”，它包含一个整数。您可以使用getter方法读取该IntegeranInstance.getNumber（）或通过使用anInstance.number直接访问数字。我的程序通过两种方式读取数字1000000000次。该过程重复五次，并打印时间。我得到了以下结果：

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

（时间1是直接方式，时间2是吸气方式）

你看，吸气器（几乎）总是快一点。然后我尝试了不同次数的循环。我用了1000万和10万，而不是100万。结果：

1000万次循环：

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

1000万次循环，时间几乎相同。以下是10万（10万）个循环：

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

同样，对于不同数量的循环，getter比常规方法快一点。我希望这对你有所帮助。

DataStructure和Object之间存在差异。

数据结构应该暴露其内部而不是行为。

一个物体不应该暴露其内部，但它应该暴露其行为，这也被称为德米特定律

大多数DTO被认为是一种数据结构，而不是对象。他们应该只公开自己的数据，而不是行为。在数据结构中设置Setter/Getter将暴露行为，而不是其中的数据。这进一步增加了违反德梅特定律的可能性。

鲍勃叔叔在他的《干净的代码》一书中解释了得墨忒耳定律。

有一种著名的启发式方法叫做得墨忒耳定律，它说：模块不应该知道它的对象的内部结构操纵。正如我们在上一节中看到的，对象隐藏其数据并暴露操作。这意味着对象不应公开其通过访问器的内部结构，因为这样做是为了暴露，而不是隐藏其内部结构。更准确地说，德米特定律说C类的方法f应仅调用以下方法：Cf创建的对象作为参数传递给f的对象保存在C的实例变量中的对象该方法不应在任何允许的函数返回的对象上调用方法。换句话说，与朋友交谈，而不是与陌生人交谈。

因此，根据这一点，LoD违规的例子是：

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

在这里，函数应该调用它的直接朋友的方法，这里是ctxt，它不应该调用它直接朋友的朋友的方法。但该规则不适用于数据结构。所以在这里，如果ctxt、option、scratchDir是数据结构，那么为什么要用一些行为包装它们的内部数据，并违反LoD。

相反，我们可以这样做。

final String outputDir = ctxt.options.scratchDir.absolutePath;

这满足了我们的需求，甚至没有违反LoD。

灵感来源于Robert C.Martin（Bob叔叔）的“清洁代码”