Здравствуйте, Kluev, Вы писали: K>чем бы заменить слишком длинное имя item_get_or_create?
0. Конвенция именования
1. Если ситуация отсутствия запрошенного ключа в коллекции — редкая, то лучше ничего в нее не добавлять, а в хелперном методе возвращать один и тот же дефолтный объект (Re[17]: get_or_create как правильно назвать
). При этом метод должен называться не get_or_create_item , а get_item_or_default.
2. Если всё как раз наоборот, и в большинстве случаев объекта всё еще нету, то лучше сосредоточиться на том, что объект создается.
То есть метод называется create_item, а в комментах к нему написано, что в случае наличия готового айтема он возвращает его, а не новый.
3. item_get_or_create — не слишком хороший выбор.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
_FR>>Как альтернатива TryGetValue, можно было бы либо
_FR>>class Hashtable : …
_FR>>{
_FR>> public static readonly object NotFound = new object();
AVK>Нафик нафик. Никак вон с DBNull размахаться не получается
ИМХО, лучше чем null. И не хуже, чем -1 в IList<T>.IndexOf и иже с ним. Но, естественно, далеко не образец.
_FR>>struct Option
_FR>>{
_FR>> public bool HasValue { get; }
_FR>> public object Value { get; }
_FR>>}
AVK>Этот вариант уже вполне нормален, но в большинстве случаев синтаксически немножко более избыточен, чем TryGetValue. Оба этих варианта легко переходят один к другому при помощи простеньких статических хелперов.
Плохо в обоих вариантах то, что надо либо запрещать добавлять в словарь Hashtable.NotFound/Option, либо опять же будет неоднозначность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, AndrewVK, Вы писали:
_FR>>ИМХО, лучше чем null. AVK>Вот даже и не знаю, какое из двух кривых решений лучше. _FR>> И не хуже, чем -1 в IList<T>.IndexOf AVK>Хуже. Потому что -1 того же типа, в отличие от.
А почему тот же тип — лучше? Получаются примерно те же грабли, что и тут
.
Как-то я видел фреймворк для работы с БД, в котором null-значения передавались так:
class CustomConverter
{
public const int Int32Null = Int32.MinValue;
// … И так далее в том же духе для остальных типовpublic static bool IsNull(int value) { /* */ }
public static bool IsNull(object value) { /* образно говоря, switch/if по типам */ }
}
С одной стороны, да, хорошо: специальные значения не портят "чистоту" при работе с "нормальными" значениями. А в итоге те же описанные выше грабли — надо не забывать повсюду ставить проверки и при работе со стандартными, собственно, типами (int, double, decimal) пользоваться "услугами" класса CustomConverter, в котором сосредоточена логика проверки значений, обращений к которому получается так много, что кажется ради него вся работа и задумана.
С DBNull же Value (как со специальным значение, которое нельзя ни с чем перепутать) — как только хочешь что-то посчитать, делаешь приведение типа и получаешь по рукам, если не проверил данные.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Lloyd, Вы писали:
L>Умные дядьки рекомендуют для облегчения жизни явно разделять функции запрашивающие состояние и меняющие его. L>Так что бей на два метода и не ошибешься.
Согласен, хотя я сам и сделал в аналогичной ситуации 3 метода, но сейчас всеже склоняюсь к двум. Но у меня особый случай — использую паттерн многопточности SWMR и операции чтения должны быть явно отделены от операций записи, иначе получаем лишние блокировки в ненужных местах...
А метод на самом деле очень полезный. Как альтернативу думаю сделать чтото вроде внешней функции GetOrCreate(map, key). Внешние функции хоть и длинные, но это не напрягает, вот странное дело.
ЗЫ: Я таки придумал как коротко обозвать этот метод: goc_item(keys...) (goc == сокращение от Get Or Create).
Здравствуйте, AndrewVK, Вы писали:
_FR>>А почему тот же тип — лучше? AVK>Более очевидный код получается.
Когда Hashtable возвращает null, и на основании этого кажется, что словарь не нашёл значение, код тоже кажется очевидным. Да?
_FR>>Получаются примерно те же грабли, что и тут
. AVK>Я, уж извини, не хочу искать в этой простыне грабли. Можно поконкретнее?
В том, что можно не сделать проверку и узнать об этом неизвестно когда, если вообще узнать.
_FR>>Как-то я видел фреймворк для работы с БД, в котором null-значения передавались так: AVK>Неверная аналогия. Индекс равным -1 быть не может в принципе, в отличие от.
Не может, но во избежании ошибок повсюду этот индекс приходится проверять, даже там, где, я уверен, ошибки быть не может. Потому что если всё же ошибка в этом месте случится, то отыскать, где именно произошли грабли станет чертовски трудно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Когда Hashtable возвращает null, и на основании этого кажется, что словарь не нашёл значение, код тоже кажется очевидным. Да?
Нет. Я говорил исключительно про -1 у IndexOf.
_FR>В том, что можно не сделать проверку и узнать об этом неизвестно когда, если вообще узнать.
Такое и с TryGetValue лехко можно учудить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
K>Привет всем. K>Решил навести порядок в именах, не могу подобрать хорошеее и правильное название для функции.
K>Имеем: K>
K>Item* item_add(keys...); // создает новый элемент в контейнере в соотвестивии с ключом (или ключами) keys
K>Item* item_get(keys...); // возвращает элемент по keys или NULL
K>Item* item_get_or_create(keys...); // возвращает существующий элемент если он есть или создает новый
K>
K>чем бы заменить слишком длинное имя item_get_or_create?
Получение и правку всегда лучше разносить. Хотя бы из-за разного отношения к транзакциям и блокировкам.
