Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Stop creating object

 
deepak carter
Ranch Hand
Posts: 165
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 195
Java Linux Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can mark the class as abstract..
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 165
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 12020
25
Chrome Java Linux
  • 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
don't give them your .class or .java file.
 
dennis deems
Ranch Hand
Posts: 808
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5115
11
Java Netbeans IDE Opera
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A class with only a private constructor can still be instantiated via reflection. But not if the private constructor throws an Error or Exception.
 
Campbell Ritchie
Sheriff
Pie
Posts: 47258
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wouldn’t you throw an UnsupportedOperationException there?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47258
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47258
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think we agree you wouldn’t want a checked Exception in those circumstances.
 
dennis deems
Ranch Hand
Posts: 808
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 808
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 808
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic