Здравствуйте, Bigger, Вы писали:
B>автор учитесь
Ничего выдающегося, обычный код начинающих (а иногда и не начинающих, если им по рукам за такое не били), не имеющий национальности. На шедевр, достойный опубликования, не тянет .
Bigger пишет: > if (ds.Tables[0].Rows[0]["idrole"] != null && > Convert.ToString(ds.Tables[0].Rows[0]["idrole"]).Length != 0 && > new Guid(Convert.ToString(ds.Tables[0].Rows[0]["idrole"])) != Guid.Empty) > { > _role = new UserRole(new Guid(Convert.ToString(ds.Tables[0].Rows[0]["idrole"]))); > }
Чето мне подсказывает что конструктор UserRole выглядит где-то так, а
студент просто не осознал разницы между null и DBNull:
public UserRole(guid userGuid)
{
if (userGuid == null)
throw new ArgumentNullException("bla-bla-bla");
if (userGuid == Guid.Empty)
throw new ArgumentException("bla-bla-bla");
}
Однако, ежели по-взрослому, код должен выглядеть так:
viellsky пишет: > Ну если так — то в паттерне не хватает throw ArgumentException на все > неожиданные значения.
Живо себе представил:
public UserRole(Guid userGuid)
{
...............
if (userGuid.ToString == "{B2A91D68-C182-4A43-8FC8-00C3F27A1321}")
throw new ArgumentException("Этот гуид занят");
if (userGuid.ToString == "{86FC8A70-77A7-4D9B-8B48-EC4230E444C9}")
throw new ArgumentException("Этот гуид занят");
if (userGuid.ToString == "{AD0FE067-8B88-428B-B62D-46D4132ED663}")
throw new ArgumentException("Этот гуид занят");
if (userGuid.ToString == "{374D2CE1-1567-460A-8692-84007BCFA2FF}")
throw new ArgumentException("Этот гуид занят");
if (userGuid.ToString == "{5291D024-5F36-456F-9E35-7B34881D9DC7}")
throw new ArgumentException("Этот гуид занят");
if (userGuid.ToString == "{CF54D104-5E7F-4240-9384-C214D092B1E5}")
throw new ArgumentException("Этот гуид занят");
if (userGuid.ToString == "{8B397B4E-174A-4427-A7BF-CD588AAB2F64}")
throw new ArgumentException("Этот гуид занят");
......
}
... и так пару миллиардов раз....
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Bigger wrote:
> Коллеги, объясните зачем добавлять контрол и сразу его грохать
Ну... Вначале программиста попросили добавить, потом поглядели — и решили что было лучше и попросили убрать.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Предположу, что изначально написанный код глючил, и каким-то образом появлялись UserRole с Guid.Empty. В результате, автор добавил строчку для "профилактики"
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Bigger, Вы писали:
B>>автор учитесь E>Ничего выдающегося, обычный код начинающих (а иногда и не начинающих, если им по рукам за такое не били), не имеющий национальности. На шедевр, достойный опубликования, не тянет .
Опубликовать более достойное нельзя, автор может расстроится.
Код в стиле фортран, когда выполнение одного метода расстянуто по 3-6 классам
Здравствуйте, Aviant, Вы писали:
A>Здравствуйте, Ромашка, Вы писали:
Р>>Этот шаблон програмирования называется maniac pattern.
A>Не самый плохой паттерн кстати. Лучше чем "я точно знаю что в этот метод все переменные придут проинициализированные как надо"
Ну если так — то в паттерне не хватает throw ArgumentException на все неожиданные значения.
Здравствуйте, Xander Zerge, Вы писали:
XZ>Здравствуйте, Bigger, Вы писали:
B>>автор учитесь
XZ>Если в индийском помещении несколько ламп, выключатели выглядят так: XZ>
XZ>Отсюда: http://tema.ru/travel/india-2/
Ага. Зато у наших все несколько выключателей расбросаны по всему помещению с никому неизвестной логикой — причем некоторые выключатели ничего не выключают, а некоторые лампы ничем не выключаются...
Знакомо? У меня в доме на этаже именно так.
А еще я видел немало программного кода, в котором "много-много выключателей"...
А как бы вы реализовали подобную задачу: "в помещении несколько ламп"?
Здравствуйте, The Lex, Вы писали:
TL>Ага. Зато у наших все несколько выключателей расбросаны по всему помещению с никому неизвестной логикой — причем некоторые выключатели ничего не выключают, а некоторые лампы ничем не выключаются...
Это бардак просто. У Лебедева в "идиотеке" таких примеров много. Вот:
Здравствуйте, Aviant, Вы писали:
Р>>Этот шаблон програмирования называется maniac pattern.
A>Не самый плохой паттерн кстати. Лучше чем "я точно знаю что в этот метод все переменные придут проинициализированные как надо"
Не "я точно знаю…" , а "Если переменные придут непроинициализированными, то тот, кто вызвал его вызвал должен будет справедливо получить по рукам"
"Если случится исключение, то мы ещё посмотрим кто не прав. Может не автор данного кода, не тот, кто его вызывает, а тот, кто создал этот самый датасет"
Суть заключается не в коде как таковом, а в контракте метода\класса\коллера. Код может быть написан как угодно (с проверками или без), главное, что бы это соответствовало его контракту и этот контракт не был бы непродуманным или плохопродуманным.
А "maniac pattern" — это проглатывание (зачастую своих же собственных) ошибок. От такого паттерна следующий шаг:
try {
// … some operations I …
} catch(Exception ex) {
}//try
// … some operations II …
Help will always be given at Hogwarts to those who ask for it.
Гораздо более строгого порицания, на мой взгляд, заслуживает тот факт, что Guid.Empty используется как какое-то "специальное значение".
Вот это уже точно "клиника" и неграмотность. Это точно такой же гуид, как и все остальные. Рассматривать, по крайней мере, его следует именно так. И если где-то он _по ошибке_ появляется, то надо избегать именно того "ошибочного" случая, а не ставить проверки и обосабливать такое значение.
То же самое, зачастую, можно сказать и про String.Empty, когда речь идёт о чем-то БазаДанных-подобном. Есть строковое поле, "первичный ключ", как было сказано. Она должна быть либо DbNull либо непустая строка. Это же бизнес-правило, правильно я понимаю? Так значит надо давать по ушам тому, кто позволил сохранить невалидные значения (в датасете, в рассматриваемом случае) и поругать того, кто это "пропустил", не заметил нарушения бизнес-правила.
Если же бизнес-правила у вас такие, что "первичный ключ" может быть пустой строкой или не нулевым гуидом или null или DbNull, то это странные правила .
Help will always be given at Hogwarts to those who ask for it.
Р>Этот шаблон програмирования называется maniac pattern.
А мне как-то кажется, что этот и оригинальный шаблон называется copy-paste паттерн. Самое плохое в этом коде то, что невыделены переменные, у куча значений вычисляется несколько раз. Даже если компилятор оптимизирует — нечитабельно это совершенно. А тут на Guid.Empty все накинулись. Неужели так много народа практикуют запись типа Guid(Convert.ToString(ds.Tables[0].Rows[0]["idrole"])) и считает это нормальным ?
Здравствуйте, elmal, Вы писали:
E>Неужели так много народа практикуют запись типа Guid(Convert.ToString(ds.Tables[0].Rows[0]["idrole"])) и считает это нормальным ?
А как ты предлагаешь получать значение типа Guid из значения типа object, в котором хранится строковое представление гуида
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>А как ты предлагаешь получать значение типа Guid из значения типа object, в котором хранится строковое представление гуида
Очень просто — guid = Guid(guidStr). А перед вызовом агрументу напишу, что guidStr = Convert.ToString(roleGuidRow). После определенного момента стал предпочитать максимально избегать по возможности длинных строчек, рвотные рефлексы. А особенно к copy-paste это относится. А в исходном примере мало того, что строчка длинная, так аргумент функции еще и скопипастен
Здравствуйте, ., Вы писали:
.>Bigger wrote:
>> Коллеги, объясните зачем добавлять контрол и сразу его грохать
int n = _controlPanel.Controls.Count;
if (cashObject.panel.Size != _controlPanel.Size)
{
cashObject.panel.Size = _controlPanel.Size;
cashObject.panel = _getControl(cashObject.panel, cashObject.that);
}
_controlPanel.Controls.Add(cashObject.panel);
cashObject.panel.BringToFront();if (n < _controlPanel.Controls.Count)
while (n-- > 0)
_controlPanel.Controls.RemoveAt(_controlPanel.Controls.Count - 1);
BringToFront — поднимает контрол "наверх" в коллекции. Число добавленных контролов равно числу находящихся в коллекции, если они имели место быть. Если сперва удалять, потом добавлять, будет присутствовать раздражающее мерцание. Поэтому было принято решение сперва добавить "новые", а потом удалить "старые" контролы.
Не рубите с плеча. Убьёте проект.
Здравствуйте, Ромашка, Вы писали:
Р>Чето мне подсказывает что конструктор UserRole выглядит где-то так, а Р>студент просто не осознал разницы между null и DBNull:
Р>
Р>public UserRole(guid userGuid)
Р>{
Р> if (userGuid == null)
Р> throw new ArgumentNullException("bla-bla-bla");
Р> if (userGuid == Guid.Empty)
Р> throw new ArgumentException("bla-bla-bla");
Р>}
Р>
Исключения в конструкторе? Ццц
И точно не помню, но разве guid у нас нуллабле тип?
.
, а 
