如果变量具有getter和setter，应该公开吗？

我有一个带有私有变量的类，该类具有该变量的getter和setter方法。为什么不将该变量公开？

我认为您唯一需要使用getter和setter的情况是，是否需要执行除set或get之外的其他操作。例：

void my_class::set_variable(int x){
   /* Some operation like updating a log */
   this->variable = x;
}

您听说过物业吗？

属性是具有“内置”访问器（获取器和设置器）的字段。例如，Java没有属性，但是建议将getter和setter写入私有字段。C＃具有属性。

那么，为什么我们需要吸气剂和吸气剂？基本上，我们需要它来保护/屏蔽现场。例如，您不在访问内存引用中的字段，而是在访问将更改字段（引用）的方法。像您的示例一样，该方法能够执行用户不愿进行的某些操作（封装行为）。例如，想象一下，有十二个类使用您的公共字段，并且您需要更改其使用方式...您必须查看每个类，才能更改它们使用字段的方式...不所以“ OOlysh”。

但是，例如，如果您有一个名为dead的布尔字段。在声明setDead和isDead之前，您应该三思。您应该编写易于阅读的访问器，例如kill（）而不是setDead。

但是，有许多框架假定您遵循JavaBean命名约定（在此谈论Java），因此，在这种情况下，应遵循命名对流声明所有的getter和setter。

这不是最受欢迎的意见，但我认为差别不大。

设置者和获取者是一个非常糟糕的主意。我已经考虑过了，说实话，在实践中我无法提出设置者/获取者属性和公共变量之间的区别。

在理论中，设置器和获取器或属性添加了一个位置，以在设置/获取变量时采取一些额外的操作，并且从理论上讲，它们将您的代码与更改隔离开来。

实际上，我很少看到使用setter和getter来添加操作，并且当您确实要添加操作时，想要将其添加到类的所有setter或getter中（例如日志记录），这应该使您认为应该成为更好的解决方案。

至于隔离设计决策，如果将int更改为long，则仍然必须更改setter并至少检查手动访问它们的每一行-那里没有太多隔离。

无论如何，默认情况下都应避免使用可变类，因此添加setter应该是最后的选择。使用构建器模式可以缓解这种情况，在该模式下可以设置值，直到对象处于所需状态，然后类可以变为不可变，并且设置器将引发异常。

至于吸气剂-我仍然无法在吸气剂和公共最终变量之间取得很大的不同。这里的问题是，无论哪种情况，它都是不好的OO。您不应该从对象中请求值并对其进行操作，而应该让对象为您执行操作。

顺便说一句，我绝不是提倡公共变量，而是说设置器和获取器（甚至是属性）太接近已经成为公共变量的位置了。

最大的问题就是，不是OO程序员的人很想使用setter和getter将对象变成传递和操作的属性球（结构），这与面向对象代码的工作原理截然相反。

吸气剂和吸气剂的使用者进入封装原理。这将使您能够更改类内部的工作方式并保持所有功能正常运行。

例如，如果调用foo.bar了另外3个对象以获取bar的值，而您决定将bar的名称更改为远，则您手上有问题。如果调用了这些对象foo.bar，则必须更改所有具有此功能的类。如果使用了setter / getter，那么您就没有任何更改。另一种可能性是更改变量的类型，在这种情况下，只需将一些转换代码添加到getter / setter中就可以了。

使用getter和setter还可让您控制将哪些内容存储在特定变量中。如果内容需要是某种类型或值，则设置程序代码的一部分可以确保新值满足这些要求。如果变量是公共变量，则不能确保满足这些要求。

这种方法还使您的代码更具适应性和可管理性。如果具有适当的功能使该体系结构对所有其他类或使用该类的函数隐藏，则更改类的体系结构会容易得多。如果您具有getter和setter之类的功能，那么已经提到的变量名更改只是许多更改中的一项，而这些更改更容易实现。总体思路是保持尽可能多的私有性，尤其是您的类变量。

您说：“我认为唯一需要使用getter和setter的情况是，除了set或get之外，还需要执行其他操作。”

如果将来在某个时候您可能需要执行除set和get之外的某些操作，并且您不想在发生这种情况时更改数千行源代码，则应该使用getter和setter 。

如果您不希望有人获取变量的地址并传递给变量，则应使用getter和setter方法，如果该变量可以在没有任何源代码提及的情况下进行更改，或者甚至在对象停止存在后也可以更改，则将带来灾难性的后果。

首先，让我们在范例上弄清楚。

