Restricting the number of objects

[Nittin singla]

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]

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

[Winston Gutkowski]

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

[naved momin]

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

public class SingleTon {

    /**
     * @param args the command line arguments
     */

    private static SingleTon single = null;

    private SingleTon()
    {

    }

    public static SingleTon getIntance()
    {
        if(single == null)
        {
            single = new SingleTon();

        }
        return single;
    }

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 ?

[Ernest Friedman-Hill]

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.

[Jayesh A Lalwani]

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

Singleton single = new Singleton();

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

Singleton singlea = new Singleton();
Singleton singleb = singlea;

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

static Singleton single;
public static Singleton getSingleton() {
   if(single==null) {
      single = new Singleton();
   }
   return single;
}

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]

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

Singleton single = new Singleton();

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

Singleton singlea = new Singleton();
Singleton singleb = singlea;

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

static Singleton single;
public static Singleton getSingleton() {
   if(single==null) {
      single = new Singleton();
   }
   return single;
}

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]

naved momin wrote:

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

public class SingleTon {

    /**
     * @param args the command line arguments
     */

    private static SingleTon single = null;

    private SingleTon() { }

    public static SingleTon getIntance()
    {
        if(single == null)
        {
            single = new SingleTon();
        }
        return single;
    }

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:

public final class SingleTon {
    private static SingleTon single = new SingleTon();

    private SingleTon() { }

    public static final SingleTon getInstance() {
        return single;
    }
}

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:

public enum SingleTon {
    INSTANCE;
}

That way, you have no unnecessary code.

Winston

[Stephan van Hulst]

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]

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]

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