为什么要使用getter和setter / accessor？

使用仅获取和设置的getter和setter而不是仅对这些变量使用公共字段的优点是什么？

如果getter和setter所做的不只是简单的get / set，我可以很快地弄清楚这一点，但是我不清楚如何做到这一点：

public String foo;

比以下任何方面都更糟糕：

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

而前者需要更少的样板代码。

实际上，有很多充分的理由考虑使用访问器，而不是直接公开类的字段-除了封装的论点之外，并使将来的更改更容易。

这是我知道的一些原因：

• 封装与获取或设置属性相关的行为-这样可以在以后更轻松地添加其他功能（例如验证）。
• 隐藏属性的内部表示形式，同时使用替代表示形式公开属性。
• 将公共接口与更改隔离开来-在实现更改的同时允许公共接口保持不变，而不会影响现有的使用者。
• 控制属性的生存期和内存管理（处置）语义-在非托管内存环境（如C ++或Objective-C）中尤其重要。
• 为属性何时在运行时更改提供调试拦截点-在某些语言中，如果没有属性，则在何时何地更改为特定值的调试非常困难。
• 与旨在针对属性获取程序/设置程序进行操作的库之间的改进的互操作性-我想到了模拟，序列化和WPF。
• 通过覆盖getter / setter方法，允许继承者更改属性行为的语义并公开该属性。
• 允许将getter / setter作为lambda表达式而不是值传递。
• getter和setter可以允许不同的访问级别-例如，get可以是公共的，但是set可以受到保护。

因为从2现在周（月，年），当你意识到你的二传手需要做更多的比刚才设置的值，你也会意识到，财产已经在其他238类直接使用:-)

一个公共领域并不比没有返回或分配给它做任何事情的getter / setter对更糟糕。首先，很明显（在大多数语言中）没有功能上的区别。任何差异都必须在其他因素上，例如可维护性或可读性。

并非经常提到吸气剂/设置剂对的优点。有人声称您可以更改实现，而不必重新编译客户。据说，setter可以让您稍后添加诸如验证之类的功能，而您的客户甚至不需要了解它。但是，向验证器添加验证是对其先决条件的更改，这是对先前合同的违反，这很简单，就是“您可以在此处放置任何东西，以后可以从获取器中获得相同的东西”。

因此，既然您违反了合同，那么就应该而不是避免更改代码库中的每个文件。如果您避免这种情况，您将假设所有代码都假定这些方法的约定是不同的。

如果这不应该是合同，则该接口允许客户端将对象置于无效状态。这与封装完全相反。如果从一开始就无法将该字段真正设置为任何值，那么为什么从一开始就不进行验证？

同样的论点也适用于这些传递性getter / setter对的其他假定优点：如果您以后决定更改所设置的值，则您正在违反合同。如果您以某种无害的修改（例如日志记录或其他不可观察的行为）的方式覆盖了派生类中的默认功能，则您正在破坏基类的契约。这违反了《里斯科夫可替代性原则》，后者被视为面向对象的宗旨之一。

如果一个类的每个字段都具有这些愚蠢的获取器和设置器，则该类将没有任何不变式，也没有合同。那真的是面向对象的设计吗？如果班上所有的人都是那些getter和setter，那只是一个哑数据持有人，而哑数据持有人应该看起来像哑数据持有人：

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

在此类中添加传递式获取/设置对不会增加任何价值。其他类应该提供有意义的操作，而不仅仅是字段已经提供的操作。这样便可以定义和维护有用的不变量。

客户：“我可以用这个类的对象做什么？”
设计器：“您可以读写几个变量。”
客户：“哦，太酷了，我猜是吗？”

有使用getter和setter的理由，但如果不存在这些理由，以假封装之神的名义创建getter / setter对并不是一件好事。进行getter或setter的有效理由包括经常提到的事情，这些事情是您以后可以进行的潜在更改，例如验证或其他内部表示形式。或者，该值应该对客户端可读，但不可写（例如，读取字典的大小），因此，简单的getter方法是不错的选择。但是，当您做出选择时，这些原因应该存在，而不仅仅是您以后可能想要的潜在原因。这是YAGNI的一个实例（您将不需要它）。

