Is this way of using the <enum, object> dictionary correct in this production planning example?
Consider a production planning application with many products. Each product has a list of InventoryControl objects with the key InventoryControlType. Depending on the algorithm we run for production scheduling, we need access to different types of InventoryControl objects for a given product. It works fine. However, today I needed to enter an InventoryControl field that contains InventoryControlType, since in our algorithms we needed to know the InventoryControlType.
However, I felt like I was doing something wrong because it looks like I am iterating over the data.
Does this design look good? 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(){...}
}
source to share
I think you're okay. It's perfectly okay (at least in my experience) to use a unique property of an object as a key - be it in Dictionary
, a, DataTable
or whatever you have.
For example, in my own work, our main project has a class called Product
with a property Symbol
, and the application maintains Dictionary
called Products
with each property Product
object Symbol
as its key.
Think of it this way: if you have a database with two tables, and one table refers to rows in the other by key, it may seem that you are "duplicating" data in the sense that you have the same number (key) in two places ... But this is not duplication; this is a link. The same applies to your scenario.
source to share
I don't see anything wrong with that. He duplicates some of the information, but the situation requires it. You can use a regular collection instead of a dictionary, but because your main goal is to find a piece of information based on its InventoryControlType, Dictionary seems to be the most correct with this implementation.
source to share
I think this is absolutely fine to use Dictionary<TKey, TValue>
.
Many times dictionary objects will always have some redundant information from the value object, the most common of which would be ID, for example. Dictionary<int, SomeObject>
where int will be the value taken from SomeObject.Id - it makes sense in that regard and matches your use case perfectly.
source to share
It depends on how large the dictionary needs to get, because for very large amounts of data, I think a dictionary lookup using a key will probably be faster. But if you don't have a lot of data, you can use Linq and a generic list. For example:
class Product{
List<InventoryControl> InventoryControls;
GetInventoryControl(InventoryControlType type){
return InventoryControls.First(x => x.ControlType == type);
}
I would recommend running some unit test to see if a dictionary is needed.
source to share