Getter和Setters何时合理

getter和setter经常被批评为不合适的OO。另一方面，我见过的大多数OO代码都有大量的getter和setter方法。

何时使用吸气剂和塞特剂？您是否尝试避免使用它们？他们是否普遍滥用？

如果您最喜欢的语言具有属性（我的语言），那么此类问题也被视为此问题的获取者和准备者。从面向对象方法论的角度来看，它们是同一回事。他们只是语法更好。

Getter / Setter批评的来源（部分摘自评论以使他们更清晰可见）：

• http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
• http://typicalprogrammer.com/?p=23
• http://c2.com/cgi/wiki?AccessorsAreEvil
• http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm
• http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and
• http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

简单地说一下批评：Getters和Setters允许您从对象外部操纵对象的内部状态。这违反了封装。只有对象本身应该关心其内部状态。

以及示例程序版本的代码。

struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}

Mutator版本的代码：

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

没有提供适当的封装，getter和setter会使代码变得更加复杂。由于其他对象可以访问内部状态，因此添加这些getter和setter不会带来很多好处。

该问题先前已在堆栈溢出中讨论过：

• https://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil
• https://stackoverflow.com/questions/996179

拥有getter和setter方法本身并不会破坏封装。破坏封装的方法是自动为每个数据成员（Java术语中的每个字段）添加一个getter和setter ，而无需考虑任何问题。尽管这比使所有数据成员公开更好，但仅一步之遥。

封装的重点不是您不应该从对象外部知道或更改对象的状态，而是应该拥有合理的策略来做到这一点。

• 一些数据成员可能完全在对象内部，并且既不应该具有getter也不应该具有setter。

• 一些数据成员应该是只读的，因此它们可能需要getter但不需要setter。

• 某些数据成员可能需要保持彼此一致。在这种情况下，您将不会为每个设置程序提供设置程序，而是提供一种同时设置它们的单一方法，以便您可以检查值的一致性。

• 某些数据成员可能仅需要以某种方式进行更改，例如以固定量递增或递减。在这种情况下，您将提供一个increment()和/或decrement()方法，而不是一个setter。

• 还有一些实际上可能需要读写，并且同时具有getter和setter。

考虑一个例子class Person。假设一个人有一个名字，一个社会保险号和一个年龄。假设我们不允许人们更改其姓名或社会保险号。但是，该人的年龄每年应增加1。在这种情况下，您将提供一个构造函数，该构造函数会将名称和SSN初始化为给定值，并将年龄初始化为0。您还将提供一个方法incrementAge()，该方法会将年龄增加1。所有三个的吸气剂。在这种情况下，不需要二传手。

在此设计中，您允许从类外部检查对象的状态，并允许从类外部更改对象的状态。但是，您不允许随意更改状态。有一项策略有效地声明了名称和SSN完全不能更改，并且年龄可以一次增加1年。

现在，假设一个人也有薪水。人们可以随意更换工作，这意味着他们的工资也将改变。为了模拟这种情况，我们只能提供一种setSalary()方法！在这种情况下，允许随意更改薪水是一个完全合理的政策。

顺便说一句，在你的榜样，我会给类Fridge的putCheese()和takeCheese()方法，而不是get_cheese()和set_cheese()。这样您将仍然具有封装。

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

Java中的getter和setter的基本原因很简单：

• 您只能在接口中指定方法，而不能指定字段。

因此，如果要允许字段通过接口传递，则将需要一个reader和writer方法。传统上将它们称为字段x的getX和setX。

来自http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and

JavaBean样式：

connection.setUser("dukie");
connection.setPwd("duke");
connection.initialize();

面向对象风格：

connection.connect("dukie","duke");

好吧，显然我更喜欢后一种方法。它不会泄漏实现细节，它更加简单明了，并且所有需要的信息都包含在方法调用中，因此更容易实现。我还更愿意在可能的情况下使用构造函数中的参数设置私有成员。

您的问题是，什么时候需要使用吸气剂/吹丝机？也许当需要更改模式时，或者您需要询问对象以获取某些信息时。

myObject.GetStatus();
myObject.SomeCapabilitySwitch = true;

考虑这一点时，当我第一次开始使用C＃进行编码时，我以上述的Javabeans风格编写了许多代码。但是随着我在语言方面的经验的积累，我开始在构造函数中进行更多的成员设置，并使用看起来更像上述OO风格的方法。