很多人都在谈论吸气剂和吸气剂的优点，但我想扮演魔鬼的拥护者。现在，我正在调试一个非常大的程序，程序员在该程序中决定使所有东西都变得吸气和用气。这看起来不错，但这是反向工程的噩梦。

假设您正在浏览数百行代码，就会发现：

person.name = "Joe";

这是一段漂亮的代码，直到您意识到它的设置者。现在，您遵循该设置器，发现它还设置了person.firstName，person.lastName，person.isHuman，person.hasReallyCommonFirstName，并调用person.update（），这会将查询发送到数据库，等等。哦，那是发生内存泄漏的位置。

乍看之下，了解本地代码是具有良好可读性的重要属性，而吸气剂和装料器往往会破坏这种特性。这就是为什么我会尽量避免使用它们，并尽量减少使用它们时的行为。

在纯粹的面向对象的世界中，吸气剂和吸气剂是一种可怕的反模式。阅读本文：Getters / Setters。邪恶。期间。简而言之，他们鼓励程序员考虑数据结构中的对象，而这种类型的思考是纯粹的过程性的（例如在COBOL或C中）。在面向对象的语言中，没有数据结构，只有暴露行为的对象（没有属性/属性！）

您可以在Elegant Objects的 3.5节（我的有关面向对象编程的书）中找到有关它们的更多信息。

原因有很多。我最喜欢的一种是当您需要更改行为或调节可以在变量上设置的内容时。例如，假设您有一个setSpeed（int speed）方法。但是，您希望只能将最大速度设置为100。您可以执行以下操作：

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

现在，如果您在代码中的任何地方都使用公共字段，然后又意识到需要上述要求怎么办？有趣地寻找公共领域的每一种用法，而不仅仅是修改您的二传手。

我的2美分:)

访问器和更改器的优点之一是可以执行验证。

例如，如果foo是公共的，我可以轻松地将其设置为null，然后其他人可以尝试在对象上调用方法。但是现在不存在了！通过一种setFoo方法，我可以确保foo永远不会将其设置为null。

访问器和更改器也允许封装-如果不希望在设置值后看到该值（也许是在构造函数中设置了该值，然后供方法使用，但决不能更改），那么任何人都不会看到它。但是，如果您可以允许其他类查看或更改它，则可以提供适当的访问器和/或更改器。

取决于您的语言。您已将此标记为“面向对象”而不是“ Java”，因此我想指出ChssPly76的答案取决于语言。例如，在Python中，没有理由使用getter和setter。如果需要更改行为，则可以使用属性，该属性将getter和setter封装在基本属性访问周围。像这样：

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

好吧，我只是想补充一点，即使有时候它们对于变量/对象的封装和安全性是必需的，如果我们想编写一个真正的面向对象程序，那么我们就需要停止过度使用这些访问器，因为有时我们依赖很多何时不需要它们，这几乎与我们将变量公开一样。

谢谢，这确实澄清了我的想法。现在（几乎）有10个（几乎）充分的理由不使用getter和setter：

1. 当您意识到需要做的不仅仅是设置和获取值时，您可以将字段设置为私有，这将立即告诉您直接访问该字段的位置。
   
2. 您在那里执行的任何验证都只能是上下文无关的，实际上很少有这种验证。
   
3. 您可以更改设置的值-这是绝对的噩梦，当呼叫者向您传递一个他们[震惊的恐怖]希望您原样存储的值时，这绝对是一场噩梦。
   
4. 您可以隐藏内部表示-太棒了，因此您要确保所有这些操作都是对称的，对吗？
   
5. 您已经将公共接口与工作表下的更改隔离开来-如果您正在设计接口，并且不确定直接访问某些对象是否可以，那么您应该继续进行设计。
   
6. 一些库期望这样做，但不是很多-反射，序列化，模拟对象都可以在公共字段中正常工作。
   
