Need a .NET Dictionary<string,object> with just a little more functionality [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect ans开发者_开发百科wers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I need a dictionary but I also need to store a boolean value about the object in the dictionary. What's the best way for this.

Something like Dictonary<string,object,bool> would be ideal, but doesn't exist.

My first idea was:

public class SomeObject
{
    public object Value { get; set; }
    public bool Flag { get; set; }
}
// and then use:
Dictionary<string,SomeObject> myDictionary;

My 2nd idea was to implement IDictionary<string,object> and contain two dictionaries within that were manipulated by the implemented methods and property accessors. They would have to be kept in sync:

class DataDictionary : IDictionary<string, object>
{
    private Dictionary<string, bool> _clientSideFlags = new Dictionary<string, bool>();
    private Dictionary<string, object> _data = new Dictionary<string, object>();

    // implemented methods, etc.
}

My 3rd idea was to see what the folks at StackOverflow would do.

---

You can just use:

Dictionary<string, KeyValuePair<object,bool>>

This lets you store a KeyValuePair<object,bool>, which provides your custom class using a BCL type.

That being said, I often find myself using a custom class or struct for this, instead. Personally, I find that implementing a custom type for my value storage is often more maintainable over time than using a KeyValuePair, Tuple, or other non-specific type. Usage, a year later, is much more obvious if I have a custom type with an appropriate name.

---

Go with your first idea - it is simple, effective, and easily understood. Yes, the custom type may feel like overkill but it increases the readability of you code. Anyone who maintains this code later will thank you.

---

I'd go with your first idea.

Further, I'd run far away from you second idea. You'll be doing a lot of coding, just to produce a class that does twice the work (two lookups) at runtime. A loser all around.

---

I would go with your first idea. It's basically a simple wrapper class for your object. But I would force the properties to be supplied to a constructor.

public class SomeObject
{
    public SomeObject(object value, bool flag)
    {
        Value = value;
        Flag = flag;
    }

    public object Value { get; private set; }
    public bool Flag { get; private set; }
}

---

System.Tuple is the other obvious prospect (if using .NET 4 or F#).

---

For a quick solution, Dictionary<string, KeyValuePair<object, bool>> works.

For a nicer solution, it's easy enough to implement a generic Pair<T1,T2> type with the correct hash code combination and equality support, which is better than abusing KeyValuePair<,>, and you can give it the constructors and access etc that you want.

(Or, yes, a new object for a one-off. Just don't forget to override Equals and GetHashCode.)

---

I would typically use:

Dictionary<string, KeyValuePair<object,bool> > 

for this type of scenario. It has worked well for me.

---

Here's something else to consider that may work for your situation, or it may not.

Dictionary<string, object> myDictionaryTrue;
Dictionary<string, object> myDictionaryFalse;

---

Just for the sake of stating it, I'm not going to argue on the merits/cons of it.

In .NET 4.0 you could do

new List<Tuple<string, object, bool>>()

or new Dictionary<string,Tuple<object, bool>>()