何时使用吸气剂和塞特剂？

当行为“ get”和“ set”实际上与模型中的行为相匹配时，这几乎是不可能的。

其他所有用途只是作弊，因为业务域的行为尚不清楚。

编辑

这个答案可能是轻率的，所以让我扩展一下。上面的答案大部分是正确的，但侧重于OO设计的编程范例，还有一些遗漏的地方。根据我的经验，这使人们认为避免使用getter和setter是OO编程语言的一些学术规则（例如，人们认为用属性替换getter很重要）。

实际上，这是设计过程的结果。您不必深入研究接口，封装和模式，也不必争论它们是否破坏了这些范式以及什么是好的OO编程还是不好的OO编程。最终最重要的一点是，如果您的域中没有任何东西像这样通过将它们放入您的工作中而没有建模您的域。

现实情况是，您域空间中的任何系统极不可能有吸气剂和吸气剂。您不能走到负责工资单的男人或女人，而只能说“将此薪水设置为X”或“请给我这个薪水”。这种行为根本不存在

如果将其放入代码中，则不是在设计与域模型匹配的系统。是的，这破坏了接口和封装，但这不是重点。关键是要建模一些不存在的东西。

更重要的是，您可能错过了重要的步骤或过程，因为可能有一个原因，我不能只是走上工资单，并说将薪水设置为X。

当人们使用吸气剂和吸气剂时，他们倾向于将这一过程的规则推到错误的地方。这将进一步远离您的域。使用现实世界中的示例，这就像薪水，假设走进的随机人有权获取这些值，否则他不会要求这些值。这不仅不是域的方式，实际上还在于域的方式。

通常，吸气剂和吸气剂是个坏主意。如果字段在逻辑上不是接口的一部分，并且您将其设为私有，那很好。如果从逻辑上讲它是接口的一部分，并且您将其公开，那就很好。但是，如果您将其设为私有，然后通过提供一个getter和setter将其转回并再次有效地公开，则您将回到开始的地方，只是您的代码现在变得更加冗长和混乱。

显然，也有例外。在Java中，您可能需要使用接口。Java标准库具有向后兼容性的要求，因此其极端性足以超过正常的代码质量度量。甚至有可能您实际上是在处理传奇但罕见的情况，即很有可能以后可以用即时计算替换存储的字段而不会破坏接口。但是这些都是例外。Getter和Setter是需要特殊证明的反模式。

是直接访问字段还是通过方法访问字段并不重要。

类不变式（有用的）很重要。为了保护它们，我们有时有时无法从外部进行更改。例如。如果我们将Square的宽度和高度分开，则更改其中之一会使它变成不是Square的东西。因此，我们需要方法changeSide如果它是Rectangle，则可以有setter / public字段。但是setter比会测试其大于零是否更好。

在具体的语言中（例如Java）是我们需要这些方法（接口）的原因。方法的另一个原因是兼容性（源和二进制）。因此，添加它们然后考虑公共领域是否足够容易。

顺便说一句 我喜欢对公共final字段使用简单的不可变值持有类。

您可能希望将内部结构更改为任何内容，同时保持接口相同。如果您的界面不变，则您编写的代码不会中断。您仍然可以根据需要更改内部结构。

我的方法是-

当我期望稍后再使用数据时，有理由使用getter / setter。另外，如果发生更改，我经常将数据推送到getter / setter中。

如果是POD结构，则保留可用的插槽。

从更抽象的角度讲，问题是“谁来管理数据”，这取决于项目。

如果使用getter和setter方法感到复杂，那么问题可能出在语言上，而不是概念本身。

这是用Ruby编写的第二个示例中的代码：

class Fridge
  attr_accessor :cheese
end

def go_shopping fridge
  fridge.cheese += 5
end

注意，它看起来很像Java中的第一个示例吗？如果将吸气剂和装夹器视为头等公民，那么它们就不是一件繁琐的事，而增加的灵活性有时则是真正的好处-例如，我们可以决定在新冰箱上返回奶酪的默认值：

class Fridge
  attr_accessor :cheese

  def cheese
    @cheese || 0
  end
end

当然，会有许多不应该公开暴露的变量。不必要地公开内部变量会使您的代码更糟，但是您几乎不能将其归咎于getter和setter。

