final/package-private underused

[G. Ralph Kuntz, MD]

Step on my soapbox... :-)

I believe that the "final" keyword is underused in Java. I have
gotten into the habit of using it on EVERY method parameter, instance
variable, and local variable unless I have reason not to do so. I
also use it on class definitions although one could argue that that
defeats the idea behind code reuse (I have the source code and can
change it to not be final if necessary).

I also believe that package-private is WAY underused. All of my
methods are declared without "public" unless they must be visible
outside of the package.

What do others think?

[Raymond DeCampo]

G. Ralph Kuntz, MD wrote:

Step on my soapbox... :-)

I believe that the "final" keyword is underused in Java. I have
gotten into the habit of using it on EVERY method parameter, instance
variable, and local variable unless I have reason not to do so. I
also use it on class definitions although one could argue that that
defeats the idea behind code reuse (I have the source code and can
change it to not be final if necessary).
I mostly agree with you, although I stop short of declaring method
parameters final. Also, I do not think it is a good idea for class
declarations. One should not need to change the class you wish to
extend in order to extend it, that defeats the purpose of re-use via
inheritance. (Although re-use via inheritance is overrated.)

I also believe that package-private is WAY underused. All of my
methods are declared without "public" unless they must be visible
outside of the package.

I disagree with you here. I try to avoid package level access
completely. (I assume here that you mean non-private methods when you
say "all of my methods...") I like to keep classes self-contained. If
another class needs access to something in my class it should be public.
Otherwise I feel you've broken encapsulation.

Rebuttals?

Ray

--
XML is the programmer's duct tape.

[G. Ralph Kuntz, MD]

Raymond DeCampo <rd******@spam.twcny.spam.rr.spam.com.spam> wrote in message news:<nX*******************@twister.nyroc.rr.com>. ..

G. Ralph Kuntz, MD wrote: .... I mostly agree with you, although I stop short of declaring method
parameters final. Also, I do not think it is a good idea for class
declarations. One should not need to change the class you wish to
extend in order to extend it, that defeats the purpose of re-use via
inheritance. (Although re-use via inheritance is overrated.)
.... I disagree with you here. I try to avoid package level access
completely. (I assume here that you mean non-private methods when you
say "all of my methods...") I like to keep classes self-contained. If
another class needs access to something in my class it should be public.
Otherwise I feel you've broken encapsulation.

Rebuttals?

Ray

I agree on the issue with private classes and many times have had to
go back and change them to public, but why do you not use final on
method parameters? It has save my butt on more than one occasion
where I entered

void myMethod(final int someVariable) {
someVariable = ...
}

where I meant to enter

this.someVariable = ...

(One could argument against naming locals/parameters with the same
names as instance variables).

Of course, you are correct about the "non-private" -- I always use the
most restrictive "protection" that I can --
private->protected->"package private"->public.

I have an easier time finding bugs when I know that the only calls to
a method are inside the current class, package, etc.