Is there a best practice for the order to define getters and setters in? There seems to be two practices:
- getter/setter pairs
- first getters, then setters (or the other way around)
To illuminate the difference here is a Java example of getter/setter pairs:
public class Foo {
private int var1,
var2,
var3;
public int getVar1() {
return var1;
}
public void setVar1(int var1) {
this.var1 = var1;
}
public int getVar2() {
return var2;
}
public void setVar2(int var2) {
this.var2 = var2;
}
public int getVar3() {
return var3;
}
public void setVar3(int var3) {
this.var3 = var3;
}
}
And here is a Java example of first getters, then setters:
public class Foo {
private int var1,
var2,
var3;
public int getVar1() {
return var1;
}
public int getVar2() {
return var2;
}
public int getVar3() {
return var3;
}
public void setVar1(int var1) {
this.var1 = var1;
}
public void setVar2(int var2) {
this.var2 = var2;
}
public void setVar3(int var3) {
this.var3 = var3;
}
}
I think the latter type of ordering is clearer both in code and in class diagrams but I do not know if that is enough to rule out the other type of ordering.
The first way. If it’s possible always group together or keep close by related functions that operate on the same members.
If you arrange your code in this way it makes it clearer and easier to refactor, since if one class can be factored out of another that is doing too much, the factorisable piece usually revolves around a specific member variable.
In general it is easier to debug, understand and manipulate code when you can see all on the same page the entire lifecycle of an object/variable. I’d go so far as to say that Code layout based primarily on superficialities like scope and alphabetical order will actually mean you miss opportunities to refactor because you cannot see them.
2
If you are on a team, do what they usually do. Otherwise just pick the one you like more. On the scale of important design choices this is probably somewhere near “which thumb should I use to hit the space bar?”
5
It can also depend on the language. In Java there’s no real advantage to either order, but in C#, for example, you have the concept of “properties”, which group the getter and setter together, so it kind of enforces that ordering. In a language like C++, where you might want different visibility on getters vs. setters (e.g. private setter, public getter), you’d probably do the opposite, since the visibility modifier is given once for multiple methods, rather than individually for each.
As far as I know, there’s no single convention. The Oracle Java Code Conventions section on file organization doesn’t explicitly mention the placement of getters and setters, but it does say:
These methods should be grouped by functionality rather than by scope or accessibility.
This doesn’t provide any guidance – I could argue that either placement meets this criteria.
Something to consider is that modern IDEs allow you to have more abstract views of the structure of your files than as the textual code component. This, coupled with powerful searching tools, should make it easy to navigate files and find the appropriate methods within even large files.
As an example, Eclipse provides an Outline view that let’s you sort and filter methods and fields in different ways, and navigate right to where they are in files. NetBeans had similar functionality, and I’d suspect that most other IDEs do as well.
The only time this might matter is if you are reading the code outside of your IDE. An example might be using an external code review tool or viewing deltas from your version control system.
The best solution would be to simply be consistent across files in a project. Find a standard, document it, and stick to it.
Group the getter and setter for a single field together, in pairs.
Grouping all the getters together and all the setters together makes it hard to tell which fields have just getters or just setters.
When I am reading code or looking for specific functionality I envision a class as having fields, with each field having a getter and a setter. It doesn’t make sense to me for a class to have a getters group and a setters group, each having fields.
2
Ever Java IDE can generate getters and setters for you. Just use that functionality and leave the order of those methods like the IDE created it. This is generated code, don’t touch it unnecessarily.
2