考虑一个Size封装宽度和高度的类。我可以通过使用构造函数消除二传手，但是这如何帮助我绘制一个矩形Size呢？宽度和高度不是该类的内部数据；它们是必须可供Size使用者使用的共享数据。

对象由行为和状态-或属性组成。如果没有暴露状态，那么只有行为是公开的。

没有状态，您将如何排序对象的集合？您将如何搜索对象的特定实例？如果仅使用构造函数，那么当对象的属性列表很长时会发生什么？

未经验证，不得使用任何方法参数。因此，懒惰地写：

setMyField(int myField){
    this.myField = myField;
}

如果确实以这种方式编写，那么您至少已准备好使用setter进行验证；它比公共领域要好-但仅此而已。但是至少您拥有一个一致的公共接口，您可以返回该接口并放入验证规则，而不会破坏客户的代码。

getter，setter，property，mutator称呼您想要的东西，但它们是必需的。

如果getter和setter违反了封装和真正的OO，那么我就很麻烦了。

我总是觉得一个对象代表着您需要它做的一切。

我刚写完一个用Java生成迷宫的程序，并且有一个表示“迷宫方块”的类。我在此类中的数据表示坐标，墙和布尔值等。

我必须有某种方式来更改/操作/访问该数据！没有getter和setter的情况下我该怎么办？Java不使用属性，因此将我在此类本地的所有数据都设置为public无疑是对封装和OO的违反。

首先，我将评论两种类型的对象：价值和服务类型。

服务类型永远不应该有设置器，无论它们需要什么依赖关系都不能被获取。传递依赖关系的最佳方法是通过构造函数或工厂，这种方法从一开始就简单，完整地形成了所有实例。

值类型也应该是不可变的，另一方面，有时还不可行，例如ORM或其他一些映射（例如从小部件到对象）。在系统中从一层或一部分传递到另一层或另一部分的所有其他值类型应该是不可变的，并且不应具有setter。

Getter / Setter就像其他任何公共方法一样是合理的。理由主要是因为我们要提供一个与外界的接口，以定义我们的类与其他类的交互方式。我们这样做主要是因为我们要减少单独实体之间的耦合。减少耦合是一件好事，原因有很多：

• 我可以从当前代码使用相同的类接口，尽管与此同时，该类添加了新方法（但保留了旧接口）
• 可以更改类的内部表示形式而不会影响其使用方
• 减少错误的机会：如果将内部数据设为私有，则可以肯定地知道外部代码不会与内部数据混淆

是的，getters和setters是面向对象编程中的反模式，永远不应使用：http : //www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html。简而言之，它们不适合面向对象的范例，因为它们鼓励您将对象视为数据结构。这是一个主要的误解。

我希望由公司开发的自动开发您的编程语言的IDE不会违反“对象定向原理”。

话虽如此，只要您有公共范围的变量，就可以使用getter和setter来达到目标​​。在我看来，这是极其面向对象的封装原理的必要元素-即使它看起来像很多垃圾代码。

使用它们的原因是，可能仍会进行适当的封装，只要您已经抽象掉了让让人摸索您的物体的物体感觉到您的物体的层，就可以在他甚至不知道正确的情况下将其取走？

可以这么说，一间分开的房子无法忍受，OO的一个租户不会自行打开，并且您不能同时进行封装和过早优化。

我以为我们在这里会有更多平常的答案？

通常，getter和setter都非常面向对象（任何人说其他什么都不对，就这么简单）。

尽管您需要记住不要过度设计，但切勿进行不需要的吸气剂或吸气剂。任何其他类都不打算使用的信息，都不应有任何获取或设置方法。

虽然，您不公开字段而是使用getter和setter的原因主要是：

• 使用字段无法进行正确的测试。在这方面，吸气剂/定阻剂要好得多。

• 在实时编程设置中正确使用字段是不可能的。同步获取器/设置器是必经之路。

• 界面主题（已经解释，所以我不会）。

• 正确重用系统时，使用起来更容易。

• 与使用getter / setter方法相比，要知道哪个类正在使用您的类以及要更改的内容要难得多。

因此，唯一的一次使用公共场所而不是使用getter / setter的情况是，您没有制定正式项目，而是只是出于娱乐目的而不会打扰getter / setter的人。