为什么要使用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)中尤为重要.
• 为属性在运行时更改时提供调试拦截点 - 在某些语言中调试属性更改为特定值的时间和位置可能非常困难.
• 改进了与旨在针对属性获取器/设置器进行操作的库的互操作性 - 可以想到Mocking,Serialization和WPF.
• 允许继承者通过重写getter/setter方法来更改属性的行为和语义的语义.
• 允许getter/setter作为lambda表达式而不是值传递.
• getter和setter可以允许不同的访问级别 - 例如get可以是公共的,但是set可以受到保护.

Answer 2

由于2周(月,年)从现在开始,当你意识到你的二传手需要做更多的比刚才设置的值,你也意识到,财产已经在其他238类直接使用:-)

Answer 3

公共字段并不比除了返回字段并分配给它之外什么都不做的getter/setter对更差.首先,很明显(在大多数语言中)没有功能差异.任何差异必须与其他因素有关,如可维护性或可读性.

getter/setter对经常提到的优点不是.有这样的说法,您可以更改实施,您的客户不必重新编译.据推测,setters允许您稍后添加验证等功能,而您的客户甚至不需要了解它.然而,向setter添加验证是对其前提条件的改变,违反了之前的合同,这很简单,"你可以把任何东西放在这里,你可以在以后从getter得到同样的东西".

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

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

同样的论证适用于这些传递的getter/setter对的其他假设优势:如果你以后决定更改所设置的值,那么你就违反了合同.如果您覆盖派生类中的默认功能,超出了一些无害的修改(如日志记录或其他不可观察的行为),那么您就违反了基类的约定.这违反了Liskov Substitutability Principle,这被视为OO的原则之一.

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

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

将传递getter/setter对添加到这样的类中不会增加任何值.其他类应该提供有意义的操作,而不仅仅是已经提供的字段的操作.这就是你如何定义和维护有用的不变量.

客户:"我能用这个类的对象做什么？"
设计师:"你可以读写几个变量."
客户:"哦......很酷,我猜？"

有理由使用getter和setter,但如果这些原因不存在,那么以false封装之神的名义制作getter/setter对并不是一件好事.制作getter或setter的有效理由包括经常提到的事情,因为您可以在以后做出可能的更改,例如验证或不同的内部表示.或者值可能是客户端可读但不可写(例如,读取字典的大小),因此简单的getter是一个不错的选择.但是当你做出选择时,这些原因应该存在,而不仅仅是你以后想要的潜在事物.这是YAGNI的一个例子(你不需要它).

Answer 4

很多人都在谈论吸气者和制定者的优点,但我想扮演魔鬼的拥护者.现在我正在调试一个非常大的程序,程序员决定让所有程序都得到吸气剂和制定者.这看起来不错,但它是一个逆向工程的噩梦.

假设您正在查看数百行代码,并且您遇到了这样的问题:

person.name = "Joe";

这是一段非常简单的代码,直到你意识到它是一个二传手.现在,你跟着那个setter,发现它还设置了person.firstName,person.lastName,person.isHuman,person.hasReallyCommonFirstName,并调用了person.update(),它将查询发送到数据库等等.哦,那是你的内存泄漏发生的地方.

乍看之下理解本地代码是一个具有良好可读性的重要特性,即getter和setter往往会破坏.这就是为什么我尽可能地避免使用它们,并尽量减少使用它们时所做的事情.

Answer 5

原因很多.我最喜欢的是当你需要改变行为或规范你可以在变量上设置的内容时.例如,假设您有一个setSpeed(int speed)方法.但是你想要你只能设置100的最大速度.你会做的事情如下:

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

现在如果您的代码中的每个地方都在使用公共字段然后您意识到您需要上述要求呢？尽情享受公共领域的每一次使用,而不仅仅是修改你的二传手.

我2美分:)

Answer 6

在纯粹的面向对象的世界中,getter和setter是一种可怕的反模式.阅读这篇文章:Getters/Setters.邪恶.期间.简而言之,它们鼓励程序员将对象视为数据结构,这种思维方式纯粹是程序性的(如COBOL或C).在面向对象的语言中,没有数据结构,只有暴露行为的对象(不是属性/属性!)

您可以在Elegant Objects的第3.5节(我的关于面向对象编程的书)中找到更多关于它们的信息.

Answer 7

访问器和更改器的一个优点是您可以执行验证.

例如,如果foo是公共的,我可以轻松地将其设置为null,然后其他人可以尝试在对象上调用方法.但它不再存在了!通过一种setFoo方法,我可以确保foo从未设置过null.

访问器和更改器也允许封装 - 如果您不应该在设置后看到值(可能是在构造函数中设置然后由方法使用,但从不应该更改),任何人都不会看到它.但是,如果您可以允许其他类查看或更改它,您可以提供正确的访问者和/或更改者.

