How restrict only 3 objects for class?

[sujitha reddy]

Hi,
How to restrict number of objects for a class example 2 objects or 8 object.Create only 3 objects not more than that its not be taken.

[Edwin Dalorzo]

You could add a static counter to the class, and when it reaches the maximum count you can throw an exception in the constructor.

Or you can use a Singleton pattern. It is typically used to retrict the number of objects created by a class to one, but it could be used just as well to restrict the number object created by the class to any other amount.

[Ilja Preuss]

Why would someone create more than three instances, and what bad would happen as a consequence? Do you really need to enforce the "only 3 instances" constraint?

[Sudhakar Reddy Kurakula]

Hi,
This is the following code.

  
    public class Example
    {
      private Example()
      {
      }
     private static Example obj[3];
     Static int i=0;
 
     public static Example  getInstance()
     {
 
            if((i<3)&&(obj[i]==null))
             {
              obj[i]=new Example();
               return obj[i++];
             }
             else{
                    if(i==3)
                       i--;
                     return obj[i];
                    }
       }

Cheers
Sudhakar Reddy
M.C.A(2006)
Satyam.
9989223696.

[ November 06, 2006: Message edited by: Paul Sturrock ]
[ November 06, 2006: Message edited by: Sudhakar Reddy Kurakula ]

[Paul Sturrock]

The above code will not restrict the number of instances of Example to 3.

Example one = Example.getInstance();
Example two = Example.getInstance();
Example three = Example.getInstance();
Example four = new Example();

[steve souza]

   
Example four = new Example();
 

The constructor is private, so the above could not be done

[Jim Yingst]

Well, it looks like the post has been edited a couple times, first by Paul S (adding code tags maybe?), then by Sudhakar. I assume Paul's comment probably reflects what the code looked like at the time he made the comment. Certainly the "Static int i=0;" and random changes in indentation seem to indicate that there might have been other errors present originally, as this code wouldn't even compile. Unless it changes again after I write this...

[Bear Bibeault]

A "tringleton"?

[steve souza]

That implementation of the 'tringleton' pattern seems return the 3rd element in all invocations except the first two. Perhaps a better implementation would be the 'random tringleton' or even the 'round-robin tringleton'. Also, the variable 'i' should probably be synchronized, so maybe the 'synchronized round-robin tringleton' is in order.

[Dan Bizman]

Correct me if I'm wrong, but I believe there are three other ways (not including a separate VM) that the class could still be instantiated.

1. Serialization
2. Loaded by different class loaders
3. Synchronization error

With #1, they take the object (a singleton), serialize it with two diff. ObjectOutputStreams and then deserialize both into the same VM and voila - two objects of that type.

With #2, if you have classloaders not in the same hierarchy, they will treat them as completely different classes (not sure how to solve this one) and allow you to create 3 copies for EVERY classloader you create (outside each other's hierarchy).

(with #3, since the static method has no synchronization, two singletons will be created at the same time if while one's constructor is running, simultaneously another thread calls the method.)

[Jesper de Jong]

Originally posted by steve souza:
The constructor is private, so the above could not be done

Yes, because Sudhakar modified his post after Paul posted his response... :roll: originally the private constructor was not there.

[Jim Yingst]

[Dan]: 1. Serialization

To be fair, serialization is only an issue if the class implements Serializable, which in the code shown, it doesn't. If it did, then it would be necessary to implement a readResolve() method to control how (or whether) deseriallization takes place. I can't really think of any reason why it might be a good idea to allow a class like this to implement Serializable in the first place though, as it seems inherently contradictory with the idea of limiting instances.

[Dan]: 3. Synchronization error

As Steve Souza pointed out, though not in detail.

Another possible way to get an extra instance is with reflection, which can often be used to violate the private access modifier. Just call Constructor.setAccessible(true) - unless there's a SecurityManager configured to prevent this. Even this, though, can be prevented by coding the constructor to throw an exception if there are already three instances created. Under most circumstances that strikes me as being unnecessarily paranoid, but the option's there I suppose.

[Ilja Preuss]

Originally posted by steve souza:
That implementation of the 'tringleton' pattern seems return the 3rd element in all invocations except the first two. Perhaps a better implementation would be the 'random tringleton' or even the 'round-robin tringleton'.

Perhaps. What would be a good implementation of course depends on why we actually want to only have three instances, and what we want to do with them.

Until the original poster answers that question, the discussion is hopelessly bound to be purely academical, I fear.