You know those quizzes in magazines that you can take to determine your personality? Don’t you just LOVE them! At any rate, I thought that it would be fun to find out about the personality, stability and integrity of various classes.

Now just close your eyes and imagine that you ARE your favorite class. Then answer each of the questions below, and find out just how classy you really are.

Object Oriented Personality Quiz

Pick the answer that best describes your personality:

I. In your class, when comparing yourself to others: (select one)

1. You do not override the equals() method of Object.

2. You do not believe that your equals() method would ever be invoked even if you had one.

3. You do not override the equals() method, but one of your super classes HAS.

4. You have an equals() method of your own.

Analysis:- If you selected:

1. You believe yourself to be unique and unequaled. The only thing that you will say that you are equal to is yourself. If you happen to be a dynamic personality, such as a Thread, rather than a stable personality with a value, this MAY be true. On the other hand, you may just not CARE whether anybody has a clue who you are equal to and you are perfectly happy letting everyone think that you are only equal to yourself. Quite an egotistic attitude.

2. You are a very private sort, and do not go out much. You believe yourself to be invisible to anyone that would ever possibly use the equals() method. You need to get a grip on yourself and work on self-confidence. Get out there and GET an equals() method - it is the right thing to do.

3. You are content to be judged based on the rules laid out by your ancestors. You are confident that whatever they said is good enough for you. Basically, you are afraid to strike out on your own and define your own personality. You are a wimp.

4. You are a personality in your own right. You are attempting to be a mature, well rounded class and live up to your responsibilities.

Now check out the next question to find out how well you are doing with your equals() method.

II. When invoking your equals() method on an instance of your class: (answer each one true or false)

1. When comparing the instance to itself, your equals() method always returns “true”.

2. When comparing the instance to a second instance of your class, you always get the same result as if the second instance compares itself to the original.

3. When comparing the instance to a second instance many times, you always get the same answer (presuming that the instances are not modified).

4. When you compare the instance to “null” your equals() method always returns “false”.

5. When you say that instance 1 is equal to instance 2 and instance 2 is equal to instance 3, then it is always true that instance 1 is equal to instance 3.

6. You answered false to any of the above.

Analysis:- If you answered true:

1. Your reflexive instincts are good, which means that you have a solid sense of self identity.

2. You are fair and symmetric. You are not influenced by who is asking the question.

3. You are consistent and stable. You can be relied on and trusted. You are really cool.

4. You can recognize thin air on your own. This is a basic survival requirement.

5. You are capable of the higher level of consciousness known as transitiveness.

6. You have a problem. Get help immediately.

III. When you overrode the equals() method: (answer each one true or false)

1. You made sure to leave the argument of the equals(Object o) method as Object.

2. You always use the instanceof operator to check if the incoming argument is the correct type.

3. You start out with a check to see if you are comparing the instance to itself by using a == check.

4. Your method checks each field of the class one by one, comparing the contents of both objects to insure that each field is equal.

5. You have identified any unreliable sources that might change without you knowing it and omitted them from the comparison.

6. You overrode the hashCode() method also.

7. You answered false to any of the above.

Analysis:- If you answered true:

1. Of course the only thing coming in should always be “MyType” but you have resisted the urge to state that in the signature, and therefore you have avoided accidentally overloading equals(Object o) instead of overriding it. You have shown exceptional willpower. Good Job!

2. Well, you left the door open for this above, so you just have to deal with it. And yes - this is a bit of an elitist attitude, but the facts of life say that you just can NEVER be the same as any other type than you ARE, so trying to compare yourself to others is a bad idea.

3. You are not easily hoodwinked. You check for obvious set-ups before putting any effort into comparisons.

4. You are methodical and complete. You do not let complexity overwhelm you.

5. You recognize flighty characteristics in yourself and do not use those aspects of your personality in defining yourself. Of course this means that your instance might be considered equal to some instance that has a different value in that field, but you have acknowledged that, come to terms with it and moved on.

6. You recognize that when defining your equals() method, you are defining what makes you unique, and that eventually someone is going to want to put some order to your instances, and they will without a doubt use the hashCode() method to do that. In fact since all the HashMap, HashSet, etc. classes count on this method working hand in hand with equals, you KNOW that this is important.

7. Once again, you have a problem. Get help immediately. Professional help.

IV. When you overrode the hashCode() method: (answer each one true or false)

1. You didn’t, even though you overrode the equals() method.

2. Your hashCode() method always returns the same value for every instance.

3. Your hashCode() method returns the same value for several instances that are NOT equal.

4. Your hashCode() method always returns the same value for the same instance over and over unless you start your application over, then it consistently returns a different value.

5. Your hashCode() method returns different values for different instances even if they are considered equal using your equals() method.

6. Your hashCode() method skips some fields in your object state because that way the hashCode() method runs faster.

7. Your hashCode() method returns something other than an int value.

Analysis:- If you answered true:

1. You fool! The hashCode() method MUST return the same result for all instances that are equal. When you changed the definition of what makes instances equal, you have to let hashCode() in on the secret or nothing will work as expected. You can plan on spending much of your life in confusion.

2. You try to get away with whatever you can. You feel that because this will compile and run, that you have done your duty. Even if it runs REALLY POORLY, which this will.

3. You play by the rules. Exactly. And that is fine. However, you are NOT expecting optimal performance, which is good, because you will probably not get it if there are too many instances that get identical results.

4. You are not chained by the opinions of others. You know that this is valid EVEN IF it bothers others, and you stand your ground.

5. You have no internal integrity. You are confused and mixed up and will spread that condition to all who interact with you.

6. You are easily confused and do not recognize the difference between immediate savings and long term benefits. You will spend much of your life waiting for hash-based activities to complete because they could be extremely slow. Learn to appreciate boredom.

7. Careful, the compiler will get you.

V. When you overrode the equals() method: (Select one)

1. You also overrode the toString() method, however the output String sort of reads like a core dump. You did not implement the Comparable interface.

2. You also overrode the toString() method trying to make the output String as readable as possible. You did not implement the Comparable interface.

3. You also overrode the toString() method trying to make the output String as readable as possible. You also implemented the Comparable interface.

4. You also overrode the toString() method trying to make the output String as readable as possible and as inclusive of all of the fields as possible. You also implemented the Comparable interface and did it well.

Analysis:- If you selected:

1. You are a techno-weenie at heart and should not be allowed to participate in design decisions. All of your code should be reviewed by persons resembling humans before being released for public consumption.

2. You are competent, but do not go the extra mile. Adequate is good enough for you.

3. You try to excel at everything, and often succeed. If you did a good job at implementing the Comparable contract then you should be proud of yourself.

4. So you are James Gosling!! Well, maybe Joshua Bloch. I knew that JavaRanch would rope you guys in sooner or later. Can we see the code????