Reputation
Top tag
Next privilege 200 Rep.
See reduced ads
Badges
12
Impact
~3k people reached

  • 0 posts edited
  • 1 helpful flag
  • 18 votes cast
Jun
24
awarded  Popular Question
Sep
11
awarded  Citizen Patrol
Jan
14
awarded  Popular Question
May
21
awarded  Critic
Jan
31
awarded  Informed
Dec
10
revised Interaction of a GUI-based App and Windows Service
fixed typo
Dec
10
asked Interaction of a GUI-based App and Windows Service
Dec
9
awarded  Quorum
Aug
14
awarded  Analytical
Aug
11
awarded  Autobiographer
Dec
27
revised C# Design, many properties, complex constructor and equality
follow-up and answer
Dec
27
awarded  Scholar
Dec
27
accepted C# Design, many properties, complex constructor and equality
Dec
24
comment C# Design, many properties, complex constructor and equality
This is an intriguing idea, I have to give it some thought. It definitely could solve my current problem, but I have 2 concerns... 1) it limits the functionality of the class. It would only do a comparison and nothing else. A class with properties would be able to do add different unrelated methods in the future. 2) For my current solution, since my 2 data sources have slightly different formats, the add method would have to do some work to modify the value so the 2 formats would have the same dictionary Key-Value pairs.
Dec
24
awarded  Supporter
Dec
24
comment C# Design, many properties, complex constructor and equality
@DocBrown I had considered that drawback after I responded. I think the best solution to that problem is making the dictionary key an enum, rather than a string.
Dec
24
comment C# Design, many properties, complex constructor and equality
By efficient, I was specifically referring to clarity. I don't want this to become a drag on performance, but I haven't even written any code yet, so performance hasn't entered my mind. I tend to subscribe to the idea that you shouldn't worry about performance until you know you have a problem.
Dec
24
comment C# Design, many properties, complex constructor and equality
@MikeNakis you make an excellent point with a changing hash code not being an evil sin. My original concern was someone else taking my code in the future and doing things that I didn't intend get getting side effects. And thanks for Eric's blog post, he is always a good read.
Dec
23
comment C# Design, many properties, complex constructor and equality
And the dictionary as the argument in the constructor is a great idea, I hadn't even thought of that. +1 if i had enough rep to upvote.
Dec
23
comment C# Design, many properties, complex constructor and equality
An immutable object isn't a requirement, but in my limited experience, overriding GetHashCode properly requires the HashCode not change over the life of the object, and if it is mutable, I cannot guarantee that using standard methods of calculating a hashcode.