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

您处理的是概念上属于属性的东西，但是：您的语言没有财产（或类似的机制，如Tcl的变量跟踪），或您的语言的属性支持不足以满足此用例，或者您的语言（或有时您的框架）惯用惯例鼓励此用例的getter或setter。

因此，这很少是一个通用的OO问题；这是一个特定于语言的问题，对于不同的语言（和不同的用例）有不同的答案。

从OO理论的角度来看，getter和setter是无用的。你的类的接口是它所做的，而不是它的状态。（如果不是，你写错了类。）在非常简单的情况下，类所做的只是，例如，表示直角坐标中的一个点，*属性是接口的一部分；getter和setter只是为这一点添油加醋。但在非常简单的情况下，属性、getter和setter都不是接口的一部分。

换一种说法：如果你认为你的类的消费者甚至不应该知道你有一个垃圾属性，更不用说随意更改它了，那么给他们一个set_spam方法是你最不想做的事情。

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

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

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

即使你的语言确实有财产，也可能有不足或不合适的情况。例如，如果要允许子类控制属性的语义，在没有动态访问的语言中，子类不能用计算属性代替属性。

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

此外，遵循所使用语言（或框架）的习惯用法也很重要。如果你用C#编写了漂亮的Ruby风格的代码，那么除了你之外，任何有经验的C#开发人员都会很难读懂它，这很糟糕。有些语言的习俗文化比其他语言更为浓厚-Java和Python在习惯用法方面处于对立的两端，它们恰好拥有两种最强的文化，这可能不是巧合。

除了人类读者之外，还会有图书馆和工具要求你遵守惯例，如果你不遵守惯例，会让你的生活变得更艰难。将Interface Builder小部件挂接到ObjC财产以外的任何东西上，或者在没有getter的情况下使用某些Java模拟库，只会让您的生活更加困难。如果这些工具对你很重要，不要与它们对抗。

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

在支持“真实”财产的语言中（Python、Ruby或Smalltalk？），没有必要使用get/set方法。

因为从现在起2周（月、年），当您意识到setter需要做的不仅仅是设置值时，您还将意识到该属性已直接用于238个其他类：-）

代码不断演变。private非常适合需要数据成员保护的情况。最终，所有的类都应该是一种“小程序”，它有一个定义良好的接口，你不能只使用它的内部结构。

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

int getVar() const { return var ; }

所以你有：

doSomething( obj->getVar() ) ;

而不是

doSomething( obj->var ) ;

getVar（）不仅在视觉上很嘈杂，而且给人一种错觉，认为getingVar（（）在某种程度上是一个比实际更复杂的过程。如果你的类有一个passthrough setter，那么你（作为类编写者）如何看待var的神圣性对你的类的用户来说尤其令人困惑——那么你似乎在设置这些门来“保护”你坚持认为有价值的东西，（var的神圣性）但即使你承认，任何人只要进来并将var设置为他们想要的任何值，而你甚至不去偷看他们在做什么，那么var的保护就没有多大价值。

所以我按如下方式编程（假设采用“敏捷”类型的方法——即当我编写代码时不知道它将要做什么/没有时间或经验来规划一个复杂的瀑布式界面集）：

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

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

3） 完全充实并对其内部有严格规则的类（即，它们确切地知道自己在做什么，你不能“操”（技术术语）它的内部）被赋予类名称，默认为私有成员，只有少数成员被允许公开。

我发现这种方法可以让我避免在一个类进化的早期阶段，当大量数据成员被迁移、转移等时，坐在那里虔诚地编写getter/setter。

我想发布一个我刚刚完成的真实世界示例：

背景-我使用休眠工具为我的数据库生成映射，这是一个我在开发时正在更改的数据库。我更改数据库模式，推送更改，然后运行hibernate工具来生成java代码。在我想向这些映射实体添加方法之前，一切都很好。如果我修改了生成的文件，则每次对数据库进行更改时都会覆盖这些文件。所以我这样扩展生成的类：

package com.foo.entities.custom
class User extends com.foo.entities.User{
     public Integer getSomething(){
         return super.getSomething();             
     }
     public void setSomething(Integer something){
         something+=1;
         super.setSomething(something); 
     }
}

我上面所做的是用我的新功能（something+1）覆盖超类上的现有方法，而不需要接触基类。如果你在一年前写了一个类，并且想在不改变基类的情况下升级到第2版（测试噩梦），也是同样的情况。希望这会有所帮助。

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

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

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

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