Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I have a class with a variable that is private and the class have getter and setter for that variable. Why don't make that variable public?

The only case I think you have to use getters and setters is if you need to do some operation besides the set or the get. Example:

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

Thanks in advance!

share|improve this question
Getters and setters are there for shielding. Someday you might want to do this->variable = x + 5, or call a UpdateStatistics function in setter, and in those cases classinstancea->variable = 5 will cause problems. – Coder Jul 31 '11 at 22:01
Another example is: set_inch, set_centimeter, get_inch, get_centimeter, with some spooky actions. – rwong Jul 31 '11 at 22:49
Yep, getters and setters help you control your instance variables the way in which you desire them to be controlled. – developerdoug Aug 1 '11 at 1:43
@Coder: you can always add your getter/setter when that need arises? Or is this something you cannot easily do in C++ (my experience is mostly Delphi)? – Marjan Venema Aug 1 '11 at 5:53
This question:… may be of interest. – Winston Ewert Aug 1 '11 at 6:47
up vote 14 down vote accepted

Have you ever heard about a property?

A property is a field that has "built-in" accessors (getters and setters). Java, for instance, doesn't have properties, but it's recommended to write the getters and setters to a private field. C# has properties.

So, why do we need getters and setters? Basically we need it to protect/shield the field. For instance, you're not accessing the field in memory reference, you're accessing a method that will then change the field (reference). That method is able to perform some operations that a user is not willing to know (encapsulating behavior), like in your example. Imagine, for instance, that a dozen classes use your public field and you need to change the way it's used... You would have to look at each of those classes in order to change the way they are using the field... Not so "OOlysh".

But, for instance, If you have a boolean field called dead. You should think twice before declaring a setDead and isDead. You should write accessors that are human readable, for instance, kill() instead of setDead.

However, there are a lot of frameworks that assume that you are following the JavaBean naming convention (talking about Java here), therefore, in those cases, you should declare all the getters and setters following the naming convetion.

share|improve this answer
Now "human readable" is finally an argument that I can "grok." All other arguments I usually hear are some sort of future proofing that are just as easily addressed when the need arises... – Marjan Venema Aug 1 '11 at 5:55
Your disdain for "future proofing" is common, but misguided. Yes, you can address such changes when the need arises, if you are the only client of that code. If you never publish your solution for external clients, you can simply incur technical debt and no one need ever know. But internal projects have a habit of becoming public when you least expect it, and then woe be unto you. – Kilian Foth Aug 1 '11 at 6:09
You actually raise a fantastic point. kill is not a set/get, it's an action. It completely hides the implementation--it's how you code OO. Properties, on the other hand, just as stupid as setters/getters--stupider even because the easy syntax encourages people to just add them to variables when they aren't even needed (OO-Furbar waiting to happen). Who would think to use kill() when they could just add a "property" tag to their dead flag? – Bill K Aug 2 '11 at 3:24
You know, I get upset when I see a Java code with 2000 lines and 1000 or more are just for getters and setters that don't do a thing. But, as everyone says, you may never know when you're going to add some new validation or related stuff... But I should say that, in my case, they are only following it because the framework they're using demands them to. Have you used play! framework? You declare public fields and it takes care of the get/set for you, just like a property. And then, if you wish, you can override something to add validation or something. – wleao Aug 2 '11 at 4:03
The question is tagged a C++ question. C++ doesn't support properties, so why would you even post this? – Thomas Eding Sep 26 '12 at 19:53

This is not the most popular opinion but I don't see much of a difference.

Setters and getters are a fairly bad idea. I've thought about it and honestly I can't come up with a difference between a setter/getter and a public variable in practice.

In THEORY a setter and getter add a place to take some extra actions when a variable is set/gotten and in theory they isolate your code from changes.

In reality I rarely see setters and getters used to add an action, and when you do want to add an action you want to add it to ALL the setters or getters of a class (like logging) which should make you think that there ought to be a better solution.

As for isolating design decisions, if you change an int to a long you still have to change your setters and at least check every line that accesses them by hand--not much isolation there.

Mutable classes should be avoided by default anyway, so adding a setter should be a last resort. This is mitigated with the builder pattern where a value can be set until the object is in a desired state then the class can become immutable and your setters will throw exceptions.

As for getters--I still can't come up with much of a difference between a getter and a public final variable. The problem here is that it's bad OO in either case. You shouldn't be asking for a value from an object and operating on it--you should be asking an object to do an operation for you.

By the way, I'm in no way advocating public variables--I'm saying setters and getters (and even properties) are way too close to already being public variables.

The big problem is simply that people who aren't OO programmers are too tempted to use setters and getters to make objects into property-balls (structures) that are passed around and operated on, pretty much the opposite of how Object Oriented code works.

