[ACCEPTED]-When to use get/set Methods in java-getter-setter

Accepted answer
Score: 38

Using Getters / Setters vs using Fields

As a rule of thumb:

use the variables directly 3 from the same class (actually from the same 2 .java file, so inner classes are ok too), use 1 Getters / Setters from other classes.

Score: 22

The simple rule is: never use direct access 5 (except, of course, when referring to them 4 from inside the class).

  • field access can't be proxied
  • you may want to have some event notification
  • you may want to guard against race conditions
  • expression languages support setters and getters
  • theoretically this breaks encapsulation. (If we are pedantic, setter and getter for all fields also breaks encapsulation though)
  • you may want to perform some extra logic inside the setter or getter, but that is rarely advisable, since consumers expect this to follow the convention - i.e. being a simple getter/setter.
  • you can specify only a setter or only a getter, thus achieving read-only, or write-only access.

Even if this does 3 not happen that you need any of these, it 2 is not unlikely. And if you start with field 1 access, it will be harder to change.

Score: 10

In Java, using a getter and setter is usually 10 considered best practice.

This is because 9 if you ever need to change your code to 8 do something else when a property is accessed 7 or modified, you can just change it in the 6 existing getter or setter.

I tend to think 5 it causes a bit of clutter for simple objects, but 4 if you have ever had to refactor a public 3 property to a getter and setter to add additional 2 functionality you will see that it can be 1 a pain.

Score: 7

I suspect most will say to always use getters/setters 4 to access private members. It's not necessary, but 3 is considered a "best practice".

One advantage 2 is that you can have more than just simple 1 assignment and returning. Example:

public void setLevel(int lvl)
{
    if (lvl<0)
    {
        this.level=1;
    }
    else
        this.level = lvl;
}

public int getLevel()
{
    if (this.someIndicator==4)
        return this.level*7.1;
    else
        return level;
}
Score: 3

Getters and Setters allow you to change 18 the implementation later (e.g. do something 17 more complex), allow you to implement validation 16 rules (e.g. setName throws an exception if the 15 name is not more than 5 characters, whatever.)

You 14 could also choose to add a getter but not 13 a setter so that the variable is like 'read-only'.

That's 12 the theory, however in many cases (e.g. Hibernate 11 using setters) you cannot throw exceptions 10 in setters so you can't do any validation. Normally 9 the value will just be assigned/returned. In 8 some companies I've worked at, it's been 7 mandatory to write getters and setters for 6 all attributes.

In that case, if you want 5 to access an attribute from outside an object, and 4 you want it to be readable/writable, I just 3 use a public attribute. It's less code, and 2 it means you can write things like obj.var += 5 which 1 is easier to read than obj.setVar(obj.getVar() + 5).

Score: 2

If you mean: when to use public accessor 23 methods instead of making the internal, private 22 variable public my answer is "always" unless 21 there is a severe performance reason.

If 20 you mean, call your own get and set methods 19 vs direct access to the vars w/in your class 18 I still say call your own access methods. This 17 way, any conversion, edits or rules you 16 implement as part of get/set get invoked 15 automatically by your own internal calls 14 as well as external callers.

In pure OO languages 13 (for example, Smalltalk) there is no concept 12 of public - all internal vars are private 11 and so you must use accessors. In less 10 pure OO languages, you can make things public 9 - however exposing the internals of your 8 data structures and implementation is an 7 exceptionally bad idea for stability and 6 maintenance in the long run. Look up "tight 5 coupling" for more on this.

Simply put, if 4 you expose internal vars publicly, people 3 can access them directly and if you ever 2 change name or type everything down the 1 line breaks. This is called side effects.

Score: 1

Its a matter of taste, but generally speaking 6 you always should use get/set methods for 5 all properties that are public. But for 4 things like Value Objects (VOs) that you 3 probably are not going to be bothered with 2 for some time you can use public variables 1 without getting too much criticism I think.

Score: 1

In general, you'd want to use setters and 20 getters to give the opportunity to developers 19 reusing your code by modifying it or extending 18 it to add layers of processing and control 17 when accessing and modifying your internal 16 data. This wouldn't be possible in Java 15 when using direct accesses.

Parenthesis: However, it's perfectly possible in other languages, for instance in Scala, when the line between properties and methods can become quite fine. And it's great, as then it doesn't become a coding-problem that gets in the way and it makes usage more transparent.


You can also 14 often consider that in your class you can 13 feel free to access your internal (private 12 or protected) members directly, as you're 11 supposed to know what you're doing, and 10 you don't need to incur the overhead of 9 yet another method call.

In practice, multiple 8 people working on a class might not know 7 what everyone's doing and those lines of 6 integrity checking in your getters and setters 5 might be useful in most cases, while the 4 micro-optimization may not.


Moreover, there's 3 only one way for you to access a variable 2 directly, whereas you can define as many 1 accessors as you want.

Score: 0

Encapsulate the private fields of a class 2 and expose them with getter/setter classes 1 the way you want to.

More Related questions