This method returns the hash code value for the object on which this method is invoked. This method returns the hash code value as an integer and is supported for the benefit of hashing based collection classes such as Hashtable, HashMap, HashSet etc. This method must be overridden in every class that overrides the equals method."
Why?
Does an ArrayList use hashCode() when processing?
How will my hashCode() algorithm affect the performance (memory use, efficiency of algorithms, CPU usage) of processing the ArrayList?
3. I am not sure how to implement a hashCode() method for my Card class, which is extended by a Deck class.
Jon
Campbell Ritchie
Sheriff
Joined: Oct 13, 2005
Posts: 32654
4
posted
1
We have already seen that Deck extends Class is incorrect use of inheritance. A Deck "is-not-a" Card.
There are several good references about the equals() method:
Angelika Langer's website. That actually appears on the Google search I told you about above
Odersky Spoon and Venners: you will find a link to their work on our FAQ.
Unsynchronized means that multiple threads can gain access to its methods simultaneously. Look in the documentation for ArrayList and the Java™ tutorials for more details.
No, an array list doesn't use a hash code as a routine.
Campbell Ritchie wrote:We have already seen that Deck extends Class is incorrect use of inheritance. A Deck "is-not-a" Card.
There are several good references about the equals() method:
Angelika Langer's website. That actually appears on the Google search I told you about above
Odersky Spoon and Venners: you will find a link to their work on our FAQ.
Unsynchronized means that multiple threads can gain access to its methods simultaneously. Look in the documentation for ArrayList and the Java™ tutorials for more details.
No, an array list doesn't use a hash code as a routine.
Thanks I will surely go through the documentation since I am training; any idea how to represent a set of 52 cards as an object and avoid extending the Card class?
"Deck" is-not-a "Card" as Ritchie has pointed out. So it is not a good design to extend "Card" class for creating "Deck" class. We use extending of classes for representing "IS-A" relationship between two classes.
Relationship between "Deck" and "Card" is, "Deck" has-a (list of)"Card".
That means, "Deck" class has a reference to list of instances of "Card" class.
In your "Deck" class, you have already implemented that relationship using
As I see, "extends Card" part in your existing class is also not required for any functionality of your current code. No harm will be done if you removed that part. But I didn't read all of your code, there may be few other changes also needs to do if you remove "extends Card" part.
Manjula Weerasinghe wrote:"Deck" is-not-a "Card" as Ritchie has pointed out. So it is not a good design to extend "Card" class for creating "Deck" class. We use extending of classes for representing "IS-A" relationship between two classes.
Relationship between "Deck" and "Card" is, "Deck" has-a (list of)"Card".
That means, "Deck" class has a reference to list of instances of "Card" class.
In your "Deck" class, you have already implemented that relationship using
As I see, "extends Card" part in your existing class is also not required for any functionality of your current code. No harm will be done if you removed that part. But I didn't read all of your code, there may be few other changes also needs to do if you remove "extends Card" part.
Thank you, you are right, however the implication that I would have to factor out the code currently within the Deck class within the main() method (and will eventually be moved to some calling program when I get to the UI design stage) seems like spaghetti to me, what is your advice?
I also have another little problem after having tried to rig in Apache logging services to the code.
As has been proposed earlier in this thread, you should study the resources to find out more about the working of equals() and hashCode().
Thank you, you are right, however the implication that I would have to factor out the code currently within the Deck class within the main() method (and will eventually be moved to some calling program when I get to the UI design stage) seems like spaghetti to me, what is your advice?
What exactly strikes you as spaghetti? It seems like a perfectly reasonable implication.
As has been proposed earlier in this thread, you should study the resources to find out more about the working of equals() and hashCode().
Thank you, you are right, however the implication that I would have to factor out the code currently within the Deck class within the main() method (and will eventually be moved to some calling program when I get to the UI design stage) seems like spaghetti to me, what is your advice?
What exactly strikes you as spaghetti? It seems like a perfectly reasonable implication.
Okay thanks, so I just have to re-factor out the code from my Deck into the Poker class, which is basically my "mother" class for processing the game.