• 数据结构->可以由适当了解知识的功能遍历和操纵的内存布局。
• 对象->一个自包含的模块，它隐藏其实现并提供可以通过其通信的接口。

吸气剂/设定剂在哪里有用？

获取器/设置器在数据结构中有用吗？没有。

数据结构是一个内存布局规范，它是一系列功能所共有和操纵的。

通常，任何旧的新功能都可以出现并操纵数据结构，如果这样做可以使其他功能仍然可以理解它，那么该功能将加入家族。否则，它是流氓功能和错误源。

不要误会我的意思，可能会有多个函数系列在数据结构上交织在一起，到处都有弯刀，反光涂层和双代理。当他们每个人都有自己的数据结构可以使用时很好，但是当他们共享它时...想象一下几个犯罪家庭在政治上意见分歧，那么它很快就会变得一团糟。

鉴于混乱的扩展功能系列可以实现，是否有一种方法可以对数据结构进行编码，以使恶意功能不会将所有事情弄乱？是的，它们被称为对象。

获取器/设置器在对象中有用吗？没有。

将数据结构包装在对象中的全部目的是确保不存在恶意功能。如果该功能想加入这个家族，则必须首先对其进行彻底的审查，然后再成为对象的一部分。

获取器和设置器的目的/目的是允许对象外部的功能直接更改对象的内存布局。这听起来像是在允许流氓的门户开放。

边缘案例

有两种情况使公众获得者/制定者有意义。

• 对象中一部分数据结构由对象管理，但不受对象控制。
• 一个接口，用于描述数据结构的高级抽象，其中某些元素不应控制于实现对象。

容器和容器接口是这两种情况的完美示例。容器内部管理数据结构（链接列表，地图，树），但由特定人员掌控所有特定元素。接口对此进行了抽象，并完全忽略了实现，仅描述了期望。

不幸的是，许多实现都犯了这个错误，并定义了这类对象的接口以提供对实际对象的直接访问。就像是：

interface Container<T>
{
    typedef ...T... TRef; //<somehow make TRef to be a reference or pointer to the memory location of T
    TRef item(int index); 
}

这已破了。Container的实现必须明确将其内部控制权交给使用它们的任何人。我还没有见过这样的可变值语言（从数据损坏的角度来看，具有不变值语义的语言从定义上来说是很好的，但不一定从数据间谍的角度来看）。

您可以通过仅使用复制语义或使用代理来改进/更正获取器/设置器：

interface Proxy<T>
{
     operator T(); //<returns a copy
     ... operator ->(); //<permits a function call to be forwarded to an element
     Proxy<T> operator=(T); //< permits the specific element to be replaced/assigned by another T.
}

interface Container<T>
{
     Proxy<T> item(int index);
     T item(int index); //<When T is a copy of the original value.
     void item(int index, T new_value); //<where new_value is used to replace the old value
}

可以说，流氓功能仍然可以在这里发挥混乱的作用（只要有足够的努力，大多数事情都是可能的），但是复制语义和/或代理减少了出现许多错误的机会。

• 溢出
• 下溢
• 与sub元素的交互是类型检查/类型检查（在类型丢失的语言中，这是福音）
• 实际元素可能驻留在内存中，也可能不是。

私人获取者/设定者

这是直接在类型上使用的getter和setter的最后堡垒。实际上，我什至不称这些getter和setter为存取器和操纵器。

在这种情况下，有时总是/几乎总是/一般地操纵数据结构的特定部分需要进行特定的记账。假设更新树的根时，需要清除后备缓存，或者在访问外部数据元素时，需要获取/释放锁。在这些情况下，应用DRY主体并将这些动作组合在一起是有意义的。

在私有上下文中，该家族中的其他功能仍然有可能避开这些“获取和设置”并操纵数据结构。因此，为什么我将它们更多地视为访问者和操纵者。您可以直接访问数据，也可以依靠其他家庭成员来正确处理该部分。

受保护的吸气剂/阻气剂

在受保护的上下文中，它与公共上下文没有很大不同。外国可能的流氓功能想要访问数据结构。所以不，如果它们存在，它们将像公共获取者/制定者一样运作。

根据C ++的经验，setter / getter对于以下两种情况很有帮助：

1. 如果必须在将值分配给成员（如字符串或数组）之前执行健全性检查。
2. 当需要函数重载时，如-1（或负值）为false时，将int值分配给bool分配时，这将很有帮助。反之亦然。

除此以外，安全性是很重要的一点，但它的重要性仅限于很少的开发应用程序，例如与登录或数据库访问相关的模块。当只有很少的人使用您的模块时，为什么还要打扰编码呢？