7. 继承此类，您可以覆盖默认功能-换句话说，您不仅可以隐藏实现，而且可以使实现不一致，从而使调用者真正困惑。
   

我要离开的最后三个（N / A或D / C）...

我知道有些晚了，但我认为有些人对性能感兴趣。

我做了一些性能测试。我写了一个“ NumberHolder”类，它拥有一个整数。您可以使用getter方法读取该Integer值，也可以使用 anInstance.getNumber()直接访问该数字anInstance.number。我的程序通过两种方式读取该数字1,000,000,000次。该过程重复五次，并打印时间。我得到以下结果：

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万。结果：

一千万个周期：

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

一千万次循环，时间几乎相同。以下是十万（十万）个周期：

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

同样，在不同的循环次数下，吸气剂比常规方法要快一点。希望这对您有所帮助。

除非当前交付需要，否则不要使用getters setter，例如，对于大多数生产应用程序，系统中的更改请求，如果有什么要更改的内容，请不要考虑太多。

简单，轻松地思考，并在需要时增加复杂性。

我不会利用深奥的技术知识的企业主的无知，只是因为我认为这是正确的，或者我喜欢这种方法。

我编写了庞大的系统，而没有使用访问修饰符和一些方法来验证n执行biz逻辑的getters setter。如果您绝对需要。使用任何东西。

我们使用getter和setter方法：

• 为了可重用
• 在以后的编程阶段执行验证

Getter和setter方法是访问私有类成员的公共接口。

封装口头禅

封装的原则是使字段私有和方法公开。

Getter方法： 我们可以访问私有变量。

设置方法： 我们可以修改私有字段。

即使getter和setter方法未添加新功能，我们也可以稍后改变主意以使该方法

• 更好;
• 更安全 和
• 快点。

在可以使用值的任何地方，都可以添加返回该值的方法。代替：

int x = 1000 - 500

采用

int x = 1000 - class_name.getValue();

用外行的话

假设我们需要存储this的细节Person。这Person有田name，age和sex。这样做涉及到创建方法name，age和sex。现在，如果我们需要建立另外一个人，有必要创造的方法name，age，sex从头再来。

除了这样做，我们还可以class(Person)使用getter和setter方法创建一个bean 。因此，明天我们class(Person class)只要有需要添加新人员时，就可以创建该Bean的对象（参见图）。因此，我们正在重用bean类的字段和方法，这要好得多。

我花了相当长的时间思考Java案例，我相信真正的原因是：

1. 代码到接口，而不是实现
2. 接口仅指定方法，不指定字段

换句话说，在接口中指定字段的唯一方法是提供一种写入新值的方法和一种读取当前值的方法。

这些方法是臭名昭著的getter和setter。

它对于延迟加载很有用。假设有问题的对象存储在数据库中，除非您需要，否则您不想获取它。如果该对象是由吸气剂检索的，则内部对象可以为null，直到有人要求它为止，然后您可以在第一次调用该吸气剂时获取它。

我在一个交付给我的项目中有一个基页类，该基类从几个不同的Web服务调用中加载一些数据，但是这些Web服务调用中的数据并不总是在所有子页面中都使用。Web服务具有所有优点，它们开创了“慢速”的新定义，因此您不必调用Web服务。

我从公共领域转移到吸气剂，现在吸气剂检查缓存，如果不存在，请调用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();
}

大！现在我们将Bottle更改为：

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和内容上使用怪异的特定语法，而到处都有相同的东西。

在不支持“属性”（C ++，Java）或在将字段更改为属性（C＃）时需要重新编译客户端的语言中，使用get / set方法更容易修改。例如，将验证逻辑添加到setFoo方法将不需要更改类的公共接口。

在支持“真实”属性的语言（Python，Ruby，也许是Smalltalk？）中，没有任何获取/设置方法的意义。

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

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

在以下情况下，应使用getter和setter方法：

