I program primarily in ColdFusion but this is a general OOP question.

Is there any benefit to using:

getProp() {
    return prop;

setProp(val) {
    prop = val;

As opposed to simply

obj = new Obj();
obj.prop = "1";
  • 3
    It's not a general OOP question. Many languages support properties more directly. Declaring a property gives default behavior for access and retrieval, but you can override that behavior if necessary. Commented Apr 13, 2012 at 19:18
  • 2
    The other side of the coin: programmers.stackexchange.com/questions/21802/… Commented Apr 13, 2012 at 20:05
  • If you have a private internal class, you can do whatever you want with it. I'd just as soon leave it without getters/setters if it is basically a struct since there is no reason to future-proof the code. If the internals change, this is part of the internals too. Commented Nov 22, 2012 at 1:33

4 Answers 4


I think you must try to use getters and setters always. In your case you have something like:

obj = new Obj();
obj.prop = "1";

What if you have other 1000 references to obj.prop? And then, you decide that obj.prop cannot be a negative like "-4" (just an example). If that's the case, how would you control that nobody passes such values to the object? If you used a setProp method it will be easy:

setProp(val) {
    if(val < 0)
      // doSomething
    prop = val;

In general, that's the kind of situations where using setter and getter would make your code easier to maintain. There are many other situations like that and most of them encourage you to use setter and getter.

However, I sometimes use classes with public fields. I do it when that class is an inner private class; which means that it is not used outside the parent class. In such cases the excuse is: "I always know what data to assign and that it is valid". Though, it is always a case of laziness.

Some guys say it is faster in runtime to assign the values directly, and that might be true but I think it is difficult to note a significant difference one way or the other.

  • 1
    I think almost any modern compiler will eliminate the function call to simple getters and setters and turn them into direct property accesses.
    – TMN
    Commented Apr 13, 2012 at 19:37
  • In the case where the setter is not simple, what would the compiler do?
    – Cristian
    Commented Apr 13, 2012 at 19:46
  • 1
    In some languages, the syntax for accessing a property directly and calling a getter / setter are identical. In those cases, your argument is moot, since you can always promote a bare field to a getter/setter pair later without breaking any interfaces.
    – tdammers
    Commented Apr 13, 2012 at 21:20
  • @tdmmaers you are right. Thanks for pointing it out.
    – Cristian
    Commented Apr 13, 2012 at 21:27
  • 1
    related to this, is, what if it turns out that the property is being accessed from a multi-threaded context? It would be much easier to add (internal) locks in the getter/setter version, then deal with external references. Commented Apr 13, 2012 at 22:14

In languages without C-style structs, it's generally accepted, even encouraged, to use public fields for "Plain Old Data" classes, like complex numbers, points, etc. Otherwise, getters and setters are recommended.

In addition to Cristian's excellent point about maintainability, it also makes debugging much easier to have only one place where a value can be changed. For example, maybe a field is used to index an array and you get an out of bounds exception. Without a setter, you're going to go through the entire code finding the one place that sets it to the wrong value. With a setter, you just put a breakpoint in the setter and you know very quickly. Setters also allow you to enforce data validation.

In other words, it's slightly more typing in the short run that maybe is not needed later on, but is extremely useful when it is.

  • I find it curious that Microsoft, in suggesting when to use a struct versus a class, ignored the fact that in many cases it's useful to have a data type which represents a collection of associated but independent values (e.g. Point or Rectangle); a struct with exposed fields is perfect for that because it is, literally, exactly what it's supposed to represent: a collection of independent variables.
    – supercat
    Commented Nov 18, 2012 at 0:37

There's no particular reason to use getters/setters if you dont need them. Public properties are there, after all, for a reason. Otherwise you're just cluttering the code with getter and setter functions that may never do anything more than assign a value.

Some of it is language dependent - some languages steer you more to them than others. Delphi, for example, has properties, which can effectively act as either a wrapper around a private variable, or a getter/setter. So there's no actual need to use a getter/setter method if you dont immediately need it, since a public variable can be recast as a property using getter/setters, keeping the interface to that class the same for the code that uses it (i.e., even though it may be a getter/setter under the hood, to code setting an object's property, it still does so as if it was a public variable).

Basically my advice is what it always is... worry less about how other people say you should be coding, and more about making sure your projects get done and are easily maintainable. If that means getters/setters to you, then use 'em. If it doesnt, thats good too.


In addition to the good points already mentioned, for C#.NET:

A - Unlike fields, a property does not have any associated storage space within the object.

B - The property value is set (or calculated) when accessed not when the object is instantiated.

Note: A field value may be set only when used if you use the volatile keyword when defining the field.

C - A property could assign a calculated value based on specific instance data to the result (or input) whereas in the case of a field, you need to invoke a method to do that, this makes your code confusing because it would require both methods and properties to obtain the object state.

D - Fields can’t be writeonly but Properties can (writeonly is rarely used but is still part of the language).

Reference: Source for A and B above is the book: Accelerated C# 2010. Information have been re-phrased based on my own understanding. For more information on volatile keyword, see Black-Wasp-Volatile Keyword.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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