Комментарии 17
Класс! Всё очевидное — просто! Добавлю в свой список маленьких, но полезных расширений.
НЛО прилетело и опубликовало эту надпись здесь
— Лябда-выражения, передача функций через параметр и прочие уменьшают скорость работы в разы.Какая скорость? Этот код выполняется один раз при старте программы!
— Проверка типа свойства и значения по-умолчанию легко решаются с помощью snippet'ов и расширений типа ReSharper.А если, спустя время, нужно будет свойство переименовать? Да и переименовывать будет другой человек — ведь можно и забыть поменять названия ВЕЗДЕ — тут сниппеты не помогут.
Какая скорость? Этот код выполняется один раз при старте программы!
Т.е. скорость запуска приложения это для вас не показатель? Видал я приложение из 10 простых бизнес-сущностей с парой экранов. Приложение запускалось >1,5 минут, при том что винда сейчас запускается около 2.
А если, спустя время, нужно будет свойство переименовать? Да и переименовывать будет другой человек — ведь можно и забыть поменять названия ВЕЗДЕ — тут сниппеты не помогут.
Скажите, как часто вам и в каком объеме приходится переименовывать свойства? У меня такое бывает от силы 1 раз за весь проект, и то чтобы исправить синтаксическую ошибку. Если для вас норма постоянно все переименовывать — это уже ошибка дизайна. Дальше скажу больше, что обычно на DP вешается биндинг в разметке. Так вот все равно никакой решарпер и никакие сниппеты вам не помогут внести изменения в XAML, все равно придется руками искать и менять.
Ну, если у девелоперов руки из *опы растут, то так оно и будет. Даю гарантию, что они при старте синхронно единичными запросами пол базы данных вытягивали. Если бизнес-приложение тупит, то практически в 100% случаев в этом виновато кривое обращение к БД.
Засеките время, которое тратиться на регистрацию всех свойств для DO. Уверяю вас, это очень долго. Не стоит нагружать данные операции еще и лямбда выражениями.
Программисты майкрасофта тоже не муд*ки, они тоже могли придумать такой сниппет, но однако этого не сделали по каким то соображениям.
Программисты майкрасофта тоже не муд*ки, они тоже могли придумать такой сниппет, но однако этого не сделали по каким то соображениям.
ну начнем с того, что засечь это время крайне сложно. не уверен, что даже профайлер сможет по-человечески его посчитать (хотя, по-идее должно получиться). но это неважно, потому что чаще всего причиной тормозов являются операции ввода/вывода и особенно, если эти операции выполняются по сети и еще особенней, если в потоке интерфейса (чтоб пользователь совсем офигел от тормозов). Даю руку на отсечение, что такие хаки с получением имени свойства сыграют ничтожно малую роль в процессе регистрации DP.
Какая скорость? Этот код выполняется один раз при старте программы!
Т.е. скорость запуска приложения это для вас не показатель? Видал я приложение из 10 простых бизнес-сущностей с парой экранов. Приложение запускалось >1,5 минут, при том что винда сейчас запускается около 2.
Это же сколько нужно таких свойств наклепать, чтобы задержка составила хотя-бы полсекунды?
Скажите, как часто вам и в каком объеме приходится переименовывать свойства? У меня такое бывает от силы 1 раз за весь проект, и то чтобы исправить синтаксическую ошибку. Если для вас норма постоянно все переименовывать — это уже ошибка дизайна. Дальше скажу больше, что обычно на DP вешается биндинг в разметке. Так вот все равно никакой решарпер и никакие сниппеты вам не помогут внести изменения в XAML, все равно придется руками искать и менять.
Не часто, но как-то сложился уже стиль программирования — если можно сделать строгую типизацию, то нужно её делать. Везде где можно. Магические числа и строки, не являющиеся текстовыми сообщениями, меня в коде немного напрягают. Для большинства бизнес-приложений микросекунды роли не играют, а вот понятность кода и возможность его статического анализа — очень даже.
Этот код выполняется один раз при старте программы!
Даже не при старте, а при первом обращении к классу содержащему данное свойство. К примеру, при первом создании кастомного контрола. Не считаю это значимой потерей производительности.
А откуда такие утверждения?
Примерно 0.3 миллисекунды на единичный вызов с передачей Expression(понятно что внутри там дерево строится). Около 300 миллисекунд на миллион вызовов. Ну думаю понятно, почему разница не линейная.
0,001 миллисекунда на один вызов функции с передачей функции как параметр. 0,6 миллисекунды на миллион вызовов. Если говорить о колле делегата, то при вызове чего-то типа ()=>1 и аналогичной статической функции разница будет 5 и 0.3 миллисекунды соотственно на опять же на миллион вызовов. И то я подозреваю во втором случае просто инлайн отрабатывает. Если функция будет делать что-то серьезно скорее всего разница практически исчезнет.
Чтобы действительно уменьшить производительность в разы используя лямбда-выражения и передачу функций как параметры надо ой как постараться.
Лябда-выражения
Примерно 0.3 миллисекунды на единичный вызов с передачей Expression(понятно что внутри там дерево строится). Около 300 миллисекунд на миллион вызовов. Ну думаю понятно, почему разница не линейная.
передача функций через параметр
0,001 миллисекунда на один вызов функции с передачей функции как параметр. 0,6 миллисекунды на миллион вызовов. Если говорить о колле делегата, то при вызове чего-то типа ()=>1 и аналогичной статической функции разница будет 5 и 0.3 миллисекунды соотственно на опять же на миллион вызовов. И то я подозреваю во втором случае просто инлайн отрабатывает. Если функция будет делать что-то серьезно скорее всего разница практически исчезнет.
Чтобы действительно уменьшить производительность в разы используя лямбда-выражения и передачу функций как параметры надо ой как постараться.
Шаблон на ReSharper'e сводит все проблемы к нажатию одной комбинации клавиш и вписывании названия DependencyProperty один раз.
Стандартный снипет позволяет вводить все части по 1 разу. Чуть модифицировав это снипет можно еще и сократить количество ввода.
Скажите, в этой строчке
у вас ошибка и пропущено слово static?
А если нет, то объясните мне, как вы от статик свойств и статик callback перешли к нестатик, и в каком тогда экземпляре объекта будет выполнятся этот код?
private void OnIntValuePropertyChanged(DependencyPropertyChangedEventArgs<int> e)
{
}
у вас ошибка и пропущено слово static?
А если нет, то объясните мне, как вы от статик свойств и статик callback перешли к нестатик, и в каком тогда экземпляре объекта будет выполнятся этот код?
Скажите, в этой строчке
у вас ошибка и пропущено слово static?
А если нет, то объясните мне, как вы от статик свойств и статик callback перешли к нестатик, и в каком тогда экземпляре объекта будет выполнятся этот код?
private void OnIntValuePropertyChanged(DependencyPropertyChangedEventArgs<int> e)
{
}
у вас ошибка и пропущено слово static?
А если нет, то объясните мне, как вы от статик свойств и статик callback перешли к нестатик, и в каком тогда экземпляре объекта будет выполнятся этот код?
Вот в этом месте static превращается в нестатик:
и выполняется он в контексте того объекта в который в статик callback-е передается в первом параметре
private static PropertyChangedCallback ConvertCallback<TProperty>(Func<T, PropertyChangedCallback<TProperty>> propertyChangedCallbackFunc)
и выполняется он в контексте того объекта в который в статик callback-е передается в первом параметре
public delegate object CoerceValueCallback(DependencyObject d, object baseValue);
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Упрощение регистрации и работы с DependencyProperty