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

Question

使用 getter 和 setter（仅获取和设置）比简单地使用这些变量的公共字段有什么优势？

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

public String foo;

比：

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

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

Answer 1

实际上有许多充分的理由考虑使用访问器而不是直接公开类的字段 - 不仅仅是封装的论据和使未来的更改更容易。

以下是我所知道的一些原因：

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

Answer 2

因为 2 周（月、年）后，当您意识到您的 setter 需要做的不仅仅是设置值之外，您还会意识到该属性已在 238 个其他类中直接使用： -)

Answer 3

公共字段并不比除了返回字段并为其赋值之外不执行任何操作的 getter/setter 对差。首先，很明显（在大多数语言中）不存在功能差异。任何差异都必须存在于其他因素中，例如可维护性或可读性。

getter/setter 对的一个经常提到的优点却不是。有人声称您可以更改实现，并且您的客户端不必重新编译。据说，setter 可以让您稍后添加验证等功能，而您的客户甚至不需要知道它。然而，向 setter 添加验证是对其先决条件的更改，违反了之前的合同，这很简单，“您可以在此处放置任何内容，并且稍后可以获得相同的内容来自吸气剂”。

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

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

同样的论点也适用于这些传递 getter/setter 对的其他假定优点：如果您稍后决定更改正在设置的值，那么您就违反了合同。如果您以超出一些无害的修改（例如日志记录或其他不可观察的行为）的方式重写派生类中的默认功能，那么您就违反了基类的约定。这违反了里氏可替代性原则，该原则被视为面向对象的原则之一。

如果一个类的每个字段都有这些愚蠢的 getter 和 setter，那么它就是一个没有任何不变量的类，没有契约。这真的是面向对象设计吗？如果类只有这些 getter 和 setter，那么它只是一个愚蠢的数据持有者，而愚蠢的数据持有者应该看起来像愚蠢的数据持有者：

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

向这样的类添加传递 getter/setter 对不会增加任何价值。其他类应该提供有意义的操作，而不仅仅是字段已经提供的操作。这就是定义和维护有用的不变量的方式。

客户端：“我可以用此类的对象做什么？”
设计师：“您可以读取和写入多个变量。”
客户：“哦...很酷，我猜？”

使用 getter 和 setter 是有原因的，但如果这些原因不存在，那么以虚假封装神的名义创建 getter/setter 对并不是一件好事。创建 getter 或 setter 的正当理由包括经常提到的稍后可以进行的潜在更改，例如验证或不同的内部表示。或者也许该值应该可由客户端读取但不可写入（例如，读取字典的大小），因此简单的 getter 是一个不错的选择。但当你做出选择时，这些理由就应该存在，而不仅仅是你以后可能想要的东西。这是 YAGNI（你不需要它）的一个实例。

Answer 4

很多人都在谈论 getter 和 setter 的优点，但我想唱反调。现在我正在调试一个非常大的程序，程序员决定将所有内容都设置为 getter 和 setter。这看起来不错，但它是逆向工程的噩梦。

假设您正在查看数百行代码，并且发现了这一点：

person.name = "Joe";

这是一段非常简单的代码，直到您意识到它是一个 setter。现在，您跟踪该 setter 并发现它还设置了 person.firstName、person.lastName、person.isHuman、person.hasReallyCommonFirstName，并调用 person.update()，该更新将查询发送到数据库等。哦，那就是发生内存泄漏的地方。

乍一看就理解本地代码是良好可读性的一个重要属性，但 getter 和 setter 往往会破坏这一属性。这就是为什么我尽可能避免使用它们，并在使用它们时尽量减少它们的作用。

Answer 5

在纯粹的面向对象世界中，getter 和 setter 是一种可怕的反模式。阅读这篇文章：Getters/Setters。邪恶的。期间。简而言之，他们鼓励程序员将对象视为数据结构，而这种类型的思维是纯粹的过程性（就像 COBOL 或 C 中的那样）。在面向对象的语言中，没有数据结构，只有公开行为的对象（不是属性/属性！）

您可以在 优雅对象（我关于面向对象编程的书）。

Answer 6

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

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

现在，如果您代码中的所有位置都在使用公共字段，然后您意识到需要上述要求，该怎么办？享受寻找公共字段的每一个用法的乐趣，而不是仅仅修改你的设置器。

