类：公共变量或公共函数来更改本地变量？
正如主题标题所述，
在哪些情况下您更喜欢使用公共函数来更改局部变量，而不是仅仅将该变量定义为公共并直接修改它？
Exactly what the topic title says,
In which cases would you prefer using public functions to change local variables over just defining that variable as public and modifying it directly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
显然，如果您希望更改变量以对对象的状态产生其他影响（例如重新计算对象的某些其他属性），则必须使用赋值函数。
如果可以将变量设置为使对象处于无效状态的值，那么您可能还应该使用赋值函数。 这样，如果即将发生非法情况，您可以抛出异常（或返回错误，或只是忽略）。 这对于调试来说有奇效。
但是，如果某些变量可以使用修改器函数进行修改，而其他变量是公共的，则程序员需要跟踪哪个是哪个。 这是浪费时间和精力，因此在某些情况下，最简单的方法是仅使用变异函数来完成所有操作。
Obviously if you want changing the variable to have some other effect on the object's state (like recalculating some other property of the object) you must use a mutator function.
If it's possible to set the variable to something that places the object in an invalid state, you should probably also use a mutator function. This way you can throw an exception (or return an error, or just ignore) if something illegal is about to happen. This does wonders for debugging.
But if some variables can be modified with mutator functions, and others are public, the programmer needs to keep track of which is which. This is a waste of time and effort so in some cases it's easiest to just use mutator functions for everything.
如果您纯粹从服务的角度来看待对象，您就会意识到公开变量并不是公开这些服务的好方法。
API 必须反映对象的全部内容（以使其实现高内聚性），如果您定义了 setValue(...)，那么它并不是那么重要，因为您现在需要一种方法来更改变量，但是因为对象公开此服务是有意义的。
所以：
不要为您编写的每个类的每个成员提供访问器或修改器函数。 仅当访问器/修改器方法是类接口 (API) 的合理且有用的部分时，才提供访问器/修改器函数。
不要将这些方法视为访问器或修改器。 相反，请将它们视为访问或改变对象的某个抽象属性的方法，该对象今天恰好由单个成员表示，但明天可能会以更复杂的方式进行计算。
If you look at an object purely in term of service, you realize that exposing a variable is not a good way to expose those services.
The API must reflect what the object is all about (for it to achieve a high cohesiveness), and if you define a setValue(...), it is not so much because you need a way to -- today -- changes a variable, but because it makes sense for the object to expose this service.
So:
Don't provide accessors or mutator function to every single member of every single class you write. Only provide accessors/mutator functions if the accessors/mutator methods are a sensible and useful part of the class's interface (API).
Don't think of these methods as accessors or mutators. Instead, think of them as methods that access or mutate a certain abstract property of the object that happens to be represented by a single member today, but may be computed in a more complex manner tomorrow.
您应该提及您正在处理的语言，因为这会影响答案。
您首先想到的应该是您的类的 API。 如果您想保持该 API 稳定（您应该这样做！），那么请考虑稍后如何将今天的简单变量更改为成熟的方法。
在许多语言中，如果不更改调用代码，就无法将变量更改为方法。 C、C++ 和 Java 都属于这一类。 永远不要在这些语言中使用公共变量，因为以后你将没有任何回旋余地。
在 Python 中，您可以将变量更改为属性，而无需更改调用者，因此您不必预先担心：使用公共变量。
我相信 C# 具有可以让您透明地将变量更改为方法的属性，但我不确定。
You should mention what language you are dealing with, since that will affect the answer.
Your first thought should be about the API to your class. If you want to keep that API stable (and you should!), then consider how you might change today's simple variable into a full-blown method later.
In many languages, you can't change a variable to a method without changing the calling code. C, C++, and Java fall into this category. Never use public variables in these languages, because you won't have any wiggle room later.
In Python, you can change a variable to a property without changing the callers, so you don't have to worry up front: use public variables.
C# I believe has properties that can let you change variables to methods transparently, but I am not sure.
如果您想更改类内的变量，最好通过属性来完成。
在外部修改变量并不是一个好习惯。
也想想未来的发展。 您可以在属性背后添加一些逻辑，而无需更改整个程序。
If you want to change a variable inside a class, your best doing it through Properties.
Its not good practice to have variable's modified on the outside.
Think of future development too. You could put some logic behind a Property without changing the whole program.
不要直接公开数据成员：使用不透明访问器意味着您可以在以后更改实现，而无需更改接口。
我应该知道。 我时常走捷径，也曾后悔过。
Don't expose the data members directly: using opaque accessors means you can change the implementation at a later date without changing the interface.
I should know. I take the short cut from time-to-time, and have had occasion to regret it.