Я использую много словарных коллекций, которые содержат другие словарные коллекции, такие как:
Dictionary<Guid, List<string>>()
Dictionary<Guid, Dictionary<Guid, List<string>>>()
Я перебираю эти карты и передаю их в параметрах в моем коде.
Это кажется плохой идеей, так как вы не можете по-настоящему расширить природу этих коллекций.
Должен ли я обернуть их в классе?
Вы сталкиваетесь с такими ограничениями? Ваша программа трудно изменить/отладить? Если да, то рефакторинг. В противном случае, прибыль: вы прагматичный программист,
Тем не менее, я вижу место для немедленного улучшения:
IDictionary<Guid, List<string>> x;
IDictionary<Guid, IDictionary<Guid, List<string>> y = new Dictionary<Guid, IDictionary<Guid, List<string>>();
Я бы сказал, да, создайте класс специально для него. Затем вы можете добавлять/не применять методы в соответствии с вашим использованием, а не работать с любыми ограничениями, которые вы обнаружите с помощью Dictionary при использовании.
Похоже, вам нужна древовидная структура.
По крайней мере, оберните свою "вонючую" структуру данных в классе, чтобы вы могли инкапсулировать ее реализацию, предоставив чистый API для запроса/изменения данных без какого-либо кода клиента, описывающего информацию о деталях хранения.
Затем вы сможете в любой момент изменить структуру данных в будущем. Если вы этого не сделаете сейчас, вы можете пожалеть об этом позже, когда у вас в 10 или 100 раз больше клиентского кода, и это слишком дорого/больно для рефакторинга.
Вы можете обнаружить, что до тех пор, пока вы держите его инкапсулированным аккуратно, и это работает, тот факт, что вы чувствуете, что он вонючий, не имеет особого значения - до тех пор, пока код делает то, что ему нужно делать, и его можно обслуживать, нет смысла вкладывать в него гораздо больше времени. (Я не сторонник сохранения грязного кода, но мы должны сбалансировать коммерческие реалии против нашего желания достичь теоретического совершенства - если код работает и не вызывает никаких проблем, то это может быть не всегда полезно для вашего времени, чтобы улучшить или реорганизовать его. Вместо этого вы можете обнаружить, что просто нейтрализовать риски, инкапсулируя его в класс и изолируя грязную реализацию от своих клиентов, достаточно на данный момент)
.NET 4.0 представила Tuple, еще более неприхотливую структуру данных, такую же приятную, как кажется в начале, столько боли, которую она приносит впоследствии, и ее следует использовать с умом.
Словарь здесь как-то менее злой, потому что он служит для быстрого доступа к элементу, а не как клей вместо создания классов. Я считаю, что нет ничего плохого в использовании словарей, если эти словари используются локально в методе для некоторых вычислений или что-то в этом роде, но становится менее ясным, когда вы начинаете передавать их в качестве параметров. Если это так, я думаю, вам нужно создать для него класс.
Поскольку тип словаря является ссылочным типом, вы здесь не в плохом состоянии, но только для ясности кода рассмотрите определение нового типа, полученного из Dictionary<Guid,List<string>>, чтобы сократить код, который вы пишете, и сделать его легким удобочитаемый. Класс должен выглядеть следующим образом:
internal class MyWrapper : Dictionary<Guid, List<string>>
{
}
Или, если вам важно сохранить IDictionary, а затем продолжите с составным дизайном, обернув экземпляр Dictionary<Guid, List<string>> в класс, который реализует IDictionary<Guid, List<string>>, и просто делегирует все методы в завернутый словарь.