我的 2 美分:)

Answer 7

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

例如，如果 foo 是公共的，我可以轻松地将其设置为 null，然后其他人可以尝试调用该对象的方法。但它已经不在那里了！使用 setFoo 方法，我可以确保 foo 永远不会设置为 null。

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

Answer 8

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

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

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

Answer 9

取决于您的语言。您已将其标记为“面向对象”而不是“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)

Answer 10

编辑：我回答这个问题是因为有很多学习编程的人问这个问题，而且大多数答案在技术上都非常有能力，但如果你是新手，它们就不那么容易理解了。我们都是新手，所以我想我应该尝试一个对新手更友好的答案。

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

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

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 implements 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 知道的其他内容上。

所有这些都可以有不同的方式来处理各种问题。 Bottle 只是检查，如果溢出就会抛出 RuntimeException。但这可能是错误的做法。
（关于错误处理有一个有用的讨论，但我故意在这里保持非常简单。评论中的人可能会指出这种简单方法的缺陷。;））

是的，看起来我们走了从一个非常简单的想法到快速获得更好的答案。

另请注意，您无法更改瓶子的容量。现在它已经板上钉钉了。您可以通过将 int 声明为 Final 来实现此目的。但如果这是一个列表，您可以清空它，向其中添加新内容，等等。你不能限制接触内脏的机会。

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

Answer 11

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

Answer 12

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

我做了一些性能测试。我编写了一个“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 是吸气剂）

你看，吸气剂（几乎）总是快一点。然后我尝试了不同数量的周期。我没有使用 100 万，而是使用了 1000 万和 10 万。
结果：

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

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

Answer 13

除非当前交付需要，否则不要使用 getter setter 即不要过多考虑将来会发生什么，如果有任何事情需要更改，那么它是大多数生产应用程序、系统中的更改请求。

想得简单、容易，需要时增加复杂性。

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

我编写了一个庞大的系统，没有 getter setter，仅使用访问修饰符和一些方法来验证执行业务逻辑。如果你绝对需要的话。使用任何东西。

Answer 14

对于 Java 的情况，我花了相当长的时间思考这个问题，我相信真正的原因是：

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

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

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

Answer 15

我们使用 getter 和 setter：

• 为了
• 在编程的后期阶段执行验证的

可重用性，getter 和 setter 方法是访问私有类成员的公共接口。

---

封装的口号

封装的口号是使字段私有，方法公开。

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

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

getter 和 setter 方法不会添加新功能，我们可以改变主意，稍后再回来改进该方法

• ；
• 更安全；而且
• 更快。

---

任何可以使用值的地方，都可以添加返回该值的方法。而不是：

int x = 1000 - 500

使用

int x = 1000 - class_name.getValue();

---

通俗地说

假设我们需要存储这个的详细信息人。此Person具有字段name、age和sex。执行此操作涉及为 name、age 和 sex 创建方法。现在，如果我们需要创建另一个人，则需要重新创建 name、age、sex 方法。

我们可以创建一个带有 getter 和 setter 方法的 bean class(Person)，而不是这样做。因此，明天每当我们需要添加一个新人时，我们都可以创建这个 Bean class(Person class) 的对象（见图）。这样我们就重用了bean类的字段和方法，这样就好多了。

Answer 16

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

我在一个交给我的项目中有一个基页面类，它从几个不同的 Web 服务调用加载一些数据，但这些 Web 服务调用中的数据并不总是在所有子页面中使用。 Web 服务虽然有很多好处，但它开创了“慢”的新定义，因此如果不需要，您不会希望进行 Web 服务调用。

我从公共字段转移到 getters，现在 getters 检查缓存，如果不存在则调用 Web 服务。因此，通过一些包装，可以阻止大量 Web 服务调用。

因此，吸气剂使我无需在每个子页面上尝试找出我需要什么。如果我需要它，我会调用 getter，如果我还没有它，它就会为我找到它。

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

Answer 17

到目前为止，我在答案中错过了一个方面，即访问规范：

• 对于成员，您只有一个用于设置和获取的访问规范，
• 对于 setter 和 getter，您可以对其进行微调并单独定义

Answer 18

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

