Является ли этот способ использования словаря <enum, object> правильным в этом примере планирования производства?

Question

Рассмотрим приложение для планирования производства со многими продуктами. У каждого продукта есть список объектов InventoryControl с ключом InventoryControlType. В зависимости от алгоритма, который мы используем для планирования производства, нам необходим доступ к различным типам объектов InventoryControl для данного продукта. Это работает хорошо. Однако сегодня мне нужно было ввести поле в InventoryControl, которое содержит InventoryControlType, поскольку в глубине наших алгоритмов нам нужно было знать InventoryControlType.

Однако мне показалось, что я что-то не так делаю, поскольку похоже, что я повторяю данные.

Этот дизайн вам подходит? Есть идеи по улучшению?

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

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

Answer 1

Я думаю, ты в порядке. Совершенно нормально (по крайней мере, по моему опыту) использовать уникальное свойство объекта в качестве ключа - будь то Dictionary, DataTable или что у вас есть.

Например, в моей собственной работе наш основной проект имеет класс Product со свойством Symbol, и приложение поддерживает Dictionary с именем Products с каждым Product объектом, обслуживающим свойство Symbol как его ключ.

Думайте об этом так: если у вас есть база данных с двумя таблицами, и одна таблица ссылается на строки в другой по ключу, может сложиться впечатление, что вы «дублируете» данные в том смысле, что у вас одинаковое число ( ключ) в двух местах. Но это не дублирование; это ссылка. То же самое относится и к вашему сценарию.

Answer 2

Это действительно зависит от того, насколько большим должен быть словарь, потому что для очень больших объемов данных, я думаю, поиск в словаре с использованием ключа, вероятно, будет быстрее. Но если у вас нет больших объемов данных, вы можете использовать Linq и Generic List. Например:

class Product{
List<InventoryControl> InventoryControls;
GetInventoryControl(InventoryControlType type){
    return InventoryControls.First(x => x.ControlType == type);
}

Я бы порекомендовал запустить некоторые тесты модульных тестов, чтобы узнать, нужен ли словарь.

Answer 3

Я думаю, что это абсолютно нормально для варианта использования Dictionary<TKey, TValue>.

Много раз объекты словаря всегда будут иметь некоторую избыточную информацию из объекта значения, наиболее распространенным из которых будет идентификатор, напримерDictionary<int, SomeObject> где int будет значением, взятым из SomeObject.Id - это имеет смысл в этом отношении и совершенно идентично вашему варианту использования.

Answer 4

Я не вижу в этом ничего плохого. Это дублирует часть информации, но ситуация требует этого. Вы можете использовать обычную коллекцию вместо словаря, но поскольку ваша главная цель - найти часть информации, основанную на ее InventoryControlType, словарь в этой реализации кажется наиболее правильным.