Is it good practice in Java OOP to allow an object to know about other instances of its type?

Question

I am speaking especially in regards to using a static variable to accomplish this. Consider the following object in Java:

public class MyObject{
    private static ArrayList<String> ID_List = new List<String>();
    private String ID_Number;
    public MyObject(){
        /* Assign a random number to ID_Number
         * And ensure that this is a unique number
         * not found in ID_List. Then add it to ID_List. */
    }

    /* Other methods and such */
}

To some degree, this is to ensure that each object made has a unique and distinguishing attribute that is easily accessible and readable. However, I am not sure if this kind of odd coupling between all objects of the same type is good practice.

Since it's making me uncomfortable I'm inclined to think that this isn't a good idea. What is the right way of thinking about this in an OOP manner?

Answer 1

Wouldn't it be practical to use a static ID_INCREMENTOR and a local objectID? In constructor, add one to ID_INCREMENTOR, then set objectID to ID_INCREMENTOR current value?

Then no two objects would ever have the same id.

Example:

public class MyObject{
    private static long ID_INCREMENTOR = 0;
    private long id;
    public MyObject(){

          ID_INCREMENTOR++;
          id = ID_INCREMENTOR;

    }

public long getID(){
    return id;
}

/* Other methods and such */
}

This is perhaps the simplest way to do this, as far as I can see. The objects don't know about each other, though you can be assured that no two objects will ever have the same unique identifier, unless you set it through the class/reflection.

Answer 2

It depends on what you need it for.

Actually Java offers a similar mechanism with the hashCode() method that returns a hash code value for each instance of the object ( it may be unique per class, but that's not mandatory and you are responsible to compute it properly), although nobody keeps track of that id.

What you mention is totally possible and may be legit depending on your needs, in some other scenarios may be totally unnecessary and or even may cause memory leaks.

If you want to keep a list of the created object you may also have a "builder" class what maintains the list.

class MyObject {
     private static AtomicInteger count = new AtomicInteger();
     private int id;
     MyObject(){
         id = count.getAndIncrement();
     }
     public int hashCode() {
         return id;
     }
     public void equals(Object o) {
        return o instenceof MyObject && ((MyObject)o).id == this.id;
     }
}
class MyObjectBuilder {
    private static List<MyObject> instances = new ArrayList<>();
    public static MyObject createObject() {
         MyObject newOne = new MyObject();
         instances.add(newOne);
         return newOne;
     }
 }

Other option is to use a Map, or a Set but again, depend on what you need it for.

You can also read more about equals and hashcode in here

Answer 3

Why to do all that, when you have that object.hashcode() returns a unique object ID for it almost all the time? It is very unlikely to have the same hashcode for different instances of the same object though the contract between equals() and hashcode() does not impose on guarantee of different hashcode when the objects are not equal. Moreover, I still didn't like the way of having a static ArrayList maintained for that in the class itself for that housekeeping. Even if you need such thing, externalize that ArrayList from this class. Let the management of unique instances of this object be done by a different class. Remember the Single Responsibility Principle in SOLID principles of OOPs.

Answer 4

This isn't that weird. You can find a similar pattern in Effective Java. Here is some of that info http://www.informit.com/articles/article.aspx?p=1216151

As it suggests, I would probably go for a factory method to get these objects, instead of newing them each time.

Answer 5

I am posting my own idea for a solution here in the case that someone looking at this might think my approach is more suitable to their needs. However, I'll be accepting PsyChrom's answer since I believe it is the best.

Assuming that the objects need to know their own ID number at all times, and may from time to time know what the ID numbers of other objects in memory are, consider the following implementation:

public class MyObject{
    private String ID_Number;
    public MyObject(String ID){
        this.ID_Number = ID;
    }

    public getID(){
        return ID_Number;
    }

    public checkUniques(List<String> ID_List){
        /* Do what not */
    }
    /* Other methods and such */
}

Assuming you only have one area where you are generating these objects, then simply do the following:

ArrayList<String> ID_List = new List<String>();
/* Create a number/string before you make the object
 * Which is unique. */
MyObject newObj = new MyObject(someUniqueStr);

In my own implementation, I actually only need the objects to know about the ID numbers of objects of their own type rarely. As a result, perhaps just adding in a method for it may be satisfactory instead of providing them with their own list. This way we externalize the housekeeping on our objects like a user previous suggested!