wood burning stoves 2.0*
The moose likes Java in General and the fly likes Restricting the number of objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Restricting the number of objects" Watch "Restricting the number of objects" New topic
Author

Restricting the number of objects

Nittin singla
Greenhorn

Joined: Jul 02, 2011
Posts: 24
Hi,

I have a requirement that i want to restrict the number of objects that get created for a class. How can i do that?

TIA
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19656
    
  18

Make all of the constructors private, and add static factory methods that return instances as you see fit.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Nittin singla wrote:I have a requirement that i want to restrict the number of objects that get created for a class. How can i do that?

And further to what Rob said, how you restrict those objects will depend on what they are/do. If they are all clones of each other, a blocking queue or even an array might do; if it is a cache of some sort, you might want to look at LinkedHashMap.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 688

Rob Spoor wrote:Make all of the constructors private, and add static factory methods that return instances as you see fit.


is that all you mean mr. rob ?
but one thing is not clear with me is ...this singleton pattern is use to restrict the no of object being created of a particular class
but i can call a static method with its class name from any other class any number of times ...so if i call a static method thrice from three different classes
i would end up with 3 objects returned from this static method ..so how we can say that we are restricting the number of objects created here to 1 ?
can you explain me ?


The Only way to learn is ...........do!
Visit my blog http://inaved-momin.blogspot.com/
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

naved momin wrote:so if i call a static method thrice from three different classes
i would end up with 3 objects returned from this static method


No, you wouldn't. The first time the method is called from anywhere, an object is created, saved in a static variable, and returned. No matter how many more times the method is called, it will return the same object stored in that variable; it will not create any more.


[Jess in Action][AskingGoodQuestions]
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2275
    
  28

No, what the factory method is returning is a reference to the object. In Java, you always have a reference to an object, you never have the actual object. When you do this



There are 2 things happenning here. First it creates an object of type Singleton on the heap. Then it puts a reference to the newly created object in the variable named single. When you call a method on single, the compiler automatically generates code to find the object in the heap via the reference and call the method on the object. This happens behind the scenes, and logically, the reference to the object behaves like it was the object, but in reality, it's not the object.

So, let's say you do this



Here you created a new object on the heap and put the reference to that object in single a. In the next line, you copied the reference, you didn't make a new object. Calling a method on singleb will be equivalent to calling the method on singlea, because they are 2 references pointing to the same object


So, now when you have this


Here, the object is just created once. Because new Singleton is called only if single was null. Once single = new Singleton() is called single stops being null since it will have a reference to the new created object on the heap. So, first time you call the function, it will create the object put it on the heap and return a reference to that object. Next time, it will only return the reference to the same object. Please note that a reference is returned, not the object. So, calling it 3 times will lead to 3 references to the object, but there will be only 1 object.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 688

Jayesh A Lalwani wrote:No, what the factory method is returning is a reference to the object. In Java, you always have a reference to an object, you never have the actual object. When you do this



There are 2 things happenning here. First it creates an object of type Singleton on the heap. Then it puts a reference to the newly created object in the variable named single. When you call a method on single, the compiler automatically generates code to find the object in the heap via the reference and call the method on the object. This happens behind the scenes, and logically, the reference to the object behaves like it was the object, but in reality, it's not the object.

So, let's say you do this



Here you created a new object on the heap and put the reference to that object in single a. In the next line, you copied the reference, you didn't make a new object. Calling a method on singleb will be equivalent to calling the method on singlea, because they are 2 references pointing to the same object


So, now when you have this


Here, the object is just created once. Because new Singleton is called only if single was null. Once single = new Singleton() is called single stops being null since it will have a reference to the new created object on the heap. So, first time you call the function, it will create the object put it on the heap and return a reference to that object. Next time, it will only return the reference to the same object. Please note that a reference is returned, not the object. So, calling it 3 times will lead to 3 references to the object, but there will be only 1 object.

thanks mate
you have preety good skills
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

naved momin wrote:
Rob Spoor wrote:Make all of the constructors private, and add static factory methods that return instances as you see fit.


is that all you mean mr. rob ?

Close (at least for a singleton class), except that the above is NOT Thread-safe. Unless the cost of creating the object is very high, you're usually better off just initializing it directly, viz:Oh, and BTW, in many cases the best way to define a class with a limited number of instances is to make it an enum, eg: That way, you have no unnecessary code.

Winston
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3605
    
  14

While I agree with the fact that lazy initialization is often unnecessary, I should point out that thread safety often is unnecessary as well.

In this case thread safety is trivial, but you shouldn't go out of your way to make classes thread-safe unless you specifically design them to be used by multiple threads at the same time. Just slap a warning in your contract that the methods of the class are not safe.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stephan van Hulst wrote:While I agree with the fact that lazy initialization is often unnecessary, I should point out that thread safety often is unnecessary as well.

In this case thread safety is trivial, but you shouldn't go out of your way to make classes thread-safe unless you specifically design them to be used by multiple threads at the same time...

Totally agree with you in general, but in the case of a singleton it is rather inextricably tied up with it, since everyone will be using the same object.

Winston
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3605
    
  14

Not necessarily at the same time. For instance, you can still use the Logger API (which uses instance control, of which the singleton is a special case) just fine, in a completely single-threaded application.

I don't know from the top of my head whether it's thread-safe, but if it wasn't, it would still be useful in a multi-threaded application as long as the application provides its own synchronization. I firmly believe that the responsibility of thread-safety should be left as much as possible to the classes that actually know that the application is going to be multi-threaded.

This of course is a discussion separate from the original poster's problem :P
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Restricting the number of objects
 
Similar Threads
Convert SQL to Criteria please
count the number of objects
Pass by Value (Method arguments)
"Number Of Objects in Heap"
reusability of object