File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Stop creating object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Stop creating object" Watch "Stop creating object" New topic
Author

Stop creating object

deepak carter
Ranch Hand

Joined: Feb 19, 2011
Posts: 165
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
Ranch Hand

Joined: Aug 22, 2008
Posts: 191

You can mark the class as abstract..


Do not wait to strike till the iron is hot; but make it hot by striking....
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Ranch Hand

Joined: Feb 19, 2011
Posts: 165
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
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10916
    
  12

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


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Bartender

Joined: May 03, 2008
Posts: 4523
    
    5

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


luck, db
There are no new questions, but there may be new answers.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
Wouldn’t you throw an UnsupportedOperationException there?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
I think we agree you wouldn’t want a checked Exception in those circumstances.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
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.
 
Consider Paul's rocket mass heater.
 
subject: Stop creating object
 
Similar Threads
Understanding how this code works
what exactly meant by ANYCLASS.class
object Vs instance
access modifier for constructor ?
.transferFocus()