In what order to arrange the methods of a Java class?
In what order to arrange the methods of a Java class?
Whereas a class can have: constructors, static methods, private methods, public methods, abstract methods.
For example:
public class Classe {
public Classe() { ... }
public Classe(int valor) { ... }
public void init() { ... }
public void fazerAlgoPublico() {
fazerAlgoPrivado();
}
public void fazerOutraCoisaPublica() {
fazerAlgoPublico();
}
private void fazerAlgoPrivado() { ... }
}
Or else:
public class Classe {
public Classe() { ... }
public Classe(int valor) { ... }
public void init() { ... }
public void fazerAlgoPublico() {
fazerAlgoPrivado();
}
private void fazerAlgoPrivado() { ... }
public void fazerOutraCoisaPublica() {
fazerAlgoPublico();
}
}
In what order to place the methods so that it is easy to find one method being called within another?
1 answers
This is taste, there are no technical reasons to choose one way or another.
However there may be a logic that not everyone will agree, and I myself do not always agree with everything I preach, some issues are quite complicated.
Fields
I like to see a class as a data structure first of all with Fields... and then methods, then it becomes clear that the fields must come before the methods, right?
Is, more or less, it becomes a little more complicated because of the getters and setters, because these tend to get more readable with the field nearby. But there is no consensus and I tend not to mix State with behavior. Then should the methods go next to the field or the field next to the method?
And it is true that I use another language that this decision becomes easier because it has properties :) what has there its problem too, but it is another question.
In thesis private fields should come before public. But if you have both would it not be better to separate everything that is implementation detail and what is API without worrying about the type of member? It is not simple to answer this, I prefer to leave all fields together. Some people do not have this problem because they have decided that all fields are implementation details and therefore are private.
Some languages even make this separation clearer.
Constructors
It seems obvious to me that the constructors they should come next, after all it is the entrance door of the object. I have seen some people considering that this part is less important and leave at the end (see below another question that complicates), but I find it strange and uncommon.
Private x Public
Now something more complicated begins.
If you consider that Fields should come first and they tend to be more private then private methods should come before public ones, right?
But constructors are public (almost always), so broke it. Some people will choose to have the private methods before the builders then. I see some sense in this, I have already talked about in the previous paragraphs of fields, but I tend to put after the builders.
Some people will prefer to put the private ones after precisely because they would have the public ones all together (constructors and normal methods) and then have the private ones, even if it is separated from the private fields, after all they are types of very distinct members.
But it's even more complicated when you have a private constructor. I tend to do before the public builders (when it has, because it is common to have only the private one when it exists).
Some people will make blocks and prefer to interleave private part of public, and therefore group more the type of member it is (field or method).
And the protected? They should probably be between private and public, if you make this separation.
Some people like to keep an order of Use and declare before what will be used internally within some method algorithm. This is required in some languages that compilation takes place in just one step. But it has the circular reference cases, although not direct, so it gets more complicated.
Some people do not like to separate any of it and think that being private or not is irrelevant. But it seems to be something a little out of the ordinary (which does not mean wrong, the popular many sometimes it's wrong, remember that most people are mediocre and make mediocre decisions, but I will not go into the merit, I'm just warning that it could happen in any case, not only in that).
Static members
And gets more complicated when static members enter. It's where I least see consensus, some people think it should come last, others first of all.
Inclusive it may be that static fields can be separated from instance fields, because in fact they are part of another structure.
There are those who say that the static part should not even be joined by the instance part (some people always use another class), or even more radically it should not even exist.
I prefer everything in the end because it is common for the instance part to be more important and there are rarely static fields, which makes the methods more utilitarian, if you think it should be something outside the class, then for more in the end it does a lot sense.
But I've already caught myself using in the middle of instance methods, especially if the method is private because it would be a utility made to help a public instance method and probably just called there. In C# has even the local function when it is guaranteed that it will only be used by one method, this helps decide why it is neither before nor after it is inside.
If you choose to keep close to use you need to decide whether it will be just above or just below. It's a lot of decision :).
E static privates should come before static publics, right? But it is implementation detail too, and often to use with Instance Methods, which makes it more complicated.
Has another problem since constructors are static methods. Should they be treated differently? I think yes, they are fundamental to the object, the other static ones are just Utilities.
Static constructors, if any, should come before normal ones, right? Strange if all the statics are separated, but it makes some sense.
Abstract methods
The question of abstract methods could be simpler, but it is not. There are those who think that you should put the methods in the order that makes the most sense to visualize the object, which you do not always find something that makes so much sense, and in fact should not have more important methods or that should be used before.
Some argue that abstracts should come separate, some feel they should come sooner because it is only part of the contract and not the behavior itself.
There are those who think just the opposite, if it does not have behavior for this class it does not matter much and it should come in a suitable order as if it had implementation because in the derived class it maintains more or less the same order.
Virtual methods
Some people think they should segregate non-virtual methods (final). It is more complicated to decide on this, it does not seem to me have a good reason for that. Perhaps it is interesting to adopt the same one you adopted in the abstract.
Implementing interfaces
In the question does not speak, but there are those who like to separate the methods that are implementations of interfaces from the others.
And then put her internal methods in the order that is in the interface, which forces you to look at her source which is not something that should be mandatory and you don't even have access to) so this part is more complicated.
E as always, some who will prefer before or after the others because they are more comforting with a more general API; or because they are more specific with the current object and these are more important.
Be consistent with abstract methods of abstract classes.
Other orders
Within these organizations already established to tiebreaker should you put everything alphabetically or in a way that makes sense? The first can make it easier to find in the middle of many, and the second it is not always easy to find a meaning, but there are cases that it has. Do you have methods that you tend to mess around with more or query the source more often? Should these be before?
It seems right to me that all methods of the same name (overload) should be together. Some think it should have the methods with the least parameters First, others think it should have the most complete before that is what matters most and usually has a behavior in fact, the others would be almost a proxy for the rest in most cases (see above that I have already talked about this question of by before who calls other methods).
There are those who prefer to separate methods that are procedures (returns void) because they are almost always utilities, and in fact it is common to be rare and static (if done the right way).
Lucky that Java has no events, operators, delegates to complicate more :).
Some people like to separate fields that are lambdas (I don't even know if you can in Java, I think so). They are Fields whose value is a method.
I didn't even get into the case of having a enum or an inner class because it's rarer and more controversial.
I want to reinforce that some people will give preference to all private and all public before considering another criterion. I have already tried to do this and then prioritize other independent ways of being private or public, I have not been able to conclude which one is better so far: D
Often the private is a utility of a public what should make him stay around, but there are so many other ways that do not preach this that it is not so easy to defend it always.
Generally speaking I having prefer what will be used together posted together.
Plus
Remembering that interfaces nowadays can have various types of members as well.
In C# it is possible to separate parts of the code in more than one file which can facilitate the decision if you know how to do well since you do not have to think in order. But it can be complicated by not being all in the same file. I don't like it very much.
C # also has Region markers, which is usually a beautiful gambiarra most of the time .
I don't know if there is comment convention in Java that some IDE adopts to simulate this.
Conclusion
Can have multiple motivators for one order or another.
The most important thing is to be consistent, people need to know where everything is.
Thought I were you gonna tell me what to do? The only way to answer this type of question without falling into GTKY is like this, it gives the options and tries to justify, can not speak what I use directly, it does not teach.
Is the misfortune of those who have OCD because they can not find a way that everything fits, something will always seem out of place :D