在支持“真实”属性的语言（Python、Ruby，也许是 Smalltalk？）中，没有必要使用 get/set 方法。

Answer 19

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

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

Answer 20

您应该在以下情况下使用 getter 和 setter：

• 您正在处理概念上属于属性的内容，但是：
  • 您的语言没有属性（或某种类似的机制，如 Tcl 的变量跟踪），或者
  • 您的语言的属性支持不足以满足此用例，或者
  • 您的语言（或者有时是您的框架）的惯用约定鼓励此用例使用 getter 或 setter。

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

---

从面向对象理论的角度来看，getter 和 setter 是没有用的。类的接口是它的功能，而不是它的状态。 （如果没有，则说明您编写了错误的类。）在非常简单的情况下，类所做的只是例如表示直角坐标中的点，*属性是接口的一部分； getters 和 setters 只会让这一点变得模糊。但除了非常简单的情况外，属性、getter 和 setter 都不是接口的一部分。

换句话说：如果您认为您的类的使用者甚至不应该知道您有 spam 属性，更不用说能够随意更改它，那么给他们一个 set_spam 方法是您最不想做的事情。

_{* 即使对于这个简单的类，您也可能不一定希望允许设置 x 和 y 值。如果这真的是一个类，它不应该有诸如 translate、rotate 等方法吗？如果它只是一个类，因为您的语言没有记录/结构/命名元组，那么这实际上并不是面向对象的问题......}

---

但是没有人做过一般的面向对象设计。他们用特定的语言进行设计和实现。在某些语言中，getter 和 setter 并非毫无用处。

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

即使您的语言确实具有属性，也可能存在不足或不合适的情况。例如，如果您希望允许子类控制属性的语义，则在没有动态访问的语言中，子类不能用计算属性替换属性。

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

此外，遵循您所使用的语言（或框架）的习惯用法也很重要。如果您用 C# 编写漂亮的 Ruby 风格代码，那么除您之外的任何有经验的 C# 开发人员都将难以阅读它，这很糟糕。有些语言比其他语言在约定方面拥有更强大的文化。Java 和 Python 在惯用的 getter 方面处于两端，但恰好拥有两种最强大的文化，这可能并非巧合。

除了人类读者之外，还会有一些库和工具希望您遵守约定，如果您不遵守约定，就会让您的生活变得更加困难。将 Interface Builder 小部件与 ObjC 属性之外的任何内容挂钩，或者使用某些没有 getter 的 Java 模拟库，只会让您的生活变得更加困难。如果这些工具对你很重要，就不要与它们对抗。

Answer 21

从面向对象设计的角度来看，这两种选择都可能削弱类的封装性，从而损害代码的维护。如需讨论，您可以查看这篇优秀的文章：http://tropicalprogrammer.com/?p=23

Answer 22

代码不断发展。 private 非常适合您需要数据成员保护。最终，所有的类都应该是某种“小程序”，它们有一个定义良好的接口你不能简单地修改其内部。

也就是说，软件开发并不是要设定类的最终版本，就好像您在第一次尝试时按下某个铸铁雕像一样。当您使用它时，代码更像是粘土。 随着您开发它并了解有关您正在解决的问题领域的更多信息，它会不断发展。在开发过程中，类之间可能会发生超出应有的交互（您计划排除的依赖关系）、合并在一起或分开。所以我认为争论归结为人们不想虔诚地写

int getVar() const { return var ; }

所以你有：

doSomething( obj->getVar() ) ;

而不是

doSomething( obj->var ) ;

不仅是 getVar() 视觉上嘈杂，它给人一种错觉 gettingVar() 在某种程度上是一个比实际情况更复杂的过程。如果您的类有一个 passthru setter，那么您（作为类编写者）如何看待 var 的神圣性对于您的类的用户来说尤其令人困惑 - 那么看起来您正在将这些门设置为“保护”您坚持认为有价值的东西（var 的神圣性），但即使您承认 var 的保护对于任何人来说都没有多大价值in 和 set var 为他们想要的任何值，而你甚至不需要偷看他们在做什么。

因此，我的编程如下（假设采用“敏捷”类型的方法 - 即，当我编写代码时不知道确切它将做什么/没有时间或经验来规划精心设计的瀑布式界面set):

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

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

