You can do this, but it doesn’t usually make much sense in practice.
A method, even if it is the main
, ideally has a connection with the class it is in. This has a direct relationship with the principle of single responsibility, with the principle of high cohesion and with the low coupling principle.
Therefore, the ideal place to place the main
depends heavily on the architecture and structure of your program. If there is a class that naturally already represents your entire program being run, it makes sense that the main
stay there to maintain high cohesion and low coupling, even if this class is abstract. However, it would hardly make sense for an abstract class to represent its program as a whole, and therefore it would hardly make sense. Also, if the class representing your program as a whole is an abstract class, it would probably be doing too much, violating the principle of sole responsibility.
In cases where there is no class representing the program as a whole, you would put the method main
in a class just for him. The sole responsibility of this class would be to be the entry point of the program. Naturally, it would make no sense for this class to be abstract.
In fact, in practice the concept of abstract class itself is something that has been questioned as a result of the concept of inheritance of implementation being questioned. Inheritance introduces a strong coupling from the subclass to the superclass and is something that can almost always be eliminated with refactoring and replaced by composition. Type inheritance is worked with interfaces. From Java 8, you can have implementations default
and static interfaces, which further reduces the need to use inheritance and thus the need to use abstract classes by providing implementation inheritance also through interfaces.
In short, if you’re concerned about good programming practices, you might end up with a project where there will be no abstract class (or very few left), and therefore there would be none of them where you would put the main
.
In your specific case, it seems you have Diretor extends funcionario
. Turns out it would be better than Funcionario
had a method public Cargo getCargo()
and then you would have public class Diretor implements Cargo
. This would make the structure of your project more organized and eliminate heritage and with it the need to have abstract classes.
Also, the fact of main
be in class funcionario
demonstrates that there has been a violation of the principle of sole responsibility in this class. The fact that main
probably use many other things besides employee (especially when coupling the superclass in the subclass instead of the other way around) also demonstrates that the coupling is high rather than low and the cohesion is low rather than high.
So your question is a bit of a XY problem. The method main
being in an abstract class is a bad Smell, but in fact "the hole is lower".
Define "good programming practice" and we can start talking about it.
– Jéf Bueno
The question here is: why would someone do this? What is the point of putting an application’s entry point into an abstract class? More than that: what is the sense of putting in a class that seems (by name) to have been created to interact with the application data?
– Jéf Bueno
The main question here is, Why do you want to focus on an abstract class? I can’t imagine any situation for this.
– user28595
@Articuno LOL It seems that we agreed
– Jéf Bueno
Although it is certainly not the best question of the site, I consider a clear question (and therefore I disagree with the closing vote) and also consider a legitimate question (and therefore I disagree with the negative votes).
– Victor Stafusa