Question

Consider a production planning application with many products. Each product has a list of InventoryControl objects keyed on InventoryControlType. Depending on the algorithm we run for production planning, we need to access to different types of InventoryControl objects for a given product. This works OK. However, today I needed to introduce a field in InventoryControl that holds the InventoryControlType since deep in our algorithms we needed to know the InventoryControlType.

However, I felt felt like I was doing something wrong since it looks like I am repeating data.

Does this design look OK to you? Any ideas for improvement?

class Product{
    Dictionary<InventoryControlType, InventoryControl> InventoryControls;
    GetInventoryControl(InventoryControlType type){
        return InventoryControls[type];
    }
}

class InventoryControl{
    InventoryControlType controlType;
    float limit;
    float cost; 
    ...
    CalculateCost(){...}
    GetConstraint(){...}
}

Answer 1

I think you’re fine. It’s perfectly normal (at least in my experience) to use a unique property of an object as a key–be it in a Dictionary, a DataTable, or what have you.

For example in my own work our major project features a class called Product with a property called Symbol, and the application maintains a Dictionary called Products with each Product object’s Symbol property serving as its key.

Think of it this way: if you have a database with two tables, and one table references rows in the other by key, it may feel like you are “duplicating” data in the sense that you have the same number (the key) in two places. But that is not duplication; it’s a reference. The same applies in your scenario.