• 您正在处理的东西从概念上讲是一个属性，但是：
  • 您的语言没有属性（或某些类似的机制，例如Tcl的变量跟踪），或
  • 您的语言的财产支持不足以解决此用例，或者
  • 您的语言（或有时是您的框架）的惯用惯例会鼓励这种使用案例的使用者或使用者。

因此，这很少是一般的面向对象问题。这是一个特定于语言的问题，针对不同的语言（和不同的用例）有不同的答案。

从面向对象理论的角度来看，获取器和设置器是无用的。类的接口是它的作用，而不是状态。（如果不是，则您编写的类是错误的。）在非常简单的情况下，类的作用仅仅是，例如用直角坐标表示一个点，*属性是接口的一部分；吸气剂和塞特剂只是使这一点蒙上阴影。但是在非常简单的情况下，属性，getter和setter都不是接口的一部分。

换句话说，如果您认为类的使用者甚至不应该知道您拥有一个spam属性，更不用说随意更改它了，那么给他们提供一个set_spam方法就是您要做的最后一件事。

_{*即使对于那个简单的类，您也不一定要允许设置x和y值。如果这真的是一个类，它不应该有这样的方法translate，rotate等等？如果因为您的语言没有记录/结构/命名元组而只是一门课，那么这实际上不是OO问题。}

但是没有人进行通用的OO设计。他们正在使用特定语言进行设计和实现。在某些语言中，获取器和设置器远非无用。

如果您的语言没有属性，则表示概念上某种属性但实际上经过计算或验证等的唯一方法是通过getter和setter。

即使您的语言确实具有属性，在某些情况下也可能不够用或不合适。例如，如果要允许子类控制属性的语义，则在没有动态访问的语言中，子类不能用计算所得的属性代替属性。

至于“如果以后我想更改实现该怎么办？” 问题（在OP的问题和接受的答案中，用不同的措词重复多次）：如果确实是纯粹的实现更改，并且从属性开始，则可以将其更改为属性，而不会影响界面。当然，除非您的语言不支持。因此，这确实是同样的情况。

同样，遵循您使用的语言（或框架）的习惯用法也很重要。如果您用C＃编写漂亮的Ruby风格的代码，那么除了您之外的任何经验丰富的C＃开发人员都将很难阅读它，这很糟糕。某些语言比其他语言具有更强的习惯文化。Java和Python在习惯用法的获取者方面处于相反的地位，碰巧拥有两种最强的文化，这并非巧合。

除了人类读者之外，还有一些库和工具可以期望您遵守这些约定，如果不遵循这些约定，将会使您的生活更加艰难。将Interface Builder窗口小部件链接到除ObjC属性之外的任何内容，或者使用某些没有getter的Java模拟库，只会使您的生活更加困难。如果这些工具对您很重要，请不要使用它们。

从面向对象的设计角度来看，这两种选择都可能通过削弱类的封装来破坏代码的维护。对于讨论，您可以看一下这篇出色的文章：http : //typicalprogrammer.com/?p=23

Getter和setter方法是访问器方法，这意味着它们通常是更改私有类成员的公共接口。您可以使用getter和setter方法定义属性。即使在类中将getter和setter方法定义为方法，也可以将它们作为属性访问。类之外的那些属性可以具有与类中的属性名称不同的名称。

使用getter和setter方法有一些优点，例如使您能够创建具有可以像属性一样访问的复杂功能的成员的能力。它们还允许您创建只读和只写属性。

尽管getter和setter方法很有用，但您仍应注意不要过度使用它们，因为，除其他问题外，它们在某些情况下会使代码维护更加困难。此外，它们还提供对您的类实现的访问，例如公共成员。OOP实践不鼓励直接访问类中的属性。

在编写类时，总是鼓励您尽可能多地将实例变量设为私有，并相应地添加getter和setter方法。这是因为有时您可能不想让用户更改类中的某些变量。例如，如果您有一个私有的静态方法来跟踪为特定类创建的实例数，则您不希望用户使用代码来修改该计数器。每当调用该变量时，只有构造函数语句应使该变量递增。在这种情况下，您可能会创建一个私有实例变量，并仅允许将getter方法用于计数器变量，这意味着用户只能使用getter方法来检索当前值，而他们将无法设置新值使用setter方法。

