In what order to dispose the methods of a Java class?

Question

In which order to dispose 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 which order to put the methods so that it is easy to find a method that is being called within another?

Answer 1

That’s taste, there’s no technical reason to choose one way or the other.

However there may be a logic that not everyone will agree, and I myself do not always agree with everything I preach, some questions are very complicated.

Campos

I like to see a class as a data structure first with fields... and then methods, so it’s clear that fields should come before methods, right?

Yeah, more or less, it gets a little more complicated because of the getters and setters, because these tend to become more readable with the field nearby. But there is no consensus and I tend not to mix state with behavior. Here the methods should 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 your problem too, but it is another issue.

In thesis private fields must come before the public. But if you have both, wouldn’t it be better to separate everything that is implementation detail and what is API without worrying about the member type? 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.

Builders

It seems obvious to me that the builders 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 complicating issue), but I find it strange and unusual.

Privados x Públicos

Now begins something more complicated.

If you consider that the fields should come first and they tend to be more private then the private methods should come before the public, right?

But the builders are public (almost always), so broke it. Some people will choose to have private methods before the builders then. I see some sense in it, I’ve 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 later precisely because they would have the public all together (normal builders and methods) and then have the private ones, even if they are separated from the private ones, after all they are very different types of members.

But it’s even more complicated when you have a private contractor. I tend to do before the public builders (when it has, because it is common to have only the private when it exists).

Some people will make blocks and prefer to intermediate private part of the public, and therefore group more the type of member it is (field or method).

What about the protected ones? They should probably be between private and public, if you make this separation.

Some people like to maintain an order of use and declare before what will be used internally within some method algorithm. This is mandatory in some languages that compilation occurs in just one step. But there are circular reference cases, although not direct, so it becomes more complicated.

Some people don’t like to separate any of this, and they think being private is irrelevant. But it seems to be something a little out of the ordinary (which does not mean wrong, the popular is often the wrong, remember that most people are mediocre and make mediocre decisions, but I will not get into the merit, I’m just warning that it could happen in any case, not only in this).

Static members

And it gets more complicated when the static limbs come in. It’s where I least see consensus, some people think it should come last, others first of all.

It may even be that static fields can be separated from instance fields, because they are actually part of another structure.

Some say that the static part should not even be together with 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 that the part of the instance is more important and rarely there are static fields, which makes the methods more utilitarian, if you think it should be something outside the class, then for more in the end makes a lot of sense.

But I have found myself using in the middle of the instance methods, mainly 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, it helps to decide why it is not even before or after 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 :).

And static privates should come before static audiences, right? But it is implementation detail too, and often to use with the instance methods, which makes it more complicated.

There is 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 only utilitarian.

The static builders, if there are any, should come before the normal ones, right? Strange if all the static ones are separated, but it makes some sense.

Abstract methods

The question of abstract methods could be simpler, but it’s not. There are those who think that you should put the methods in order that makes more sense to visualize the object, which you don’t always find something that makes so much sense, and in fact should not have more important methods or that should be used before.

There are those who argue that the abstract should come apart, some think they should come first because it is only part of the contract and not the behavior itself.

There are those who think just the opposite, if it has no behavior for this class it matters little and it should come in a proper order as if it had implementation because in the derived class it maintains more or less the same order.

Virtual methods

Some think you should segregate methods that are not virtual (final). It is more complicated to decide on this, does not seem to have a good reason for it. Maybe it is interesting to adopt the same one that adopted in the abstract.

Implementation of interfaces

In the question it does not speak, but there are those who like to separate the methods that are implementations of interfaces of the others.

And then put her internal methods in the order that’s on the interface, which forces you to look at her source which is not something that should be mandatory and has case that you don’t even have access to) so this part is more complicated.

And as always, some will prefer before or after the others because they are more comforting with a more general API; or because they are more specific to the current object and these are more important.

Be consistent with abstract methods of abstract classes.

Other orders

Within these organizations already established to unpack must put everything alphabetically or in a way that makes sense? The first can make it easier to find in the midst of many, and the second is not always easy to find meaning, but there are cases you have. Do you have methods that you tend to stir more or consult the source more often? These should be before?

It seems certain that all methods of the same name (overload) should be together. Some think you should first have the methods with fewer parameters first, others think you should have the most complete before it is the one that matters most and usually has a de facto behavior, the others would be almost a proxy for the others in most cases (see above I have already spoken on this question of by before who calls other methods).

Some prefer to separate methods that are procedures (returns void) because they are almost always utilitarian, and in fact it is common to be rare and static (if done the right way).

Lucky that Java does not have events, operators, delegates to complicate more :).

Some people like to separate fields that are Amble (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 in case I had one enum or an inner class because it is rarer and more controversial.

I want to stress that some people will give preference to all private and all public before considering another criterion. I have tried to do this and then prioritize other independent ways of being private or public, I could not conclude which is better so far :D

Often the private is a utility of an audience what should make it stay there close, but there are so many other ways that do not preach it that it is not so easy to defend it always.

Generally speaking I having prefer what will be used together posted together.

More

Remembering that interfaces nowadays can have several types of members as well.

In C# it is possible separate parts of code into more than one file which can facilitate the decision if you know how to do well since you do not need to think about the order. But it can be complicated because it is not all in the same file. I don’t like it much.

C# also has region markers, which used to be a beautiful gambiarra most of the time.

I don’t know if there is a comment convention in Java that some IDE adopts to simulate this.

Completion

There may be several motivators for one order or another.

The most important thing is to be consistent, people need to know where everything is.

Did you think I was gonna tell you what to do? The only way to answer this type of question without falling into the GTKY is like this, gives the options and tries to justify, can not say what I use directly, it does not teach.

It is the misfortune of those who have OCD because they cannot find a way that everything fits, something will always seem out of place :D