share|improve this answer
One good thing apart from other answers here, about getter setter is: I can add some validations/conversions inside it befor the actual private variable assumes it's value. – Kiran Ravindranathan Aug 1 '11 at 7:22
+1 for "you should be asking an object to do an operation for you" – Malcolm Aug 1 '11 at 8:14
@Kiran true, but if you set it in the constructor you can have validations AND you have an immutable class. For setters I'm not saying a public writable variable is good, I'm saying that even setters are bad. For getters I might consider a public final variable a viable alternative. – Bill K Aug 2 '11 at 3:12
In some languages like C#, properties are not binary-compatible with public variables, so if you make a public variable part of your API, but then want to add some validation, you're going to break your client's program when you convert it to a property. Better to make it a public property from the start. – Robert Harvey Sep 26 '12 at 19:44
Mutable state is acceptable, but again you should ask your object to do something for you, not do somethign to your object--therefore when you mutate your state a setter is not a great way to do it, try writing a business method with logic in it instead. For instance, "move(Up5) rather than setZLocation(getZLocation()+5)". – Bill K Apr 25 '13 at 16:53

The user of getters and setters goes into the principle of encapsulation. This will allow you to change how things work inside of the class and keeping everything functioning.

For instance if 3 other objects call to get the value of bar and you decide to change the name of bar to far you have a problem on your hands. If the objects called you would have to change all the classes that have this. If a setter/getter is used then you have nothing to change. Another possibility is changing the type of the variable in which case just add some transformation code to the getter/setter and you are fine.

share|improve this answer
+1 - the member variable is implementation, the getter and setter are interface. Only the interface should be public. Also, the getter and setter names should make sense in terms of an abstraction, irrespective of whether there is a simple member variable underlying them or some other implementation. There are exceptions - cases where a subsystem built from tightly-coupled classes is the easiest way - but that just pushes the data-hiding boundary up a level anyway, to the class that represents the whole subsystem. – Steve314 Jul 31 '11 at 22:27
Couldn't I simply introduce the getter and/or setter when I need to change the work inside of the class? It is something that is easily done in Delphi, but perhaps not in other languages? – Marjan Venema Aug 1 '11 at 5:57
@ marjan Sure, you could introduce the getter/setter at any point later on. The issue then is that you have to go back and change ALL the code that was using the public field instead of getter/setter. I'm not sure if I'm the one who is confused or you are. 0.o – Pete Aug 1 '11 at 6:14
Personally, I think this is a bit of a bogus argument. If you change the meaning of a variable but the variable has a getter and setter, then it doesn't matter what it is called. It's not a visible part of the interface. You are much more likely to want to change the name of the getters and setters themselves to indicate to clients the change or clarification of the meaning of the encapsulated variable. In this latter case, you are in no better position that with a public variable. This is quite aside from the argument that a variable with getters and setters is more exposed than encapsulated. – Charles Bailey Aug 1 '11 at 9:04
@Charles For instance I was working on an application (in Java) and had the standard getter for a JDialog. In reality I was only getting the underlying Window object. I later changed the JDialog to a JFrame for some functionality reasons that I hadn't anticipated. The getter still works regardless of frame being a JDialog or JFrame. Nothing to update in the end. Not the case if I called object.frame or whatever it was called in which case I would have some major code wrangling to do. – Glenn Nelson Aug 1 '11 at 11:53

Using getters and setters also enables you to control what content gets stored in a particular variable. If the content needs to be of a certain type or value, part of your setter code can be to ensure that the new value meets these requirements. If the variable is public you can't ensure these requirements are met.

This approach also makes your code more adaptable and manageable. Its much easier to make changes to the architecture of a class if you have functions in place that keep that architecture hidden from all other classes or functions that utilize that class. The already mentioned change of a variable name is only one of many many changes that are much easier to make if you have functions like getters and setters. The overall idea is to keep as much private as possible, especially your class variables.

share|improve this answer
Thanks a lot! I was thinking the same case you mention. If I want a variable to be content in [0,1] I should check the incoming value in its setter :) – Oni Jul 31 '11 at 22:17
When you are the only developer working on a project it is easy to think that things like this are useless but when you find yourself working with a team you will find that being in the habit of techniques like this will come in very handy and help you avoid a lot of bugs down the road. – Kenneth Aug 1 '11 at 0:27
If you are using C#, use properties, you can use a property to set a private instance if needed based on some logic in the setter part of the property. – developerdoug Aug 1 '11 at 1:41

You say "The only case I think you have to use getters and setters is if you need to do some operation besides the set or the get. ".

You should use getters and setters if at some point in the future you might need to do some operation besides the set and get and you don't want to change thousands of lines of source code when that happens.

You should use getters and setters if you don't want someone to take the address of the variable and pass it around, with disastrous consequences if that variable can then be changed without any source code mentioning it, or even after the object stopped existing anymore.

share|improve this answer
Your last paragraph makes an excellent point which cuts both ways: requiring the use of getters and setters will prevent other code from taking the address of something. In cases where there would be significant benefits and few downsides to having outside code take the addresses of things, such restriction could be a bad thing. if there would be few benefits and severe downsides to allowing such behavior, restricting it could be a good thing. – supercat Jul 11 '15 at 16:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.