I suspect that there are many correct answers, but I'd speak against
"abstract".  The purpose of "abstract" is not to prevent instantiation, the
purpose of "abstract" is to require that the class be extended, which is not
the purpose here.

A private (NOT protected!  that is useless to prevent class extension)
constructor, possibly with a 'final' class decoration, is the canonical
approach.  Josh Bloch talks about the idiom in /Effective Java/, IIRC.

Abstract is like an interface that can contain some implementation.
It's useful when the subclasses will be known to have some common
implementation methods. In this case an abstract class can contain
common implementation, where an interface would require that each
subclass duplicate the common implementation.

In my opinion (and I'm sure others will feel differently), final is
for classes such as Math, where it is VERY certain that there won't be
any extensions or implementations. I have never run into a situation
where I have a class that can be instantiated, but I NEVER want to
extend it. I've had the opposite though: classes that WERE final but
had to be modified to be non-final. The alternative to that would have
been a lot of copy-and-paste. ;)
But maybe one day I WILL want to make a class final... ;)

...

...

It's not really a class. It's a namespace, that happens to be
implemented using a class declaration.

The "no instantiation" part should be enforced using a private
constructor (documenting that that is its sole purpose).
A private constructor (and no other constructors) also suffices
to prevent anybody from extending the class.

I'd add "final" just to make it clear that it can't be extended,
so you wouldn't have to deduce it from the missing constructor.

I wouldn't add "abstract", as that suggests that it should be
extended.

/L

I would subject first off: The documentation should be the first place one  
goes to figure out how to use a class. If you document the intended use  
case ("this class is not intended to be instantiated"), then you've clear  
from users making expectations.

A good IDE will probably issue an excessive/unused code warning for  
writing a constructor that never gets called. Of course, you can always  
add a @SupressWarnings, or just turn off that warning.

Does the object "work" if you instantiate it? Since presumably the result  
of "new MyObject()" is not much different from "new Object()", then the  
object "works" (meaning, to your knowledge, your instance methods won't  
throw Errors).

You should also ask yourself: how will these rules change in the next  
major revision of this class? What sort of support would that update need  
to offer your current version? If you might need to expose your class as  
subclassable for internal implementations in the future, then it's  
probably a good idea to mark the class final until that time.

From the other side of the table: In general, it is considered bad  
practice to call a static method like you would an instance method  
(myObject.staticMethod). Fortunately, when JUnit was designed (to pick one  
example), this principle wasn't followed to the letter, allowing the test  
developer to write

public void testMyMethod() throws Throwable {
    assertEquals(55, MyClass.myMethod(5));
}

rather than the more verbose:

public void testMyMethod() throws Throwable {
    Assert.assertEquals(55, MyClass.myMethod(5));
}

You might even want to go hogwild:

public void testMyMethod() throws Throwable {
    MyClass MC=new MyClass();    //non-production constructor; alias for code  
clarity only

    assertEquals(55, MC.myMethod(5));
}

This is of course a mute point with the "import static" mechanism in Java  
1.5, which is the preferred way to reference statics without the class  
prefix. Rather, consider this a scenario that should qualify as an  
exception from the general rule: being verbose is redundant, and henders  
the readability of the test's parameters and expected results.

Likewise, another developer could come across a routine using  
reflection/interrogation in a "bean-esk" way to do something useful:

public void remotelyCallFooMethods(Object o) throws Exception {
    for (Method m : o.getClass().getMethods())
        {
        if (m.getName().startsWith("foo"))
            executeOnRemoteHost(m, o);
        }
}
/**
* calls m.invoke(o), but on a remotely attached VM. Supports both instance  
& static methods
*/
public Object executeOnRemoteHost(Method m, Object o)

Probably not useful for your type of static methods, but as this is a  
theoretical case, somebody might run into it.

So, with those points presented, I stick with declaring classes like these  
"abstract". Other programmers still get to use "import static", for  
convenience. If the other fellow has a *really* compelling reason that I  
did not envision to instantiate this object, then it is only a  
inconvenience:

MyClass o=new MyClass() { };

And hopefully they scratched their head, revisited the docs, and were  
still convinced that there was a good reason to make an exception to a  
general rule.

For technique, I would stick to the principle that writing additional code  
for the express purpose of reducing functionality and/or limiting code  
reusability is wastefull. Error checking is great, just don't go out of  
your way to wall yourself off from unconsidered usecases with brick &  
mortar.

HTH,

-Zig

On Thu, 6 Dec 2007 06:06:42 -0800 (PST), Todd
<todd.heidenthal@lmco.com> wrote, quoted or indirectly quoted someone
who said :

abstract to me implies you are SUPPOSED to extend the class before
you.

final means it would not make sense to extend the class.  IntelliJ
Idea encourages the use of final to mean "there is no class that
extends this one, for now".

Neither condition is satisfied. So I would leave both attributes out.

I would however give it a dummy private constructor as an indicator it
is not for instantiation.

final gives you no speed improvement for static methods.  They are in
a sense already final.