2

I'm finishing a project which has like 100-150 classes and...puff..many, many methods. For the development, I've used the "Use modifier 'final' where possible" save action since the beginning. But that lets my methods (and the classes which I've created manually instead of with the assistant) without the final/abstract keyword they deserve. And really, I don't want to go through every class and method declaration to manually complete them. I'm sure there's a way to tell to eclipse 'do it for me, in the most restrictive way (i.e. if a class is never instantiated, set it as abstract, otherwise, if never extended, set it as final, and otherwise nothing, and something similar - without the abstract part, obviously - for the methods).

Am I right? And if so, which is that way?

Jorge Antonio Díaz-Benito
  • 1,036
  • 12
  • 32
  • 1
    Personally I wouldn't worry about "final". It won't make much difference to your application in the end. If you're worried about performance I'd use a profiler and look for bottlenecks. I always run jvisualvm.exe when I'm about to release a new program. Remember this: To quote Donald Knuth: "Premature optimization is the root of all evil" -- which is actually a paraphrase of the wellknown saying: "The road to hell is paved with good intentions." – DAB Mar 15 '13 at 12:04
  • +1 a good question - made me think – kostja Mar 15 '13 at 15:52

2 Answers2

3

It may be problematic to enforce your heuristics. This may be the reason that eclipse does not implement them.

Setting all classes that are not extended in your code to final - how can the IDE know if they are intended to be extended elsewhere? Make them final only if you really intend to prohibit extension.

The same goes for abstract - there is no way for the IDE to know if you are writing a framework, or just a domain model .jar, where there never will be any initialization. Making the entities abstract automatically may shoot you in the foot later.

This is rarely the case for variables, so this heuristic eclipse can do.

EDIT I think I have to elaborate a bit on my reasoning.

Adding the final modifier is not problematic for variables because they are mostly localized - they live within the scope of the code under your control. There are rarely modyfiable variables that are visible to 3rd party code and can be modified wihtout calling a method.

If the final modifier on a variable is excessive, it's impact will be limited to your code, and you will probably notice it fast. So the worst case is that you will have to open the file and remove the modifier.

Things are different for classes - many of them are public and thus accessible to 3rd party code. If you declare all classes that are not instantiated in your code as abstract, you will effectively prohibit everybody else from instantiating it - and this time you will not even know. So the worst case here is that somebody else will not be able use your code. That's why I would not automate it - most of the time you would want 3rd party code to be able to instantiate the classes that you have defined.

There is however a heuristic about when to make a class final - when a class has only static methods. Some tools like PMD and Checkstyle know that, and will tell you about it. This option would actually fit well into eclipse, but is unfortunately not implemented.

As to making classees final per default - andersoj and many others adhere to the principle "design for inheritance or prohibit it" - i think it was introduced by Joshua Bloch in his "Effective Java" book. Others argue that it would violate the open-closed principle to "seal" all classes by default. I tend to the latter.

kostja
  • 60,521
  • 48
  • 179
  • 224
  • I don't get to understand the "problematic" of my heuristics. eclipse finds impossible to determine if a class should be declared as final, but he does so with, as you said, variables, which may later require the modifier to be removed from them (and I find it very often to call it 'strange', as you say). BTW this, basically, means that the answer to my question is no, isn't it :( ? @kostja – Jorge Antonio Díaz-Benito Mar 15 '13 at 15:07
  • 1
    @JorgeAntonioDíaz-Benito - tl;dr - it is 'no'. Eclipse can't do it yet. I have tried to explain my reasoning better - please see the edit. – kostja Mar 15 '13 at 15:38
  • Even after considering your edit, I keep thinking it wouldn't heart as an optional 'Save Action' or something, so it can be activated only when you want it (as now happens with variables or parameters). It's up to eclipse developers anyway, thanks. – Jorge Antonio Díaz-Benito Mar 15 '13 at 15:41
  • @JorgeAntonioDíaz-Benito - Sure, there is no technical reason against it, only opinions :) You could create an eclipse plugin yourself that does what you want, but the initial effort is quite substantial. – kostja Mar 15 '13 at 15:48
2

In the case of final classes, you need only mark the class final, you do not need to mark each method... Perhaps that helps a bit. As opposed to kostja's answer, I would say to mark your classes as final by default, and only leave off final if you have explicitly designed for extension. This should be the exceptional case anyway ("prefer composition to extension") unless you are doing something specialized.

Community
  • 1
  • 1
andersoj
  • 22,406
  • 7
  • 62
  • 73
  • _In the case of final classes, you need only mark the class final, you do not need to mark each method..._ this means there's no outstanding difference at all from marking the methods in a final class as final to not doing it? @andersoj – Jorge Antonio Díaz-Benito Mar 15 '13 at 15:06
  • Nope, no difference. See for instance http://docs.oracle.com/javase/tutorial/java/IandI/final.html If you declare a class final, then it cannot be subclassed at all, and therefore the methods cannot be overridden. – andersoj Mar 15 '13 at 18:36