I have a dictionary of Objects of a class Columns

Dictionary<double, Columns>

Columns is a class of columns, i.e. name, post code, etc, mobile phone. I would like to make Columns class as much open for extension as possible, so it will be no trouble to add more classes. I need to set few of the columns to be there always, and would like the user to be able to define which columns to display from the remaining, and also add custom columns. Each columns has to have a method getValue()

My idea is to create an abstract class Column and derive specific columns from it. Make each child class implement the getValue() method by making it abstract what should force it to be overridden (am I correct?). I will define enum which will list all available column types. Finally, a class Columns would keep all the available columns in dictionary

Dictionary<enum, Column>

My question is: is my thinking process correct? Is there any room for improvement? Would it be a better idea to use interfaces? Finally, is this design going to be efficient and fast for rapidly changing values in columns, i.e. within a second I might have to update 50 different records in this dictionary.

  • 5
    Due to floating-point inaccuracies, I'm not sure if double is a wise choice for a dictionary key.
    – Heinzi
    Nov 21, 2013 at 13:23
  • @Heinzi I will keep this in mind
    – Macin
    Nov 21, 2013 at 13:40

1 Answer 1


I think you need to pause and reconsider what you're doing. My preference is for the code to mirror the business problem that I'm trying to solve. Defining your problem in terms of a language primitive and a complex object that mirrors a database element doesn't help me understand what you're trying to solve.

As mentioned by Heinzi, using a double for your key is probably unwise. Consider an integer (which could represent a customer ID) or a string (which could represent a customer name) instead. If speed / performance is of concern, I would probably use an integer but I wouldn't worry about it too much unless I benchmarked it both ways.

For the value, consider creating a class that makes sense for your problem. You mentioned name, post code, etc, mobile phone. which made me think of "personally identifiable information" (PII) or "client contact information" (CCI) or something similar. So I would build a class to that effect and use that as my value type instead.

If you had both a PII and a CCI class that could be stored, then I would consider an Interface and use that as the value type. Using an enum or some other sort of flagging mechanism to indicate available data types is perfectly fine too. If you use an Interface, consider putting the flag(s) inside of the Interface to enable additional access beyond the core Interface fields.

  • I wanted to upvote your answer but don't have enough reputation points so had to thank you in comment. The answer is usefull indeed.
    – Macin
    Nov 21, 2013 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.