Do if allowed
От: Kingofastellarwar Украина  
Дата: 29.11.11 14:17
Оценка:
долго такая мелочь интерсовала, как всё таки писать?

типа правильнее, но нада каждый раз проверять перед вызовом
if(m->CanDoIt)
{
    m->DoIt();
}


или

не очень понятно, будет что-то сделано или нет при вызове
void Class::DoIt()
{
   if(CanDoIt)
   {
       ...
   }
}
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re: Do if allowed
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 29.11.11 14:30
Оценка:
Можно сделать DoIt и bool TryDoIt по аналогии с System.Number.Parse*/TryParse*, .
Ce n'est que pour vous dire ce que je vous dis.
Re: Do if allowed
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.11.11 14:42
Оценка: 2 (2) +3
Здравствуйте, Kingofastellarwar, Вы писали:

K>долго такая мелочь интерсовала, как всё таки писать?

K>типа правильнее, но нада каждый раз проверять перед вызовом

"Правильность" и того, и другого кода зависит от условий, в которых он используется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Do if allowed
От: jazzer Россия Skype: enerjazzer
Дата: 29.11.11 14:59
Оценка: 1 (1) +1
Здравствуйте, Kingofastellarwar, Вы писали:

K>долго такая мелочь интерсовала, как всё таки писать?


"сделать, если разрешено" имеет как минимум два измерения:

поведение:
1) если не разрешено, ничего не делать
2) если не разрешено, сигнализировать (например, бросить исключение)

знание вызывающего кода:
1) вызвающий код знает о существовании проверок (т.е. может проверить сам, придумать обходные пути и т.п.)
2) вызвающий код не должен знать о существовании проверок (т.е. глядя на него, невозможно сказать, есть какие-то проверки в программе или нет. Ну и можно использовать как с компонентами, содержащими проверки, так и с несодержащими)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Do if allowed
От: vdimas Россия  
Дата: 29.11.11 23:03
Оценка: +1
Здравствуйте, Kingofastellarwar, Вы писали:

K>долго такая мелочь интерсовала, как всё таки писать?


K>типа правильнее, но нада каждый раз проверять перед вызовом

K>
K>if(m->CanDoIt)
K>{
    m->>DoIt();
K>}
K>


K>или


K>не очень понятно, будет что-то сделано или нет при вызове

K>
K>void Class::DoIt()
K>{
K>   if(CanDoIt)
K>   {
K>       ...
K>   }
K>}
K>


Для однопоточного доступа не важно, но для доступа к "m" из многих потоков первый способ является популярной ошибкой (например, при работе с сокетами). Как правильно сказали, можно сделать две версии, бросающую исключения и не бросающую:
void DoIt();
bool TryDoIt();
Re: Do if allowed
От: B0FEE664  
Дата: 30.11.11 17:22
Оценка:
Здравствуйте, Kingofastellarwar, Вы писали:

Однозначно второй вариант за исключением случаев, когда производительность очень важна.
И каждый день — без права на ошибку...
Re: Do if allowed
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.12.11 13:41
Оценка: 2 (1) +2
Здравствуйте, Kingofastellarwar, Вы писали:

>не очень понятно, будет что-то сделано или нет при вызове

void Class::DoIt()
{
   if(!CanDoIt)
       return;
   ...
}


Называется этот паттер guard condition, экономит массу времени и усилий при чтении/поддержке кода. Идея в том, что вложеность блоков сильнее всего коррелирует с количетсвом ошибок.
Re: Do if allowed
От: b-3 Россия  
Дата: 19.12.11 20:25
Оценка:
Здравствуйте, Kingofastellarwar, Вы писали:

K>долго такая мелочь интерсовала, как всё таки писать?


K>типа правильнее, но нада каждый раз проверять перед вызовом

K>
K>if(m->CanDoIt)
K>{
    m->>DoIt();
K>}
K>


K>
K>void Class::DoIt()
K>{
K>   if(CanDoIt)
K>   {
K>       ...
K>   }
K>}
K>


Проверки типа CanDoIt, мне кажется, уместны только в одном случае: когда есть виртуальный интерфейс, в реализации которого часть методов не поддерживается — и нужно проверить допустимость связывания компонент приложения. Т.е. например в фреймворке абстрактный класс "поток" (Read(), Write(), CanRead(), CanWrite()...) который передаётся в конструктор, для выполнения записи. Можно проверить аргумент на CanWrite, кинуть исключение. Примерно так дотнетовский System.IO.Stream спроектирован.

В остальных случаях операцию желательно делать атомарной, чтобы не создавать сложностей на пустом месте и не провоцировать ошибок. При необходимости жёстких оптимизаций применить inline. Вообще говоря, не очень ясна логика "если не можем, то ничего не делаем" — разве что это spinlock? Или там ветвление, разные методы в зависимости от состояния вызываются?
Забанен с формулировкой "клинический дисидент".
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.