Использование многих словарей в словарях в моем коде - PullRequest
12 голосов
/ 25 ноября 2011

Я использую много словарных коллекций, которые содержат другие словарные коллекции, такие как:

Dictionary<Guid, List<string>>()

Dictionary<Guid, Dictionary<Guid, List<string>>>()

Я перебираю эти карты и передаю их в параметрах в моем коде.

Это кажется плохой идеей, так как вы не можете по-настоящему расширить природу этих коллекций.

Должен ли я обернуть их в классе?

Ответы [ 5 ]

6 голосов
/ 25 ноября 2011

Вы сталкиваетесь с такими ограничениями?Трудно ли изменить / отладить вашу программу?Если это так, рефакторинг.В противном случае, прибыль: вы прагматичный программист.

Тем не менее, я вижу возможность для немедленного улучшения:

IDictionary<Guid, List<string>> x;

IDictionary<Guid, IDictionary<Guid, List<string>> y = new Dictionary<Guid, IDictionary<Guid, List<string>>();
5 голосов
/ 25 ноября 2011

Я бы сказал, да, создать класс специально для него.Затем вы можете добавлять / не реализовывать методы в соответствии с вашим использованием, вместо того, чтобы обходить любые ограничения, которые вы обнаружите с помощью Dictionary, с вашим использованием.

Похоже, вам нужна древовидная структура.

2 голосов
/ 25 ноября 2011

По крайней мере, оберните свою "вонючую" структуру данных в класс, чтобы вы могли инкапсулировать ее реализацию, предоставляя чистый API для запроса / изменения данных без какого-либо кода клиента, который ничего не говорит о деталях хранилища.

Тогда вы сможете в любой момент изменить реализацию структуры данных.Если вы не сделаете этого сейчас, вы можете пожалеть об этом позже, когда у вас будет в 10 или 100 раз больше клиентского кода, и это слишком дорого / болезненно для рефакторинга.

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

1 голос
/ 25 ноября 2011

Поскольку тип Dictionary является ссылочным типом, вы не находитесь здесь в плохом положении, но просто для ясности кода рассмотрите возможность определения нового типа, производного от Dictionary<Guid,List<string>>, только для сокращения кода, который вы пишете, и для упрощенияудобочитаемый.Класс должен выглядеть следующим образом:

internal class MyWrapper : Dictionary<Guid, List<string>>
{
}

Или, если для вас важно придерживаться IDictionary, тогда продолжайте составлять дизайн, обернув экземпляр Dictionary<Guid, List<string>> в класс, который реализует IDictionary<Guid, List<string>> и просто делегирует все методы в завернутый словарь.

1 голос
/ 25 ноября 2011

.NET 4.0 представила Tuple, еще одну более уязвимую структуру данных, столь же приятную, как кажется в начале, такую ​​же большую боль, которую она приносит впоследствии и которую следует использовать с умом.

Словарь здесь как-то менее злой,потому что он служит для быстрого доступа к элементам, а не просто как клей вместо создания классов.Я считаю, что нет ничего плохого в том, что вы используете словари, если эти словари используются локально в методе для какого-либо вычисления или чего-то еще, но становится менее ясным, когда вы начинаете передавать их в качестве параметров.Если это так, я думаю, вам нужно создать класс для него.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...