Tales from a code review gone wrong
time to read 1 min | 61 words
Originally posted at 2/23/2011
Yes, I know that the NHibernate documentation says that you should override Equals and GetHashCode, but I get the feeling that this wasn’t what the documentation authors intended:
Comments
This one is a classic. It's also a showcase why code c.q. peer reviews are so important. You catch 'errors' you won't catch with a unit test..
Yeah, it's missing the number 397 in it.
R# would have catch it automatically, and would have shown this code grayed in the VS code editor wnd
Even if the base class (e.g. BaseEntity) has a valid logic for calculating GetHashCode based on all identifier properties, NHibernate will complain if the inherited class doesn't implement it. If you're using composite ids, you're oblitaded to do so.
That being said, this code may not be so wrong.
So is the documentation wrong or the implementer?
A really good one ;-)
@Juan Lopes
You are right, S#arp Architecture's BaseObject class implements general purpose GetHashCode.
sharp-architecture.googlecode.com/.../BaseObjec...
Provided .Equals is implemented by calling down to the base, then this is fine :-D
I have been struggling with implementing Equals/GetHashCode, especially when lazy-loaded properties are part of an object's identity. Because then every time Equals or GetHashCode gets called those properties get lazy-loaded. I have posted a question about this on stackoverflow, but haven't yet received an answer that satisfies me 100%.
http://stackoverflow.com/q/5002670/104750
Comment preview