Getters and Setters in Java convention

Question

My Java is a bit rusty (been doing C# for the last couple of years). Also I hope this won't be a very subjective question.

Anyway say I had class Person (yeah a bit of a cliche, I know), with no behaviour (C# version):

public class Person 
{
   public string Name { get; set; }
   public int Age { get; set; }
   // say 10+ properties
}

How would the equivalent Java version look like ? I know I can write bunch of getters and setters (but say I had 10+ properties), it feels like a lot of boilerplate. Is it considered bad practice to just do:

public class Person {
   public String name;
   public int age;
   // rest of the stuff here
}

I feel a bit uneasy about this. I realise there is no "right answer" but, I'm more interested in the general conventions and best practices.

In java we signify `set` methods by using the `.this` statement. We signify `get` methods by using the `return` statement. — Tdorno, Aug 04 '13 at 18:21
Dup http://stackoverflow.com/questions/1907312/java-getters-and-setters? — lreeder, Aug 04 '13 at 18:29
Better yet, favor immutability, make all fields final and only provide getters. — Steve Kuo, Aug 04 '13 at 21:10
Java is verbose... must write set and get in the 10 properties — Dorathoto, May 17 '20 at 16:49

score 9 · Accepted Answer · edited Aug 06 '16 at 17:12

9

You should write getters and setters. Or better - let your IDE generate them automatically. Otherwise you break the encapsulation. Also maybe you need just a getter.

Another advantage of using a getter or setter can be doing some checks or preprocessing before returning or setting the field.

Here is a sample code snippet:

private String name;

public String getName() {
   return this.name;
}

public void setName(String name) {
   this.name = name;
}

Optionally you can use http://projectlombok.org/ and write it like this using annotations:

@Getter @Setter
private String name;

The code generation is done compile time.

edited Aug 06 '16 at 17:12

Robert Harvey

178,213
47
333
501

answered Aug 04 '13 at 18:22

Petar Minchev

46,889
11
103
119

2

Thanks, I was secretly hoping for a different answer :) – Dimitar Dimitrov Aug 04 '13 at 18:25
1

@Dimitar Dimitrov - There is a project called `Lombok` to reduce the boilerplate. I will edit my post soon. – Petar Minchev Aug 04 '13 at 18:32
1

And besides encapsulation .. if you have to change internal representation is more flexible .. only have to change inside getter method and clients dont care about internal representation – nachokk Aug 04 '13 at 18:37
@nachokk - Correct, thanks for the addition. – Petar Minchev Aug 04 '13 at 18:38
I am trying to learn, just wondering, do you think it is better to do private String name_; and then public void setName(String name){ this.name_ = name; } – NOT_A_PROGRAMMER May 02 '16 at 13:31

lreeder · Answer 2 · 2013-08-05T02:39:49.553

6

It's better to have getter/setters to return the fields so that you can encapsulate the way the fields are calculated. Although it happens rarely, there may come a time when you want to change something like this:

getBalance()
{
   return this.staticBalance;
}

to this:

getBalance()
{
  return calculateBalance();
}

And the only way in Java to change field behavior without potentially changing tons of code (or worse requiring your API users to change bunches of code) is to use getters and setters.

Other benefits are:

Ability for subclasses to override the behavior
Improved thread safety because you can synchronize access

Writing the boilerplate is tedious, but a good IDE will just generate those methods for you from the field names.

edited Aug 05 '13 at 02:39

answered Aug 04 '13 at 18:29

lreeder

12,047
2
56
65

+1 for explaining WHY the setter and getters are needed – geby Aug 04 '13 at 18:38
You can get rid of `this.` (clutter) – Steve Kuo Aug 04 '13 at 21:11
@SteveKuo I put the `this` on the field to make it stand out as a field since I didn't want to do a full class def, but agree it is clutter for the method call. Dropped it from method call. – lreeder Aug 05 '13 at 02:40

score 3 · Answer 3 · edited May 23 '17 at 10:29

3

You have to create manual functions to do it.

So first, you create a backing field.

private String _backingString

Then you create getters and mutators

public String getBackingString()
{
  return this._backingString;
}

public String setBackingString(String value)
{
   this._backingString = value;
}

It's the Java convention - there's no other way around it. However, you'll be pleased to know most IDEs have tools to generate these. Just google around for your favourite IDEs generator tool.

You can see this SO question on how to do this in Eclipse.

edited May 23 '17 at 10:29

Community

1
1

answered Aug 04 '13 at 18:22

Vaughan Hilts

2,839
1
20
39

I corrected this already when I noticed. :) – Vaughan Hilts Aug 04 '13 at 18:25
7

I know it is a matter of personal style, but this `_` hurts my eyes and it is not the standard. – Petar Minchev Aug 04 '13 at 18:25
2

Please forgive a C# developer - I know the standards but sometimes when context switching on SO so much my brain lets it slip. (like string vs String.. i.e like of the alias). – Vaughan Hilts Aug 04 '13 at 18:26
@VaughanHilts yeah I'm doing `_` as well :) Old habits die hard :) – Dimitar Dimitrov Aug 04 '13 at 18:27
Ah, you are a C# developer, then it is understandable :) – Petar Minchev Aug 04 '13 at 18:28
@PetarMinchev ouch :))) – Dimitar Dimitrov Aug 04 '13 at 18:28
You are not following java code conventions _variable is not c – nachokk Aug 04 '13 at 18:30

score 1 · Answer 4 · answered Aug 04 '13 at 18:23

1

You should do getters and setters for each. Modern IDE's make it easy because they have auto-insert option. Eventually you can create get and set methods in Calendar's class style.

answered Aug 04 '13 at 18:23

Michał Tabor

2,441
5
23
30

score 1 · Answer 5 · answered Aug 05 '13 at 02:53

I often use both approaches, having getters and setters and not. I always use private fields which force the use of getters and setters in my model. Using JPA and Hibernate my model is tied to my DB schema. Then for my DTOs which are normally used for things like RESTful services I use mostly public fields with no getters and setters. These DTOs have no logic and get marshaled out to JSON or created from JSON that's being set from a client so I find no need for the getters and setters. I usually don't end up override equals and hashCode for these too. They are as simple as possible.

So I don't think there's a right or wrong way and it depends on usage.

And if you are going to create you getters and setters let your IDE do the work for you.

score 0 · Answer 6 · edited Aug 04 '13 at 18:29

0

Which IDE are you using? In Eclipse you can create them automatically from the source menu, and their names are derived from the field names. Code:

private String myField; 
public String getMyField()
{
   return this.myField;
}
public void setMyField(String value)
{
   //validation stuff
   this.myField = value;
}

edited Aug 04 '13 at 18:29

Dimitar Dimitrov

14,868
8
51
79

answered Aug 04 '13 at 18:28

Dan94

346
1
3

Getters and Setters in Java convention

6 Answers6

Linked