Question

There is a class that defines primary keys in various tables by having 1 string[] variable per table. For example:

static string[] my_table_foo_TablePrimaryKeys = new string[] { "primary_key1", "primary_key2" }
static string[] my_table_bar_TablePrimaryKeys = new string[] { "user_id", "customer_number" }

I find this to be a bit messy and less extensible for cases where we add a 3rd table later and we want to come back to this class to define the primary keys for that new 3rd table. So, I refactored it to look like this:

    static Dictionary<string, string[]> tablePrimaryKeys = new Dictionary<string, string[]>()
    {
        {"my_table_foo", new string[] { "primary_key1", "primary_key2" }},
        {"my_table_bar", new string[] { "user_id", "customer_number" }}
    };

Would you guys consider this a decent refactoring change? Why?

In addition, it also is a little cleaner in my humble opinion where the primary keys are referenced. Example:

In the former case:

DoStuffWithPrimaryKeys( my_table_foo_TablePrimaryKeys, "other stuff", 1000 );

And in the latter case:

string[] keys = tablePrimaryKeys["my_table_foo"];
DoStuffWithPrimaryKeys( keys, "other stuff", 1000 );

If anyone also wants to mention what the principles are for “acceptable refactoring” and how to know what is acceptable to refactor and what is not, that would be great and very educational.

I’m using C# and .NET 3.5.

Answer 1

I’m not too crazy about that change. Both cases looks dubious to me, but in the first case at least you get some amount of safety from the compiler. As long as the keys are spelled correctly where the variables are initialized, they will work as expected whenever they are used.

After you refactored you will be using strings everywhere, any a spelling error somewhere will cause a runtime error.