Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Restricting the number of objects

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 21971
106
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make all of the constructors private, and add static factory methods that return instances as you see fit.
 
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 692
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ?
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 692
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Saloon Keeper
Posts: 12129
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 12129
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
incandescent light gives off an efficient form of heat. You must be THIS smart to ride this ride. Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic