Re: Over-riding equals method dilemma
From: Anony! (someone_at_something.com)
Date: 08/13/04
- Next message: kaeli: "Design question - interface, abstract class, or ???"
- Previous message: taylorius: "Unusual application for code coverage tool?"
- In reply to: andrewh1: "Re: Over-riding equals method dilemma"
- Next in thread: bugbear: "Re: Over-riding equals method dilemma"
- Reply: bugbear: "Re: Over-riding equals method dilemma"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 13 Aug 2004 13:19:09 GMT
"andrewh1" <andrewh1@iinet.net.au> wrote in message
news:411cb39c$0$16330$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>
>
> Anony! wrote:
> > Hi
> >
> > <snippet>
> >
> > public boolean equals(Object obj)
> > {
> > if (obj == null) //*
> > return false;
> > else if (obj instanceof Node )
> > return this.identifier.equals(((Node)obj).identifier); //**
> > else return false;
> > }
> >
> > Problems:
>
> Why are the following problems?
Don't want to be rude, but can't you read? I'm trying to understand why I'm
getting these compile errors/runtime errors if the code is changed as
indicated below. And thanks to the reponses, I know why!
> > 1 ) if i change * to:
> >
> > if (obj.equals(null))
> >
> > it compiles but i get a runtime error. i thought if your comparing
objects
> > you should use equals method. null is an object isn't it?
> >
> null is not an object. What is wrong with what you have?
>
> > 2) if i change ** to:
> >
> > return this.identifier.equals(obj.identifier); //**
> >
> > i get a compile error
> > Dont understand why u need to cast it into a Node, since you know its
> > already a instanceof a Node from the previous statement.
>
> You know; but the compiler still needs to be told.
>
> As I said what is wrong with your original code?
>
> However note that 'instanceof' tests for null as well. ie it could be
> rewritten as
>
> public boolean equals(Object obj) {
> return (obj instanceof Node) &&
> (this.identifier.equals(((Node)obj).identifier)));
> }
>
> Note that as Tony mentioned you should override hashcode() too. In this
> case if identifier is simply a String then you could return the hashcode
> for identifier. This will fulfil the equals/hashcode contract.
And as i mentioned equals/hashcode contract was mentioned in a different
post, and has nothing to do with the subject in this post. And yes, I do
realize that you have to override both methods, which I have also indicated
in the other post. Anyhow, I do appreciate the help.
AAA
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.732 / Virus Database: 486 - Release Date: 29/07/2004
- Next message: kaeli: "Design question - interface, abstract class, or ???"
- Previous message: taylorius: "Unusual application for code coverage tool?"
- In reply to: andrewh1: "Re: Over-riding equals method dilemma"
- Next in thread: bugbear: "Re: Over-riding equals method dilemma"
- Reply: bugbear: "Re: Over-riding equals method dilemma"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
