Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > A truly uninstantiable class?

Reply
Thread Tools

A truly uninstantiable class?

 
 
Ian Pilcher
Guest
Posts: n/a
 
      10-13-2005
Just wondering if it's really impossible to instantiate or extend the
following class:

package testing;

public abstract class BagOfStaticMethods
{
/** Prevent subclassing. */
private BagOfStaticMethods() {}
}

Thanks!

--
================================================== ======================
Ian Pilcher http://www.velocityreviews.com/forums/(E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
 
 
 
Ross Bamford
Guest
Posts: n/a
 
      10-13-2005
On Thu, 13 Oct 2005 22:11:54 +0100, Ian Pilcher <(E-Mail Removed)>
wrote:

> Just wondering if it's really impossible to instantiate or extend the
> following class:
>
> package testing;
>
> public abstract class BagOfStaticMethods
> {
> /** Prevent subclassing. */
> private BagOfStaticMethods() {}
> }
>
> Thanks!
>


Using normal techniques, you would be unable to instantiate or extend this
class from without as written. However, if your reason for going
'abstract' instead of 'final' is to allow an anonymous subclass to be
returned from a static method, then be warned that you will get a second,
package-private constructor if you do that.

Otherwise, 'final' with the private constructor would be a better bet I
think.

--
Ross Bamford - (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      10-14-2005
On Fri, 14 Oct 2005 00:05:49 +0100, "Ross Bamford"
<(E-Mail Removed)> wrote or quoted :

>Otherwise, 'final' with the private constructor would be a better bet I
>think.


Constructors cannot be overridden even when you use the same name and
signature in a subclass. So in that sense all constructors are final
anyway..

All private methods are automatically final.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-14-2005
On Thu, 13 Oct 2005 16:11:54 -0500, Ian Pilcher
<(E-Mail Removed)> wrote or quoted :

> package testing;
>
> public abstract class BagOfStaticMethods
> {
> /** Prevent subclassing. */
> private BagOfStaticMethods() {}
> }


I'd think the private constructor should suffice. The use of abstract
gives off the false implication you are SUPPOSED to extend the class
to complete it.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
Owen Jacobson
Guest
Posts: n/a
 
      10-14-2005
On Fri, 14 Oct 2005 02:43:47 +0000, Roedy Green wrote:

> On Fri, 14 Oct 2005 00:05:49 +0100, "Ross Bamford"
> <(E-Mail Removed)> wrote or quoted :
>
>>Otherwise, 'final' with the private constructor would be a better bet I
>>think.

>
> Constructors cannot be overridden even when you use the same name and
> signature in a subclass. So in that sense all constructors are final
> anyway..
>
> All private methods are automatically final.


I believe he was referring to declaring the class 'final' (as opposed to
'abstract', as in the original post), not the constructor. Comme ša:

public final class Foo {
private Foo () {
assert false: "Uninstantiable?";
}
}

 
Reply With Quote
 
Ian Pilcher
Guest
Posts: n/a
 
      10-14-2005
Roedy Green wrote:
> I'd think the private constructor should suffice. The use of abstract
> gives off the false implication you are SUPPOSED to extend the class
> to complete it.


Yeah. For some reason, I got obsessed with the fact that private
constructors can be invoked via reflection. Using an un-extendable
abstract class seemed like a way around this.

Reading the Javadoc for Constructor.newInstance, it looks like it just
throws an InstantiationException if it is invoked on a Constructor whose
underlying class is abstract. A final class with a private constructor
that throws an InstantiationException seems like a more straitforward
approach.

--
================================================== ======================
Ian Pilcher (E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
Ross Bamford
Guest
Posts: n/a
 
      10-14-2005
On Fri, 14 Oct 2005 03:43:47 +0100, Roedy Green
<(E-Mail Removed) > wrote:

> On Fri, 14 Oct 2005 00:05:49 +0100, "Ross Bamford"
> <(E-Mail Removed)> wrote or quoted :
>
>> Otherwise, 'final' with the private constructor would be a better bet I
>> think.

>
> Constructors cannot be overridden even when you use the same name and
> signature in a subclass. So in that sense all constructors are final
> anyway..
>
> All private methods are automatically final.
>


I pretty obviously meant final, instead of the OPs reference to abstract,
_on the class_ , and a private constructor.

And how on earth do you use the same name for a constructor on a subclass.
Tell me, because I want to know.

--
Ross Bamford - (E-Mail Removed)
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-14-2005
On Fri, 14 Oct 2005 08:15:25 +0100, "Ross Bamford"
<(E-Mail Removed)> wrote or quoted :

>And how on earth do you use the same name for a constructor on a subclass.
>Tell me, because I want to know.


you refer to it as super in your subclass constructor. I was just
trying to point out that "final" constructors was not a useful
concept.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
Ross Bamford
Guest
Posts: n/a
 
      10-14-2005
On Fri, 14 Oct 2005 08:44:41 +0100, Roedy Green
<(E-Mail Removed) > wrote:

> On Fri, 14 Oct 2005 08:15:25 +0100, "Ross Bamford"
> <(E-Mail Removed)> wrote or quoted :
>
>> And how on earth do you use the same name for a constructor on a
>> subclass.
>> Tell me, because I want to know.

>
> you refer to it as super in your subclass constructor. I was just
> trying to point out that "final" constructors was not a useful
> concept.


Well, granted, 'final' isn't a valid modifier for a constructor (which is
at least part of why I didn't suggest it ). But putting aside the whole
question of whether a constructor even has a name (apart from <init> if
you're picky), I think any reasonable person would look at any constructor
and, if asked it's 'name', give the name of the class upon which it is
declared. Wouldn't they?

In other words, I don't think someome looking at a class AnotherClass, a
subclass of SomeClass, would upon seeing a super() call inside the
constructor, think "Oh okay, so that constructor's called 'SomeClass'".

The specification for a constructor stipulates a 'SimpleTypeName' (i.e.
unqualified class name) between modifiers and parameters. I've always
thought of it more as the return type for an unnamed method, than a name
for an untyped method (not exactly right - constructors are void - but it
works as an abstraction).

--
Ross Bamford - (E-Mail Removed)
 
Reply With Quote
 
Stefan Schulz
Guest
Posts: n/a
 
      10-14-2005
On Fri, 14 Oct 2005 03:27:43 +0000, Owen Jacobson wrote:

> I believe he was referring to declaring the class 'final' (as opposed to
> 'abstract', as in the original post), not the constructor. Comme ├ža:
>
> public final class Foo {
> private Foo () {
> assert false: "Uninstantiable?";
> }
> }


On an unrelated note, why does java.lang.Class offer a private constructor
that never throws any exception, but handles it specifically in
Constructor.setAccessible(boolean)? The constructor might just as well
throw the SecurityException when invocation is attempted.

--
You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Truly Sign out a user Chris Kettenbach ASP .Net 2 10-15-2005 03:13 AM
Techniques for truly reusable structures in XML schemas Steve Jorgensen XML 0 09-08-2005 06:44 AM
[OT] Truly an MCNGP? T-Bone Microsoft Certification 0 11-05-2004 02:43 PM
Prospect of MCSE truly frightening Julian Ford MCSE 14 04-05-2004 04:57 PM
Re: truly abstract (platform independent) pathnames Harald Hein Java 9 08-17-2003 01:01 PM



Advertisments