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

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


当前回答

根据我的经验,最好将变量设置为私有,并为每个变量提供访问器和修饰符。

通过这种方式,您可以根据需要创建只读变量,也可以只写变量。

下面的实现显示了一个只写变量。

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

下面显示了一个只读变量。

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

其他回答

如果您想要一个只读变量,但不想让客户端改变访问它的方式,请尝试使用这个模板类:

template<typename MemberOfWhichClass, typename primative>                                       
class ReadOnly {
    friend MemberOfWhichClass;
public:
    template<typename number> inline bool   operator==(const number& y) const { return x == y; } 
    template<typename number> inline number operator+ (const number& y) const { return x + y; } 
    template<typename number> inline number operator- (const number& y) const { return x - y; } 
    template<typename number> inline number operator* (const number& y) const { return x * y; }  
    template<typename number> inline number operator/ (const number& y) const { return x / y; } 
    template<typename number> inline number operator<<(const number& y) const { return x << y; }
    template<typename number> inline number operator^(const number& y) const  { return x^y; }
    template<typename number> inline number operator~() const                 { return ~x; }
    template<typename number> inline operator number() const                  { return x; }
protected:
    template<typename number> inline number operator= (const number& y) { return x = y; }       
    template<typename number> inline number operator+=(const number& y) { return x += y; }      
    template<typename number> inline number operator-=(const number& y) { return x -= y; }      
    template<typename number> inline number operator*=(const number& y) { return x *= y; }      
    template<typename number> inline number operator/=(const number& y) { return x /= y; }      
    primative x;                                                                                
};      

示例用途:

class Foo {
public:
    ReadOnly<Foo, int> cantChangeMe;
};

记住,您还需要添加按位和一元运算符!这只是为了让你开始

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

在支持“真实”财产的语言中(Python、Ruby或Smalltalk?),没有必要使用get/set方法。

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

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

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

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

太棒了现在我们把瓶子换成这个:

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和其他东西没有奇怪的特定语法,而是到处都有相同的语法。

在面向对象的语言中,方法及其访问修饰符声明该对象的接口。在构造函数、访问器和赋值器方法之间,开发人员可以控制对对象内部状态的访问。如果变量被简单地声明为公共的,那么就没有办法规范这种访问。当我们使用setter时,我们可以限制用户所需的输入。这意味着这个变量的输入将通过一个适当的通道,通道是我们预先定义的。所以使用setter更安全。

公共字段并不比getter/setter对差,它除了返回字段并赋值之外什么都不做。任何差异都必须存在于其他因素,如可维护性或可读性。

getter/setter对的一个经常提到的优点不是。有一种说法是,您可以更改实现,而不必重新编译客户端。据推测,setter允许您稍后添加验证之类的功能,而您的客户甚至不需要知道它。然而,将验证添加到setter是对其前提条件的更改,违反了以前的合同,这很简单,“您可以将任何东西放在这里,稍后您可以从getter那里获得相同的东西”。

因此,现在您违反了合同,更改代码库中的每个文件是您应该做的事情,而不是避免。如果你避免这样做,你就假设所有的代码都假设这些方法的契约是不同的。

如果这不应该是约定,那么接口允许客户端将对象置于无效状态。这与封装正好相反。如果该字段从一开始就不能真正设置为任何值,为什么验证从一开始不存在?

同样的论点也适用于这些传递getter/setter对的其他假定优点:如果您稍后决定更改设置的值,那么您就违反了合同。如果您在派生类中重写默认功能,而不是进行一些无害的修改(如日志记录或其他不可观察的行为),那么您就违反了基类的约定。这违反了Liskov替代原则,这被视为OO的原则之一。

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

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

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

客户:“我可以用这个类的对象做什么?”设计器:“你可以读写几个变量。”客户:“哦……我想很酷吧?”

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