final methods and classes
in [Java Programming]
|
From: Arne Vajhøj on 11 Oct 2009 19:01 Lionel van den Berg wrote: > Just wondering what arguments there are out there for making methods > and classes final when they are not expected to be overridden/ > extended? Typically I would make them final, but when I'm doing code > reviews I don't raise this as an issue because I see it is relatively > trivial. In my opinion none it is a leftover from the very early days of Java. See: http://www.ibm.com/developerworks/java/library/j-jtp1029.html Arne
From: Rzeźnik on 11 Oct 2009 19:28 On 12 Paź, 00:38, Lionel van den Berg <lion...(a)gmail.com> wrote: > Hi all, > > Just wondering what arguments there are out there for making methods > and classes final when they are not expected to be overridden/ > extended? Typically I would make them final, but when I'm doing code > reviews I don't raise this as an issue because I see it is relatively > trivial. > > Thoughts? Yes, a few :-) First of all: you answered your question already - it is done for preventing subclasses from redefining them. So it is a mechanism of enforcing architectural constraints in code. Let's add, very dangerous one because a mistake here may seriously cripple code re-usability. There were times when it was used as optimization technique - final methods need not use polymorphic dispatching, but this technique's become obsolete, modern VMs know whether overriding method exists or not, so they can (and will) ignore 'final' declarations.
From: Mike Schilling on 11 Oct 2009 20:06 Lionel van den Berg wrote: > Hi all, > > Just wondering what arguments there are out there for making methods > and classes final when they are not expected to be overridden/ > extended? Typically I would make them final, but when I'm doing code > reviews I don't raise this as an issue because I see it is > relatively > trivial. Some classes have not been designed to be extensible (either as a deliberate choice or because the time wasn't taken to make extensibility work correctly.) For instance, a class that has only static members should in general not be subclassed, nor should a class that has complex interactions among its public and protected methods [1]. "final" can signal either of those. Likewise, classes can be designed for only some methods to be extensible. For example, in the programming-by-contract style: public final void method() { // check preconditions ... // do the thing doMethod(); // check postconditions ... } protected abstract void doMethod(); Here you enforce the convention that the method is extended by overriding doMethod() rather than method() by making the former final. That is, you welcome different implementations of what the method does, but you frown on classes that skip the pre- and post-checks. 1. The functionality of such a class can be extended using aggregation with far more safety and robustness.
From: Lew on 11 Oct 2009 21:04 Arne Vajhøj wrote: > Lionel van den Berg wrote: >> Just wondering what arguments there are out there for making methods >> and classes final when they are not expected to be overridden/ >> extended? Typically I would make them final, but when I'm doing code >> reviews I don't raise this as an issue because I see it is relatively >> trivial. > > In my opinion none it is a leftover from the very early days of Java. > > See: > http://www.ibm.com/developerworks/java/library/j-jtp1029.html > > Arne -- Lew
From: markspace on 11 Oct 2009 22:00
Mike Schilling wrote: > Lionel van den Berg wrote: >> Hi all, >> >> Just wondering what arguments there are out there for making methods >> and classes final when they are not expected to be overridden/ >> extended? Typically I would make them final, but when I'm doing code >> reviews I don't raise this as an issue because I see it is >> relatively >> trivial. > > Some classes have not been designed to be extensible (either as a > deliberate choice or because the time wasn't taken to make > extensibility work correctly.) This is the one I would emphasize. "Either design for inheritance or prevent it." Effective Java, I believe, by Joshua Bloch. Inheritance is a sticky issue and can lead to some surprising situations. It's best to consider all the issues involved and to convince yourself that you've addressed each. (Bloch has a whole chapter of "tips" devoted to inheritance issues, iirc.) If you don't go through that process, or you do and decide that you cannot support inheritance, then make the class final. Another issue is multi-threading, thread safety and the whole foreign method bug-a-boo. Use private methods when you can, but if you must, making a public method final is the only way to guarantee that an instance method does not suddenly become a foreign method. |