3）给出了完全充实的类，并且对其内部有严格的规则（即它们确切地知道自己在做什么，并且你不应该用它的内部来“操”（技术术语）） class 名称、默认私有成员以及仅允许选择的少数成员为public。

我发现，在类演化的早期阶段，当大量数据成员被迁移、移动等时，这种方法可以让我避免坐在那儿认真地编写 getter/setter。

Answer 23

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

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

Answer 24

Getters 和 setters 用于实现面向对象编程的两个基本方面，它们是：

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();
    }
 }

这里 Full Name 的实现细节是与公共属性不同，对用户隐藏并且用户无法直接访问。

Answer 25

数据结构和对象之间存在差异。

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

对象不应该暴露其内部结构，但应该暴露其行为，这也称为得墨忒耳法则

大多数 DTO 被认为更多是一种数据结构而不是对象。他们应该只暴露他们的数据而不是行为。在 DataStructure 中使用 Setter/Getter 将暴露行为而不是其中的数据。这进一步增加了违反德墨忒尔法则的机会。

鲍勃叔叔在他的《干净的代码》一书中解释了德米特法则。

有一个著名的启发式，称为德米特法则，它说：
模块不应该知道它的对象的内部结构
操纵。正如我们在上一节中看到的，对象隐藏其数据
并公开操作。这意味着一个对象不应该暴露它的
通过访问器的内部结构，因为这样做就是暴露，
而不是隐藏其内部结构。

更准确地说，德墨忒尔定律说 C 类的方法 f
应该只调用这些方法：

• C
• 由 f 创建的对象
• 作为参数传递给 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（鲍勃叔叔）的《干净代码》的启发

Answer 26

如果您不需要任何验证，甚至不需要维护状态，即一个属性依赖于另一个属性，那么我们需要在一个属性发生更改时维护状态。您可以通过公开字段而不使用 getter 和 setter 来保持简单。

我认为，随着程序的增长，面向对象编程会让事情变得复杂，这对开发人员来说扩展成为噩梦。

一个简单的例子；我们从 xml 生成 C++ 标头。标头包含不需要任何验证的简单字段。但仍然像 OOPS 访问器一样，我们按如下方式生成它们。

const Filed& getfield() const
Field& getField() 
void setfield(const Field& field){...} 

这是非常冗长的并且不是必需的。一个简单的

struct 
{
   Field field;
};

就足够了并且可读。
函数式编程没有数据隐藏的概念，它们甚至不需要它，因为它们不会改变数据。

Answer 27

此外，这是为了让你的班级“面向未来”。特别是，从字段更改为属性是 ABI 破坏，因此如果您后来决定需要更多逻辑而不仅仅是“设置/获取字段”，那么您需要破坏 ABI，这当然会给任何事情带来问题else 已经针对您的班级进行了编译。

Answer 28

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

Answer 29

getter/setter 的一个相对现代的优点是可以更轻松地在标记（索引）代码编辑器中浏览代码。例如，如果您想查看谁设置了成员，您可以打开设置器的调用层次结构。

另一方面，如果成员是公共成员，则这些工具无法过滤对该成员的读/写访问权限。因此，您必须费力地使用该成员的所有用途。

Answer 30

来自数据隐藏的获取器和设置器。数据隐藏意味着我们
向外部人员隐藏数据或外部人员/事物无法访问
我们的数据。这是 OOP 中的一个有用的功能。

举个例子：

如果您创建一个公共变量，您可以访问该变量并在任何地方（任何类）更改值。但是，如果您创建为私有变量，则除了声明的类之外，该变量无法在任何类中查看/访问。

public 和 private 是访问修饰符。

那么我们如何才能在外部访问该变量：

这就是 getters 和 setters 的来源。您可以将变量声明为私有，然后您可以为该变量实现 getter 和 setter。

示例（Java）：

private String name;

public String getName(){
   return this.name;
}

public void setName(String name){
   this.name= name;
}

优点：

当任何人想要访问或更改/设置balance变量的值时，他/她必须拥有许可。

//assume we have person1 object
//to give permission to check balance
person1.getName()

//to give permission to set balance
person1.setName()

您也可以在构造函数中设置值，但稍后当您需要时
要更新/更改值，您必须实现 setter 方法。