В чем назначение ReadonlyDictionary ? Какие преимущества он дает ?
Также насколько правильным является такой тест для демонстрации возможностей ReadonlyDictionary, почему-то результат не особо в пользу ReadonlyDictionary.
Dictionary Elements 5 : 126 ms
ReadOnlyDictionary Elements 5 : 139 ms
Dictionary Elements 50 : 1305 ms
ReadOnlyDictionary Elements 50 : 1345 ms
Dictionary Elements 500 : 12357 ms
ReadOnlyDictionary Elements 500 : 13039 ms
Dictionary Elements 5000: 126129 ms
ReadOnlyDictionary Elements 5000: 134018 ms
Вот код теста
class Program
{
static Dictionary<int, int> d5 = CreateDictionary(5);
static ReadOnlyDictionary<int, int> rod5 = new ReadOnlyDictionary<int,int>(d5);
static Dictionary<int, int> d50 = CreateDictionary(50);
static ReadOnlyDictionary<int, int> rod50 = new ReadOnlyDictionary<int, int>(d50);
static Dictionary<int, int> d500 = CreateDictionary(500);
static ReadOnlyDictionary<int, int> rod500 = new ReadOnlyDictionary<int, int>(d500);
static Dictionary<int, int> d5000 = CreateDictionary(5000);
static ReadOnlyDictionary<int, int> rod5000 = new ReadOnlyDictionary<int, int>(d5000);
static Dictionary<int, int> CreateDictionary(int elements)
{
var dict = new Dictionary<int,int>(elements);
for (int i = 0; i < elements;i++ )
dict[i + 1] = i + 1;
return dict;
}
static void TestDictionary(IDictionary<int, int> dict)
{
var sw = new Stopwatch();
sw.Start();
Int64 sum = 0;
int size = dict.Count;
for (int i = 0; i < 1000000; i++)
for(int j = 1; j<=size; j++)
sum += dict[j];
sw.Stop();
Console.WriteLine("{0} Elements {2} : {1} ms", dict.GetType().Name, sw.ElapsedMilliseconds, dict.Count);
}
static void Main(string[] args)
{
TestDictionary(d5);
TestDictionary(rod5);
TestDictionary(d50);
TestDictionary(rod50);
TestDictionary(d500);
TestDictionary(rod500);
TestDictionary(d5000);
TestDictionary(rod5000);
Console.ReadKey();
}
}
Здравствуйте, Аноним, Вы писали:
А>В чем назначение ReadonlyDictionary ? Какие преимущества он дает ?
Попробуйте добавить элемент в ReadonlyDictionary и все сразу станет ясно.
Re[2]: ReadonlyDictionary vs Dictionary
От:
Аноним
Дата:
12.06.13 09:43
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Аноним, Вы писали:
А>>В чем назначение ReadonlyDictionary ? Какие преимущества он дает ?
Doc>Попробуйте добавить элемент в ReadonlyDictionary и все сразу станет ясно.
Да добавить нельзя, создан только ради этого ? Меньшая функциональность, дольше доступ.
Какой use_casе на практике ?
Здравствуйте, Аноним, Вы писали:
А>Да добавить нельзя, создан только ради этого ? Меньшая функциональность, дольше доступ. А>Какой use_casе на практике ?
Выдать клиенту dictionary в который он не сможет дописать и удалять элементы. Например, текущий конфиг.
Здравствуйте, Аноним, Вы писали:
А>Не давать клиентам возможность менять словарь.
Интересно, почему сие было достигнуто классом-оберткой, а не разделением интерфейса.
Re[4]: ReadonlyDictionary vs Dictionary
От:
Аноним
Дата:
12.06.13 09:57
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Аноним, Вы писали:
А>>Да добавить нельзя, создан только ради этого ? Меньшая функциональность, дольше доступ. А>>Какой use_casе на практике ?
Doc>Выдать клиенту dictionary в который он не сможет дописать и удалять элементы. Например, текущий конфиг.
А не лучше такие статичные конфиги делать в виде жестких полей ?
Вместо
IDictionary<string,string>
давать
public class Config
{
public string Path1 { get; }
public int Timeout { get; }
}
ведь
dictionary["Очепятка"] обнаружится только в Runtime,
а
Config.Очепятка на этапе компиляции + Config возвращает типизированные значения,
а из словаря нужно будет их преобразовывать в нужный тип.
Здравствуйте, Аноним, Вы писали:
А>А не лучше такие статичные конфиги делать в виде жестких полей ?
По ситуации. Свойствами можно если все ключи конфига известны при создании такого класса.
А если там есть что-то типа секции <appSettings> из внутри может быть сколько угодно каких-то пар "ключ-значение"?
Так что по ситуации.
Re[5]: ReadonlyDictionary vs Dictionary
От:
Аноним
Дата:
12.06.13 12:05
Оценка:
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Аноним, Вы писали:
А>>Не давать клиентам возможность менять словарь. 0>Интересно, почему сие было достигнуто классом-оберткой, а не разделением интерфейса.
А как вы себе это представляете?
Объект обычного словаря возвращает интерфейс 'только для чтения'?
Здравствуйте, Аноним, Вы писали:
А>Да добавить нельзя, создан только ради этого ? Меньшая функциональность, дольше доступ. А>Какой use_casе на практике ?
одно название readonly уже нагружает код семантикой, и дает foolproof от изменений извне, это наверно больше полезно для производителей фреймворков и публичных библиотек, может он еще оптимизирован для GC
Здравствуйте, <Аноним>, Вы писали:
А>В чем назначение ReadonlyDictionary ? Какие преимущества он дает ?
Я думаю он нужен для того кода, который на вход принимает IDictionary, но при этом не хочется ему давать возможность менять, отлавливая такие попытки хотя бы в рантайме.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
. В пользу этой версии говорит тот факт, что и Dictionary и ReadOnlyDictionary реализуют одни и те же интерфейсы:
class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>, IReadOnlyDictionary<TKey, TValue> {...}
class ReadOnlyDictionary<TKey, TValue> : IDictionary<TKey, TValue>, IReadOnlyDictionary<TKey, TValue> {...}
В ReadOnlyDictionary методы IDictionary.Add и IDictionary.Remove спрятаны за счет явной реализации интерфейса + в их реализации выкидывается эксепшен.
На мой взгляд кривизна какая-то. Если метод хочет IDictionary, значит его функционал может менять словарь, если функционал метода не меняет словарь пускай требует только IReadOnlyDictionary. Если функционал метода может менять словарь словарь, а Вы ему даете ReadOnlyDictionary, то метод не сможет выполнить свои обязанности. Возникает вопрос зачем вам тогда вообще вызывать этот метод.
Еще одна кривизна на мой взгляд заключается в том, что множество членов IReadOnlyDictionary является подмножеством членов IDictionary. Здесь просится наследование интерфейсов, но нет, общие методы IDictionary<TKey, TValue> и IReadOnlyDictionary<TKey, TValue> продублированы. По мне класс ReadOnlyDictionary не нужен, а нужно
У меня есть версия почему MS так не сделала:
недженериковый IDictionary включает свойство IsReadOnly.
В Dictionary в реализации этого метода жестко возвращается false.
В ReadOnlyDictionary true.
Получается класс, который реализует IDictionary и в IsReadOnly возвращает true это не тоже самое, что класс реализующий IReadOnlyDictionary<TKey, TValue>.
Очередная кривизна IMHO.
Может кто-нибудь прояснить?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Re[7]: ReadonlyDictionary vs Dictionary
От:
Аноним
Дата:
12.06.13 19:59
Оценка:
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Аноним, Вы писали:
А>>А как вы себе это представляете? А>>Объект обычного словаря возвращает интерфейс 'только для чтения'? 0>Да.
В этом случае хитрый клиент может прикастить интерфейс к IDictionary, и всё-таки изменить содержимое словаря.
Здравствуйте, <Аноним>, Вы писали:
А>В этом случае хитрый клиент может прикастить интерфейс к IDictionary, и всё-таки изменить содержимое словаря.
А еще он может залезть через рефлекшен и поменять даже честный ReadOnlyDictionary. Только обычно такие вещи в дизайне не учитывают, потому что сознательные вредители обычно расцениваются как ССЗБ.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, igor-booch, Вы писали:
IB>На мой взгляд кривизна какая-то. Если метод хочет IDictionary, значит его функционал может менять словарь
Ты, судя по всему, не в курсе истории вопроса. IDictionary был в фреймворке начиная с версии 2.0. IReadonlyDictionary там нее было, хотя куча народу писали о его необходимости (тут даже кто то с жаром доказывал, что на самом деле IRODictionary низя низя). Потом они наелись самостоятельно, когда реализовывали розлин, и наконец то озаботились добавлением всяких RO фенечек в BCL (и, надеюсь, в C# 6). Но появилось оно только в 4.5. Огромное же количество кода уже было написано с использованием IDictionary, даже если словарь при этом не менялся. Вот для общения с ним и нужен ReadOnlyDictionary. И обрати внимание, не зря он в отдельном неймспейсе расположен.
IB>Еще одна кривизна на мой взгляд заключается в том, что множество членов IReadOnlyDictionary является подмножеством членов IDictionary. Здесь просится наследование интерфейсов
А зачем? Наследование интерфейсов штука вообще весьма специфичная. Некоторые тут доказывали, что она вообще не нужна. Можно пример сценария, где такое наследование оказалось бы полезным?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>Потом они наелись самостоятельно, когда реализовывали розлин
Объясните, пожалуйста поподробнее чего они наелись? Я так понимаю имеется ввиду http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx.
AVK>Огромное же количество кода уже было написано с использованием IDictionary, даже если словарь при этом не менялся.
Почему было недостаточно свойства IDictionary.IsReadOnly ?
AVK>Наследование интерфейсов штука вообще весьма специфичная. Некоторые тут доказывали, что она вообще не нужна.
Дайте пожалуйста ссылку на соответствующее обсуждение.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Re[4]: Всё-равно не понятно зачем ReadOnlyDictionary
Он самый.
AVK>>Наследование интерфейсов штука вообще весьма специфичная. Некоторые тут доказывали, что она вообще не нужна. IB>Дайте пожалуйста ссылку на соответствующее обсуждение.
Здравствуйте, igor-booch, Вы писали:
IB>Почему было недостаточно свойства IDictionary.IsReadOnly ?
1. Непрактично. Смысл IReadOnlyDictionary — в явной декларации намерений в коде, такие вещи надёжнее выражать через статическую типизацию. Попробуйте сами придумать сценарий использования этого свойства
2. По историческим причинам. В стандартных словарях из BCL (если мы говорим о .Net4 и младше) не было реализации словарей, у которых IsReadOnly возвращал бы true. Соответственно, у нас есть масса кода рассчитанная на изменяемые словари.