代码不断发展。 private非常适合需要数据成员保护的情况。最终，所有类都应该是具有明确定义的接口的“小程序” ，您不能仅仅将它们与。

也就是说，软件开发并不是要设置课程的最终版本，就好像您在第一次尝试时按了一些铸铁雕像一样。使用它时，代码更像黏土。 它随着您的发展而发展，并了解您要解决的问题领域的更多信息。在开发过程中，类可能会相互干扰（您打算排除的依赖性），合并在一起或分裂。因此，我认为辩论归结为那些不想信奉宗教信仰的人

int getVar() const { return var ; }

所以你有了：

doSomething( obj->getVar() ) ;

代替

doSomething( obj->var ) ;

不仅getVar()视觉上嘈杂，而且给人一种错觉，使错觉gettingVar()比实际情况复杂得多。如果您（作为班级作者）如何看待圣贤，var如果班级中有通行证的话，这会让您的班级用户特别困惑-那么看来您是在竖起这些门来“保护”您坚持认为有价值的东西， （的神圣性var），但即使您承认var，任何人只要有能力进来，set var达到他们想要的任何价值而没有您偷看他们正在做的事情。

因此，我按以下方式进行编程（假设采用“敏捷”类型的方法-即，当我编写的代码不完全知道将要做什么/没有时间或经验来计划精心设计的瀑布样式接口集时）：

1）从所有具有数据和行为的基本对象的公共成员开始。这就是为什么在我所有的C ++“示例”代码中，您都会注意到我使用struct而不是class各处使用的原因。

2）当对象的数据成员内部行为变得足够复杂时（例如，它喜欢以std::list某种顺序保留内部行为），将编写访问器类型的函数。因为我是在自己编程，所以我并不总是立即设置成员private，而是在类演变的某个位置将成员“提升”为protected或private。

3）完全充实并且对内部构造有严格规定的类（即，他们确切地知道自己在做什么，并且您不要对其内部进行“操弄”（技术术语））被赋予class名称，默认的私有成员，并且只有少数几个成员被允许成为public。

我发现这种方法使我避免在课堂发展的早期阶段，当许多数据成员被移出，调动等时，避免坐在那里，认真地写getter / setter。

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

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和setter来实现面向对象编程的两个基本方面：

1. 抽象化
2. 封装形式

假设我们有一个Employee类：

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

在这里，全名的实现细节对用户隐藏，与公共属性不同，用户无法直接访问。

（在支持属性的语言中）另一种用法是，setter和getter可以暗示操作是不平凡的。通常，您希望避免在属性中执行任何计算量大的事情。

getters / setters的一个相对较现代的优点是，它使得在标记（索引）代码编辑器中浏览代码更加容易。例如，如果要查看谁设置成员，则可以打开设置器的呼叫层次。

另一方面，如果成员是公共成员，则该工具将无法过滤对该成员的读/写访问。因此，您必须仔细考虑该成员的所有使用情况。

在面向对象的语言中，方法及其访问修饰符声明该对象的接口。在构造函数与访问器和mutator方法之间，开发人员可以控制对对象内部状态的访问。如果仅将变量声明为public，则没有任何方法可以调节该访问。当我们使用设置器时，我们可以限制用户所需的输入。意味着该变量的提要将通过适当的渠道提供，并且该渠道是我们预先定义的。因此，使用二传手更安全。

另外，这是为了“防止将来”您的班级。特别是，从字段更改为属性是ABI的中断，因此，如果您以后决定需要更多的逻辑，而不仅仅是“设置/获取字段”，那么您就需要中断ABI，这当然会为任何问题带来问题。否则已经针对您的班级进行了编译。

我只想提出注释的想法：@getter和@setter。使用@getter，您应该可以obj = class.field，但不能使用class.field = obj。使用@setter，反之亦然。使用@getter和@setter，您应该可以同时做到。通过在运行时不调用琐碎的方法，可以保留封装并减少时间。