Answer 8

取决于您的语言.你已经标记了这个"面向对象"而不是"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 9

好吧,我只想补充一点,即使有时它们对于变量/对象的封装和安全性是必要的,如果我们想要编写一个真正的面向对象程序,那么我们需要停止过度使用附件,因为有时我们依赖很多当它们不是真正必要的时候,就像我们把变量公之于众一样.

Answer 10

谢谢,这真的澄清了我的想法.现在这里(差不多)10个(差不多)好的理由不使用getter和setter:

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

我刚离开的最后三个(N/A或D/C)......

Answer 11

我知道这有点晚了,但我认为有些人对性能很感兴趣.

我做了一点性能测试.我写了一个"NumberHolder"类,它拥有一个Integer.您可以使用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 12

除非您当前交付需要,否则不要使用getter setter Ie不要过多考虑将来会发生什么,如果在大多数生产应用程序,系统中有任何改变请求的事情.

想想简单,容易,在需要时增加复杂性.

我不会利用对深度技术知识的企业主的无知,因为我认为这是正确的,或者我喜欢这种方法.

我有大量的系统编写没有getter setter只有访问修饰符和一些方法来验证n执行业务逻辑.如果你绝对需要的话.用什么.

Answer 13

我们使用getter和setter:

• 可重用性
• 在编程的后期阶段执行验证

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

封装口头禅

封装口头禅是将字段设为私有,方法是公共的.

Getter方法: 我们可以访问私有变量.

Setter方法: 我们可以修改私有字段.

尽管getter和setter方法没有添加新功能,但我们可以改变主意,稍后再回来制作该方法

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

在可以使用值的任何地方,可以添加返回该值的方法.代替:

int x = 1000 - 500

使用

int x = 1000 - class_name.getValue();

用外行人的话说

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

我们可以class(Person)使用getter和setter方法创建一个bean ,而不是这样做.所以明天我们可以class(Person class)在需要添加新人时创建这个Bean的对象(参见图).因此,我们重用bean类的字段和方法,这要好得多.

Answer 14

它对于延迟加载很有用.假设有问题的对象存储在数据库中,除非您需要,否则您不希望得到它.如果对象是由getter检索的,那么内部对象可以为null,直到有人要求它为止,然后你可以在第一次调用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;
        }
      }
    }

Answer 15

我花了很长时间考虑Java案例,我相信真正的原因是:

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

换句话说,您可以在界面中指定字段的唯一方法是提供用于编写​​新值的方法和用于读取当前值的方法.

那些方法是臭名昭着的吸气者和制定者......

Answer 16

到目前为止我在答案中遗漏的一个方面是访问规范:

• 对于成员,您只有一个访问规范,用于设置和获取
• 对于制定者和吸气剂,您可以对其进行微调并单独定义

Answer 17

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

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

假设我们有这个简单的类:

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上的瓶子知道还有什么.

所有这些都可以采用不同的方式来处理各种各样的问题.Bottle只是检查它是否溢出它会抛出RuntimeException.但这可能是错误的做法.(关于错误处理有一个很有用的讨论,但我在这里有目的地保持它非常简单.评论中的人可能会指出这种简单方法的缺陷.;))

是的,似乎我们从一个非常简单的想法转变为快速获得更好的答案.

还有第三件事并不是每个人都能解决的问题:Getters和setter使用方法调用.这意味着它们看起来像其他地方的普通方法.而不是为DTO和东西提供奇怪的特定语法,你到处都有同样的东西.

Answer 18

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

在支持"真实"属性的语言(Python,Ruby,也许是Smalltalk？)中,没有必要获取/设置方法.

Answer 19

OO设计的基本原则之一:封装!

它为您提供了许多好处,其中之一就是您可以在幕后更改getter/setter的实现,但只要数据类型保持不变,任何具有该值的消费者都将继续工作.

Answer 20

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

Answer 21

代码不断演变。 当您需要数据成员保护private时非常有用。最终，所有的类都应该是某种“小程序”，它们有一个定义良好的接口，你不能仅仅破坏.

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

int getVar() const { return var ; }

所以你有了：

doSomething( obj->getVar() ) ;

代替

doSomething( obj->var ) ;

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

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

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

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

3) 完全充实并且对其内部有严格规则的类（即它们确切地知道自己在做什么，并且您不能对其内部进行“操”（技术术语））被指定为class默认私有成员，并且只有少数经过挑选的成员才被允许public。

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

Answer 22

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

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 23

在以下情况下，应使用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模拟库，只会使您的生活更加困难。如果这些工具对您很重要，请不要使用它们。

Answer 24

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

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

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

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