Stop creating object

[deepak carter]

How can i force that object of a class cannot be created.Can i do it by declaring constructor of that class PRIVATE. and what will be the use of this kind of class.

[Manoj Kumar Jain]

You can mark the class as abstract..

[Jeff Verdegan]

deepak carter wrote:How can i force that object of a class cannot be created.Can i do it by declaring constructor of that class PRIVATE.

Yes. The class can still be instantiated, but only from inside the class itself.

and what will be the use of this kind of class.

Utility classes, such as java.lang.Math. There wouldn't be any harm in instantiating such classes, but there's also no value in doing so, and making them instantiable would be misleading.

Another reason for private constructors is when you want to use a static factory method to control object creation.

[Jeff Verdegan]

Manoj Kumar Jain wrote:You can mark the class as abstract..

That's not a good approach. It doesn't clearly express your real intent. Abstract classes are intended to be extended, with the concrete subclass being instantiated. That means we will have an instance of the base class, because child IS-A parent.

[deepak carter]

Suppose i write this:

class A
{
/* some code here*/


}


now i want that no one can create the object of this class.
how can i do this?

[fred rosenberger]

don't give them your .class or .java file.

[dennis deems]

deepak carter wrote:now i want that no one can create the object of this class.
how can i do this?

You can mark the constructor as private, as you suggest in your original post.

[Jeff Verdegan]

deepak carter wrote:Suppose i write this:

class A
{
/* some code here*/


}


now i want that no one can create the object of this class.
how can i do this?

As already stated, and as you knew about in your original post--make sure that class has only private constructors.

[Darryl Burke]

A class with only a private constructor can still be instantiated via reflection. But not if the private constructor throws an Error or Exception.

   private MyClass() {
      throw new Error("Error message here");
   }

[Campbell Ritchie]

Wouldn’t you throw an UnsupportedOperationException there?

[Jeff Verdegan]

Campbell Ritchie wrote:Wouldn’t you throw an UnsupportedOperationException there?

Personally, I'd throw an AssertionError, as that is code that should never be executed. As in, "It shouldn't be possible to get here."

[Campbell Ritchie]

AssertionError, ThreadDeath and probably other subtypes of Error seem to me to occupy a very strange place in their inheritance trees.
But it probably has the same effect irrespective of whichever kind of unchecked Exception you throw. If you had a checked Exception that would be obvious from the documentation because it would display the throws clause.

[Jeff Verdegan]

Campbell RitchieIf you had a checked Exception that would be obvious from the documentation because it would display the[tt wrote: throws [/tt]clause.

I don't think a checked exception is needed here. The fact that it's private should be all the documentation needed.

And if you really want to document it, you can still add a throws clause for the unchecked exception. I suppose with a checked exception you'd at least be forced to add the throws clause. I don't consider a checked exception appropriate here though.

[Campbell Ritchie]

I think we agree you wouldn’t want a checked Exception in those circumstances.

[dennis deems]

Jeff Verdegan wrote:

Campbell Ritchie wrote:Wouldn’t you throw an UnsupportedOperationException there?

Personally, I'd throw an AssertionError, as that is code that should never be executed. As in, "It shouldn't be possible to get here."

But the AssertionError would only occur if we were running with assertions enabled. I think unsupported operation is a better communication of the designer's intent.

[Jeff Verdegan]

Dennis Deems wrote:

Jeff Verdegan wrote:

Campbell Ritchie wrote:Wouldn’t you throw an UnsupportedOperationException there?

Personally, I'd throw an AssertionError, as that is code that should never be executed. As in, "It shouldn't be possible to get here."

But the AssertionError would only occur if we were running with assertions enabled.

Nope. It's the assert keyword that gets turned on and off. If it's on and the assertion fails, then AssertionError is thrown, but AssertionError is just a plain old unchecked exception.

I think unsupported operation is a better communication of the designer's intent.

I think AssertionError is, because it says, "It's supposed to be impossible to get to this code." It's a fine point though, and either one will do the job quite nicely.

[dennis deems]

Jeff Verdegan wrote:

Dennis Deems wrote:

Jeff Verdegan wrote:

Campbell Ritchie wrote:Wouldn’t you throw an UnsupportedOperationException there?

Personally, I'd throw an AssertionError, as that is code that should never be executed. As in, "It shouldn't be possible to get here."

But the AssertionError would only occur if we were running with assertions enabled.

Nope. It's the assert keyword that gets turned on and off. If it's on and the assertion fails, then AssertionError is thrown, but AssertionError is just a plain old unchecked exception.

I think unsupported operation is a better communication of the designer's intent.

I think AssertionError is, because it says, "It's supposed to be impossible to get to this code." It's a fine point though, and either one will do the job quite nicely.

When you said you'd throw an AssertionError, I assumed you meant you'd write "assert false". But you mean instead you'd write "throw new AssertionError". Ew. ;)

[Jeff Verdegan]

Sorry to offend your sensibilities. But not really.

Although I guess an assert statement would be fine too. Sure, it can be turned off at runtime, but that's only gonna matter if somebody is deliberately using reflection to invoke a c'tor they know they shouldn't be, so if you do that and it lets you and stuff breaks, too bad. It's not the kind of thing I would concern myself with protecting against. Honestly, I wouldn't even do anything beyond making the c'tor private. It's easy to get carried away with defensive programming.

[dennis deems]

Jeff Verdegan wrote:Honestly, I wouldn't even do anything beyond making the c'tor private. It's easy to get carried away with defensive programming.

Agreed on both counts.