RE: Equality vs Sameness
Well, I do admit you have come up with a lot of types for which overriding
Equals would not offer any benefit. So for those types of functional
classes, I agree with you. I'll have to be more careful about my
generalizations in the future.
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Jon Skeet [C# MVP]" wrote:
> Dale <dale0973@xxxxxxxxxxxxx> wrote:
> > Good call on my misuse of overriding vs overloading.
> >
> > And I agree about overloading == for strings. The MS guidelines for
> > overloading operators do suggest overloading == for strings and other
> > reference types that act like value types. So maybe "any" was too strong of
> > a word. But between you and me, I can't think of a reason to overload == for
> > a string. I guess it just hasn't come up in my experience.
>
> So you find:
>
> if ((x==null && y==null) || (x != null && x.Equals(y)))
> or
> if (object.Equals(x, y))
>
> as easy to read as
>
> if (x==y)
>
> ?
>
> That's the only real reason - readability. Personally, I think that's a
> really big, good reason.
>
> > So, *grin*. let's heat things up and get to the last item... Overriding
> > Equals and GetHashCode.
> >
> > I agree about not writing code that hasn't been asked for. Developers
> > shouldn't add operations to a class because they think the user would benefit
> > from it in the future if the users haven't asked for that functionality. But
> > while that applies to business logic, there are basic functionality expected
> > in objects that I always include.
>
> Always? So you override Equals and GetHashCode even for forms, web
> pages, singletons etc? How often have you seen a Form used as the key
> in a hashtable, or wanted to compare two instances of a singleton?
>
> Just looking through my miscellaneous utility library... how often
> would you want to compare instances of threadpools other than by
> reference? Hash-creators? Binary diff decoders? Bit converters? Binary
> readers? The only thing in my library where it makes sense to compare
> instances is Utf32String, which of course *does* override Equals and
> GetHashCode (and overloads ==).
>
> > For instance, I never create a CollectionBase based class and leave out
> > IndexOf or Contains just because when I create the class I don't know if it
> > will be used. It is a collection and all developers on the team will expect
> > the collections I create to have that functionality without having to put in
> > a change request to get it.
>
> They could easily create the functionality if it's needed though.
> (Personally I never create CollectionBase based classes anyway...)
>
> > I am the same way about Equals. If you have a custom collection for your
> > class, IndexOf, Contains, and many other methods require value equality, not
> > referential equality, in order to work. If your class implements IComparable
> > so you can sort it, you have to override Equals as well.
>
> And that's fine for classes where it makes sense to compare instances -
> but in a lot of cases it doesn't. I'd say that fewer than half of my
> objects make sense to compare with other instances - that's a lot of
> work to do for the other half just for the sake of consistency.
>
> Using dependency injection, these days for many of my classes only a
> single instance will ever be created. There's nothing to *stop* new
> instances being created, but they just won't tend to be. Why would I go
> to the hassle of overriding Equals and GetHashCode for those classes?
>
> > It's just my opinion but, to me, overriding Equals is a good practice and
> > time well spent in any class except the most trivial or those with very
> > specific functional limitations that would make them exceptions
>
> To override them you have to:
>
> 1) Write unit tests for all the different possibilities (checking null,
> checking that each appropriate field is used in the equality, etc)
>
> 2) Write the implementation
>
> 3) Keep the tests and implementation up to date
>
> Point 3 is the biggest, in a way - how sure are you that if you add a
> field later on, you *always* remember to update Equals and GetHashCode?
> If you don't, you end up with a class which provides a sort of version
> of the functionality desired (if it *is* actually desired).
>
> Do you think MS should have overridden Equals for FileStream? If so,
> what should it have done? How about Thread?
>
> It's not unreasonable to override Equals and GetHashCode for types
> which will reasonably compared for value equality - but that's *far*
> from all of even most types, IME.
>
> Even where it would *potentially* be useful, I wouldn't usually bother
> until it's needed - but it depends how much bureaucracy is required in
> order to change something later. In my situation, when someone needed
> equality, they could implement it themselves with little more effort
> (if any) than if I'd done it in the first place. Embrace change :)
>
> --
> Jon Skeet - <skeet@xxxxxxxxx>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
>
.
Relevant Pages
- Re: comparing objects
... I override the Equal method on SalesRegion ... As Arne already put it, the Contains method is using the Equals method, ... ArrayList salesRegions = ... private string s; ...
(microsoft.public.dotnet.languages.csharp) - Re: do I need to override the equals() method?
... Marteno Rodia a écrit: ... so if you want that equals returne true for "content identical" object, yes you should override the equalsmethod. ... If you put object in collections and use containsfor example, you might want to override equals. ... Make sure they are consistent with each other, i.e., if two instances compare equal, they must have the same hash code. ...
(comp.lang.java.programmer) - RE: Find object inside arraylists by object attribute
... you will need to override the Equals method inside your class such that it ... public override int GetHashCode() ... instead that you just use that in your arraylit instead: ...
(microsoft.public.dotnet.languages.csharp) - Re: Find object inside arraylists by object attribute
... > public override bool Equals ... > //whenever you override equals you should override GetHashCode too ... > public override int GetHashCode() ... > instead that you just use that in your arraylit instead: ...
(microsoft.public.dotnet.languages.csharp) - Re: do I need to override the equals() method?
... And, of course, if you override equals(), you must override ... Note that there _IS_ a risk of being too liberal with equality. ... compare as equals, then they will replace each other in sets and map keys. ...
(comp.lang.java.programmer) |
|
