Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Можно воспользоваться Fody / PropertyChanged
Из кода достаточно одного атрибута, вложенные коллекции, правда, не потянет.
Из кода достаточно одного атрибута, вложенные коллекции, правда, не потянет.
Да, менеджеров зависимостей довольно много. Но я бы предпочёл иметь дело с двумя простенькими методами, чем со сторонним проектом, делающим тоже самое. Во-первых, если придёт новый человек, который с этим сторонним проектом не работал, то придётся ему показывать, что да как. Ну или он сам потратит время, чтобы почитать мануалы или разобраться интуитивно. Или если в проекте есть ошибка, например он некорректно обрабатывает вложенные коллекции, то потребуется больше времени, чтобы понять, что ошибка в чёрном ящике, а не в собственном коде. А когда работаешь с двумя простенькими методами, у которых есть summary, то сразу видно 1)как это работает и 2)где ошибка.
Сами методы не слишком простенькие (одна подписка на событие без отписки уже намекает), а код регистрации совсем не простенький.
Объем демо и объяснений в вашем случае требуется не меньший.
Дополнительно вплетение кода гарантирует отсутствие целого класса ошибок.
Отлаживать его вроде как тяжелее, зато сама отладка потребуется куда реже.
Объем демо и объяснений в вашем случае требуется не меньший.
Дополнительно вплетение кода гарантирует отсутствие целого класса ошибок.
Отлаживать его вроде как тяжелее, зато сама отладка потребуется куда реже.
Сами методы не слишком простенькие, а код регистрации совсем не простенький.Это субъективно. Вот что объективно: в приведенном мной примере 2 небольших метода, в указанном вами проекте множество немаленьких классов. Не знаю сколько из них занимаются непосредственно управлением зависимостями, но в любом случае, раз там всё построено на изменении кода в момент компиляции, то кода наберётся немало.
одна подписка на событие без отписки уже намекаетПример кода отражает основной смысл, который в него заложен (имхо, такими и должны быть примеры — краткими и конкретными). Чтобы память не текла, используйте слабые ссылки. Это, на мой взгляд, best practise при практически любом использовании событий.
Объем демо и объяснений в вашем случае требуется не меньшийНебольшое summary и сам код — вот лучшее объяснение. Пример использования — вот лучшее демо (вы же не будете копировать эти методы в свой проект, если не собираетесь их сразу же использовать, верно?).
Отлаживать его вроде как тяжелее, зато сама отладка потребуется куда реже.На основании чего вы делаете такие выводы? Похоже на гадание на кофейной гуще — что и сколько раз потребуется отлаживать. Да, там 10 контрибьюторов, но сам проект объективно сложнее устроен. Отлаживать сторонний большой проект сложнее, чем два небольших метода — с этим согласен.
Это субъективно. Вот что объективно: в приведенном мной примере 2 небольших метода, в указанном вами проекте множество немаленьких классов. Не знаю сколько из них занимаются непосредственно управлением зависимостями, но в любом случае, раз там всё построено на изменении кода в момент компиляции, то кода наберётся немало.
Объем библиотечного кода имеет малое значение по сравнению с объемом кода клиентского, а здесь у Fody большое преимущество.
Пример кода отражает основной смысл, который в него заложен (имхо, такими и должны быть примеры — краткими и конкретными). Чтобы память не текла, используйте слабые ссылки. Это, на мой взгляд, best practise при практически любом использовании событий.
Т.е. ваши методы это только пример или, скажем, прототип? Тогда сравнивать объем кода и т.п. с уже готовой библиотекой нелогично.
Небольшое summary и сам код — вот лучшее объяснение. Пример использования — вот лучшее демо (вы же не будете копировать эти методы в свой проект, если не собираетесь их сразу же использовать, верно?).
Я вообще не копирую код. Или использую библиотеку или пишу свое, ознакомившись сначала с чужими аналогами.
На основании чего вы делаете такие выводы? Похоже на гадание на кофейной гуще — что и сколько раз потребуется отлаживать. Да, там 10 контрибьюторов, но сам проект объективно сложнее устроен. Отлаживать сторонний большой проект сложнее, чем два небольших метода — с этим согласен.
На основании опыта использования чужих библиотек в своих проектах. 99% отладки приходится на свой код, а процент своих ошибок еще выше. Предпочитаю не писать свои велосипеды, если доступны готовые приемлемого качества.
При использовании Fody шансов сделать свою ошибку заметно меньше, что мне и требуется.
Тут нужно смотреть на известность и надёжность стороннего проекта, а также на развивающее его сообщество. Я про конкретно этот проект впервые слышу, так что не могу дать свою оценку. Если вы уверены, что с проектом проблем не возникнет и вам не придётся объяснять новому человеку на проекте, как им пользоваться, то бога ради, используйте. Если такой уверенности нету, то можете использовать мои два небольших метода. Поскольку методы небольшие и в них несложно разобраться, то 1)новый человек на проекте наверняка разберётся, увидев пример и исходный код 2)в случае чего можно будет легко отладить код и найти проблему — как в клиентском коде, так и в коде этих методов.
В любом случае, теперь вы знаете ещё один способ реализации binding-а вычислимых свойств в WPF.
В любом случае, теперь вы знаете ещё один способ реализации binding-а вычислимых свойств в WPF.
1. Этот проект существует уже лет пять минимум. То, что вы про него не слышали говорит о вашей неосведомленности, а не его сырости.
2. В отличие от вашей реализации не добавляет новых библиотек к вашей сборке. Все изменения делаются в процессе сборки. Тем самым как увеличивается производительность, так и уменьшается размер приложения.
2. В отличие от вашей реализации не добавляет новых библиотек к вашей сборке. Все изменения делаются в процессе сборки. Тем самым как увеличивается производительность, так и уменьшается размер приложения.
Никто не говорил про сырость, речь шла про надёжность и известность. Кстати, первый коммит был сделан примерно 3 года назад, 7 июля 2012.
Давайте представим, какие сложности могут возникнуть при использовании этой библиотеки.
1)Имена свойств передаются в атрибуты через строки, что вызывает сложности при навигации и переименовании: в параметры атрибутов можно передавать только константы, и код, вычисляющий имя свойства, задействовать не удастся.
2)По слова пользователей, Fody не поддерживает обработку вложенных коллекций. Если возникнет такая необходимость, то можно: а)написать разработчикам Fody и ждать у моря погоды (но станет ли ждать заказчик?) б)использовать другой менеджер зависимостей в)использовать код из этой статьи.
Ну давайте посмотрим, насколько отличается код. В случае Fody мы непосредственно вызываем два RaisePropertyChanged, а в случае кода из статьи — вызываем один RaisePropertyChanged, а второй вызывается как подписчик. Насколько команд процессора во втором случае больше? На одного подписчика больше, значит на одну итерацию цикла больше, примерно 7 команд: инкрементация счётчика цикла, проверка на выход из цикла, переход на нужную инструкцию, 4 операции вызова метода (вычисление адреса метода по объекту и смещению, переход, копирование регистров процессора 2 раза). Поскольку это происходит не в режиме ядра, то возможно ОС выполнит какие-то действия. Грубо говоря, пусть будет с запасом 20 операций. Сколько там у вас в ViewModel обычно вычислимых свойств? А чего мелочится, пусть будет 20. Большая такая ViewModel. И допустим отображаете вы не одно поле, а целую таблицу из 100 элементов, на большом таком мониторе. Итого 40000 операций. Допустим пользователь пользуется программой на смартфоне с процессором в 1 ГГц. Итого пользователь будет ждать аж на целых 0,00004 секунды больше! Бедный пользователь. Мне почти стыдно. Уже бегу усложнять процесс сборки и отладки солюшена, чтобы страдал я и мои коллеги, а не пользователь. Шучу. Коллег жалко. И кстати, я не против Fody, я против экономии на спичках.
Давайте представим, какие сложности могут возникнуть при использовании этой библиотеки.
1)Имена свойств передаются в атрибуты через строки, что вызывает сложности при навигации и переименовании: в параметры атрибутов можно передавать только константы, и код, вычисляющий имя свойства, задействовать не удастся.
2)По слова пользователей, Fody не поддерживает обработку вложенных коллекций. Если возникнет такая необходимость, то можно: а)написать разработчикам Fody и ждать у моря погоды (но станет ли ждать заказчик?) б)использовать другой менеджер зависимостей в)использовать код из этой статьи.
как увеличивается производительность, так и уменьшается размер приложения
Ну давайте посмотрим, насколько отличается код. В случае Fody мы непосредственно вызываем два RaisePropertyChanged, а в случае кода из статьи — вызываем один RaisePropertyChanged, а второй вызывается как подписчик. Насколько команд процессора во втором случае больше? На одного подписчика больше, значит на одну итерацию цикла больше, примерно 7 команд: инкрементация счётчика цикла, проверка на выход из цикла, переход на нужную инструкцию, 4 операции вызова метода (вычисление адреса метода по объекту и смещению, переход, копирование регистров процессора 2 раза). Поскольку это происходит не в режиме ядра, то возможно ОС выполнит какие-то действия. Грубо говоря, пусть будет с запасом 20 операций. Сколько там у вас в ViewModel обычно вычислимых свойств? А чего мелочится, пусть будет 20. Большая такая ViewModel. И допустим отображаете вы не одно поле, а целую таблицу из 100 элементов, на большом таком мониторе. Итого 40000 операций. Допустим пользователь пользуется программой на смартфоне с процессором в 1 ГГц. Итого пользователь будет ждать аж на целых 0,00004 секунды больше! Бедный пользователь. Мне почти стыдно. Уже бегу усложнять процесс сборки и отладки солюшена, чтобы страдал я и мои коллеги, а не пользователь. Шучу. Коллег жалко. И кстати, я не против Fody, я против экономии на спичках.
1. Fody/PropertyChanged это продолжение проекта PropertyChangedWeaver, про который вы конечно не слышали.
2.Действительно, чего экономить то? Процессор чай казенный. Особенно экономия бессмысленна на мобильных девайсах. Никто же далеко от розетки не отходит ;)
2.Действительно, чего экономить то? Процессор чай казенный. Особенно экономия бессмысленна на мобильных девайсах. Никто же далеко от розетки не отходит ;)
Вы всерьез считаете что по критерию «известность-надежность» ваше решение превосходит PropertyChanged.Fody?
Неужели вы думаете, что кто-нибудь в здтавом уме и твердой памяти будет копипастить код из интернета, написанный за полтора часа?
Вложенные коллекции? Как-то вот ни разу нужды не возникало. А когда возникало — коллекции были виртуальные.
Неужели вы думаете, что кто-нибудь в здтавом уме и твердой памяти будет копипастить код из интернета, написанный за полтора часа?
Вложенные коллекции? Как-то вот ни разу нужды не возникало. А когда возникало — коллекции были виртуальные.
Можно еще использовать RX для подобных вещей.
См, например, stackoverflow.
При этом вы получаете:
1. Более простой код подписки/отписки (например, насколько легко отписаться от всех event'ов сейчас? Модель может это сделать сама, или только ждать, пока UI это произведет? А а RX от подписки может отказаться и слушатель, и publisher)
2. Возможность разделения канала и способа аггрегации: т.е. по одному пути идут изменения (+ фильтры и т.д.), а в совсем других методах вы описываете, как аггрегировать.
3. Есть уже некоторые готовые аггрегации, такие как сумма, максимум и пр.
См, например, stackoverflow.
При этом вы получаете:
1. Более простой код подписки/отписки (например, насколько легко отписаться от всех event'ов сейчас? Модель может это сделать сама, или только ждать, пока UI это произведет? А а RX от подписки может отказаться и слушатель, и publisher)
2. Возможность разделения канала и способа аггрегации: т.е. по одному пути идут изменения (+ фильтры и т.д.), а в совсем других методах вы описываете, как аггрегировать.
3. Есть уже некоторые готовые аггрегации, такие как сумма, максимум и пр.
Вы меня, конечно, извините, но код пока не очень даже на прототип тянет.
Мешает серия багов:
1. Нет отписок при изменениях в цепочке — внутреннего объекта, коллекции. Результат этого понятен: изменения в объектах, которые уже нашей цепочки не принадлежат, будут инициировать уведомления об изменении цепочки, что неверно.
2. В коллекции обрабатывается только добавление элемента. А как же остальные 4 действия — Remove, Move, Replace и Reset?
Если будете фиксить эти баги, учтите, пожалуйста, следующие моменты (в частности, потому, что интересно сколько еще времени займет эта работа) по п.2:
1. Проблема обработки Remove, Move, Replace и Reset не только проблема утечек. В некоторых случаях дело и в корректности вычислений тоже. Например, в случае Replace не совершается переподписка на новый элемент, а, значит, при изменениях его свойств не будет рейзится событие об изменении зависимого свойства.
2. Не забудьте реализовать отписку от уже ненужных элементов коллекции в случае Reset (когда OldValues = null).
Мешает серия багов:
1. Нет отписок при изменениях в цепочке — внутреннего объекта, коллекции. Результат этого понятен: изменения в объектах, которые уже нашей цепочки не принадлежат, будут инициировать уведомления об изменении цепочки, что неверно.
2. В коллекции обрабатывается только добавление элемента. А как же остальные 4 действия — Remove, Move, Replace и Reset?
Если будете фиксить эти баги, учтите, пожалуйста, следующие моменты (в частности, потому, что интересно сколько еще времени займет эта работа) по п.2:
1. Проблема обработки Remove, Move, Replace и Reset не только проблема утечек. В некоторых случаях дело и в корректности вычислений тоже. Например, в случае Replace не совершается переподписка на новый элемент, а, значит, при изменениях его свойств не будет рейзится событие об изменении зависимого свойства.
2. Не забудьте реализовать отписку от уже ненужных элементов коллекции в случае Reset (когда OldValues = null).
Что касается слабых ссылок, то, это, по моему, вообще из пушки по воробьям. Чтобы использовать слабые ссылки, нужна еще реализация «слабых подписок», где этот код возьмем? Тоже сами напишем? Или библиотекой сторонней воспользуемся? :-) Если сами, то чего уж там, давайте и этот код в студию :-).
Что касается слабых ссылок, то, это, по моему, вообще из пушки по воробьям.
Вы знаете более простой и надёжный способ? В чём он заключается?
Ну лично я предпочитаю своевременную отписку.
С Rx можно обрезать пуповину еще и со стороны публикатора.
С Rx можно обрезать пуповину еще и со стороны публикатора.
предпочитаю своевременную отпискуТ.е. вы предлагаете добавить метод Dispose, в котором будет происходить отписка, и возложить на плечи программиста\архитектуры дополнительную ответственность?
Нет никакой дополнительной ответственности, отвечать за утечки приходится всегда и везде.
В случае событий надо или гарантировать отписку, или доказать одинаковое время жизни публикатора и подписчика, или доказать слабость подписки. В вашем коде я пока ничего из этого не вижу.
В случае событий надо или гарантировать отписку, или доказать одинаковое время жизни публикатора и подписчика, или доказать слабость подписки. В вашем коде я пока ничего из этого не вижу.
Вы во всех ветках будете писать, что не видите в коде слабых событий? Ответил вам в другой ветке.
Результат этого понятен: изменения в объектах, которые уже нашей цепочки не принадлежат, будут инициировать уведомления об изменении цепочки, что неверно.
Можно сделать отписку при удалении элемента из коллекции, а можно и не делать. Сам по себе случай, когда элемент изымается из отображения, и после этого с ним производятся какие-то действия, довольно редок. Обычно, если элемент перестаёт отображаться, значит он пользователя больше не интересует, и никаких действий с ним не планируется. Но что будет, если такой случай всё же произойдёт? В View перерисуется элемент, зависящий от вычислимого свойства в ViewModel, который мог не перерисовываться. Опять таки, а много у вас вычислимых свойств в проекте, и насколько они сложные? Не вижу необходимости делать преждевременную оптимизацию, усложняя код, чтобы в каких-то очень экзотических ситуациях он отрабатывал на несколько миллисекунд быстрее.
Хотя если у вас в проекте такие случаи встречаются, то можете и задуматься об оптимизации. Хотя раз в данном случае оптимизация будет заключаться в каких-то дополнительных действиях, то в одних местах код будет работать быстрее, а в других — медленнее. Тут лучше на конкретном проекте смотреть, сколько микросекунд мы выиграем, сколько потеряем, и стоит ли усложнение кода выигранного быстродействия.
Тут лучше на конкретном проекте смотреть, сколько микросекунд мы выиграем, сколько потеряем, и стоит ли усложнение кода выигранного быстродействия.
Проблема не в микросекундах, а утечке ресурсов: подписанный элемент и все его зависимости не могут быть утилизированы сборщиком мусора.
Я же лично вам недавно говорил про утечки памяти и слабые ссылки.
Пока никаких слабых ссылок в вашем коде не наблюдается. Или вы имеете в виду, что ваш код требует реализацию слабой подписки на стороне публикатора?
Описание слабых ссылок
Описание слабых событий
Нет, слабых событий на данный момент в коде нет. Почему нет, я вам говорил ранее — чтобы не перегружать пример кода:
Подумаю, может быть, добавлю в статью код примера слабых событий. Хотя не вижу особого смысла. В сети наверняка есть примеры, как это делается, я тут ничего нового не скажу.
Описание слабых событий
Нет, слабых событий на данный момент в коде нет. Почему нет, я вам говорил ранее — чтобы не перегружать пример кода:
Пример кода отражает основной смысл, который в него заложен (имхо, такими и должны быть примеры — краткими и конкретными). Чтобы память не текла, используйте слабые ссылки. Это, на мой взгляд, best practise при практически любом использовании событий.
Подумаю, может быть, добавлю в статью код примера слабых событий. Хотя не вижу особого смысла. В сети наверняка есть примеры, как это делается, я тут ничего нового не скажу.
Есть еще один недостаток у отсутствия отписки. Вы неявно принимаете исключение элемента из коллекции за его уничтожение, а это по факту может быть совсем не так. Элемент может быть добавлен в другую коллекцию, возвращен в пул и задействован повторно, использован самостоятельно и т.д. И в этом случае слабые ссылки не помогут никак.
И в этом случае слабые ссылки не помогут никак.
Не помогут в чём? Утечки памяти возникнут? Если объект не уничтожен, сборщиком мусора его собирать не надо.
От утечек слабые ссылки спасут, но ничего не сделают с паразитными пересчетами, которые дадут сложность N*M (N — число элементов коллекции, M — число бывших элементов коллекции) буквально на пустом месте.
По поводу оптимизации я уже высказывался в этом комментарии.
Оптимизация здесь вообще ни при чем.
Например, использование быстрой сортировки вместо пузырька — оптимизация.
А вот написание кода, который работает изначально работает медленнее пузырька — просто ошибка.
Нет никакого смысла допускать массовые заведомо паразитные пересчеты даже в прототипе.
Например, использование быстрой сортировки вместо пузырька — оптимизация.
А вот написание кода, который работает изначально работает медленнее пузырька — просто ошибка.
Нет никакого смысла допускать массовые заведомо паразитные пересчеты даже в прототипе.
Оптимизация — это модификация системы для улучшения её эффективности.
использование быстрой сортировки вместо пузырька — оптимизацияКстати, быстрая сортировка не всегда работает быстрее пузырьковой. Аккуратнее в словах, на портале могут быть неофиты.
В коллекции обрабатывается только добавление элемента. А как же остальные 4 действия — Remove, Move, Replace и Reset?Неправда, посмотрите код ещё раз.
Можно указать конкретное место, где обрабатывается Remove и Reset?
Подчеркнул это место.
collection.CollectionChanged += (sender, args) =>
{
RaisePropertyChanged(propertyName);
if (args.Action == NotifyCollectionChangedAction.Add || args.Action == NotifyCollectionChangedAction.Replace)
{
foreach (var addedItem in args.NewItems)
{
RegisterElementPropertyDependencies(propertyName, addedItem, destinationPropertyNames, actionOnChanged);
}
}
};
collection.CollectionChanged += (sender, args) =>
{
RaisePropertyChanged(propertyName);
if (args.Action == NotifyCollectionChangedAction.Add || args.Action == NotifyCollectionChangedAction.Replace)
{
foreach (var addedItem in args.NewItems)
{
RegisterElementPropertyDependencies(propertyName, addedItem, destinationPropertyNames, actionOnChanged);
}
}
};
То, что вы не делаете отписки при Remove, Replace и Reset — это утечки.
А вот то, что вы при Reset не подписываетесь на новое содержимое коллекции — это еще и проблемы непосредственно с пересчетом.
Конечно, типовая ObservableCollection делает Reset только при Clear, только любой шаг вправо или влево (пример: www.interact-sw.co.uk/iangblog/2013/02/22/batch-inotifycollectionchanged) сделает ваш код неработоспособным.
А вот то, что вы при Reset не подписываетесь на новое содержимое коллекции — это еще и проблемы непосредственно с пересчетом.
Конечно, типовая ObservableCollection делает Reset только при Clear, только любой шаг вправо или влево (пример: www.interact-sw.co.uk/iangblog/2013/02/22/batch-inotifycollectionchanged) сделает ваш код неработоспособным.
это утечки
Если честно, уже не смешно. Я потерял счёт, сколько раз я вам говорил про утечки памяти и слабые события. Ваш троллинг слишком толст.
Конечно, типовая ObservableCollection делает Reset только при Clear, только любой шаг вправо или влево сделает ваш код неработоспособным.Ага, а давайте рассмотрим ещё пример: типовой List<> добавляет во время Add() ровно один элемент, а если сделать в наследнике чтобы Add добавляло сам элемент и его копию, то какой-нибудь код, рассчитывающий что после Add() Count увеличивается ровно на единицу, станет неработоспособным. Можно сделать почти любой код неработоспособным, пренебрегая элементарными правилами наследования. Почитайте про принцип Лисков.
Можно сделать почти любой код неработоспособным, пренебрегая элементарными правилами наследования. Почитайте про принцип Лисков.
Видите ли, публичный контракт ObservableCollection не гарантирует, что Reset вызывается только при Clear
Если вы делаете на эту ставку — это нарушение инкапсуляции.
Reset означает очистку только начиная с .NET 4.5, что в свою очередь ломает обратную совместимость.
Не знал, спасибо. Ну тогда придётся заменить
if (args.Action == NotifyCollectionChangedAction.Add || args.Action == NotifyCollectionChangedAction.Replace)
на
if (args.NewItems != null && args.NewItems.Any()).
Сделал из этого некоторые выводы. Благодарствую, удалось извлечь пользу из диалога с вами :)
if (args.Action == NotifyCollectionChangedAction.Add || args.Action == NotifyCollectionChangedAction.Replace)
на
if (args.NewItems != null && args.NewItems.Any()).
Сделал из этого некоторые выводы. Благодарствую, удалось извлечь пользу из диалога с вами :)
Конечно, типовая ObservableCollection делает Reset только при Clear, только любой шаг вправо или влево сделает ваш код неработоспособным.
Написал статью на тему, почему нужно по-возможности избегать таких шагов влево.
RaisePropertyChanged — это не обработка.
В частности:
В частности:
Например, в случае Replace не совершается переподписка на новый элемент, а, значит, при изменениях его свойств не будет рейзится событие об изменении зависимого свойства.
Подчеркнул нужное место…
collection.CollectionChanged += (sender, args) =>
{
RaisePropertyChanged(propertyName);
if (args.Action == NotifyCollectionChangedAction.Add || args.Action == NotifyCollectionChangedAction.Replace)
{
foreach (var addedItem in args.NewItems)
{
RegisterElementPropertyDependencies(propertyName, addedItem, destinationPropertyNames, actionOnChanged);
}
}
};
collection.CollectionChanged += (sender, args) =>
{
RaisePropertyChanged(propertyName);
if (args.Action == NotifyCollectionChangedAction.Add || args.Action == NotifyCollectionChangedAction.Replace)
{
foreach (var addedItem in args.NewItems)
{
RegisterElementPropertyDependencies(propertyName, addedItem, destinationPropertyNames, actionOnChanged);
}
}
};
Хмм можно разбирать вычисления из лямбд и по ним генерировать подписку.
interface IDisposableSupplier<T> : IDisposable {
T Supply();
}
class ViewModel : BaseViewModel {
public int A {get; set;}
public int B {get; set;}
private readonly IDisposableSupplier<int> cSupplier;
public int C {get{ return cSupplier.Supply(); }}
public ViewModel(){
cSupplier = this.CreateSubcription(() => A + B);
}
}
static class ProppertyChangedHelper {
public static<T> IDisposableSupplier<T> CreateSubcription(this BaseViewModel vm, Expression<Func<T>> callable) {
//AST parsing and subscriptions here.
}
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё один способ реализации binding-а вычислимых свойств в WPF