Как стать автором
Обновить
55
0

Пользователь

Отправить сообщение
=) Эта совсем старая, в ней ещё только зарождались некоторые идеи. Окончательную форму они приобрели уже в Aero Framework…
Да, сравнительно недавно была обзорная и довольно насыщенная статья об Aero Framework, где этот вопрос поднимался. Но из-за насыщенности не всем хватило терпения её изучить, поэтому было решено разобрать некоторые аспекты детальнее и в более доступном виде.
Если у вас в приложении такая запись встречается несколько раз, то, вероятно, разницы вы не ощутите, но когда нужно локализовывать сотни элементов, то банальный выигрыш во времени набора текста прочувсвуете хорошо.

Кроме того, применение расширений привязки не ограничивается одной лишь локализацией, а позволяет делать гораздо более интересные вещи… Чтобы много не говорить, рекомендую просто ознакомиться с примером.
Кстати, если так, то, насколько понимаю, конструкция

PropertyChanged?.Invoke(this, new PropertyChangedEventArgs("Name")); 

разворачивается в

PropertyChanged == null ? null : PropertyChanged.Invoke(this, new PropertyChangedEventArgs("Name")); 

?
То есть такой код не является потокобозопасным. Или события разворачиваются по-другому?

Ведь a?.b должно быть аналогично
var tmp = a;
tmp == null ? null : tmp .b

чтобы код остался потокобезопасным относительно переменной a…

P.S. Вспомнился забавный кусочек в одном из проектов (скорее всего, описка)
var handler = PropertyChanged;
if (handler != null) PropertyChanged(o, e);
Возможно, многие знают, но что касается событий, то давно существует изящный способ избавления от проверки на null:

public event PropertyChangedEventHandler PropertyChanged = (sender, args) => { };

Просто, лаконично, потокобезопасно и удобно.
Дополнил статью и поместил теоретическую часть в начало. Теперь, надеюсь, будут более понятны идеи самого паттерна. Если всё же останутся неясности, то, пожалуйста, задавайте вопросы и пишите замечания. Вся эта информация весьма свежая, поэтому есть трудности с её доступным изложением.
Убрал спорную фразу.

В двух словах, паттерн заключается в следующем:

• с любым представлением может быть связан один или несколько контекстных объектов (и наоборот, то есть отношение многие ко многим). Любые взаимодействия представлений и контекстных объектов происходят посредством медиаторов трёх видов: привязки свойст, команд и инжекции контекста.

• классические вью-модели и модели — это сущности, выполняющие различные функции, но обладающие общим основанием (контекстная фундаментальность). Другими словами, это два вида тех самых контекстных объектов.

Также, как дополнение, к паттерну относится ряд принципов и рекомендаций, описанных в статье.
Возможно, ещё что-то требует пояснения или дополнения, не стесняйтесь спрашивать…
Кроме того, говоря о сложности и пороге вхождения, можно сравнить разные библиотеки по количеству базовых классов и интерфейсов. Это, конечно, не саймый объективный показатель, но всё же получить представление о работе 10-15 классов обычно проще, чем 20-30.
На самом деле, порог вхождения не такой высокий, как может показаться изначально. Достаточно лишь взглянуть на пример проекта, который идёт вместе с библиотекой, ведь даже начинающий разработчик при желании интуитивно разберётся в нём.

При достаточной своей простоте фреймворк позволяет решать очень широкий спектр задач, возникающих при разработке. Причём, красиво и лаконично.
Спасибо за хорошую статью и ваш труд!

Вместо того, чтобы копировать увиденное, мы хотим найти принцип и повторить его своими силами (может быть, сделав это проще/эффективней).


На мой взгляд, вы слишком заостряете внимание на визуальной составляющей и трёхмерных координатах. В реальности же мозг создаёт приближённую объектную трёхмерную модель. Попробуйте закрыть глаза, и ведь всё равно некоторое время вы будете ощущать окружающее пространство и предметы вокруг себя. Если же вы вы чего-то касаетесь или слышите, то так же представлете форму и положение объекта.

Банально, без зеркала нельзя рассмотреть свои зубы, но в мозгу есть их трёхмерная модель, созданная с помощью осязания. Мы знаем особенности и положение каждого зуба. Примечательно и то, что эта модель даже слегка может отличаться от визуальной (бывает, в зеркале зубы кажуться не совсем такими, какими их чувствует язык).

Хотя бинокулярный эффект и эффект перемещения играют некоторую роль, на мой взгляд, это не основные факторы, ведь по двумерной фотографии мозг запросто восстанавливает положения объектов в пространстве.

Что касается зрения, сначала анализируются примитивы: линии, области света и тени, цвета, после чего распознаются фигуры и контуры. Затем это всё кластеризуется в более сложные образы знакомых нам предметов. На основании привычных нам размеров и теней выводится их относительное местоположение друг к другу, а после этого приближённая трёхмерная модель. Ведь мы можем построить её даже по детскому рисунку из статьи!

Более того, мозг способен строить объёмные модели вообще по чему угодно, только дайте побольше деталей для образа, воображение всё доделает. Взгляните на тесты Роршаха. Как можно научить компьютер что-то распознавать в них, если использовать только трёхмерное моделирование точками?

Всё же, на мой взгляд, для настоящего распознавания объёмных образов с фотографий и картинок следует направлять исследования в области кластеризацией объектов и симуляции искусственного интеллекта (возможно, будет интересно ознакомиться со второй частью следующей статьи).

Буду рад услышать и другие рассуждения по этому поводу!
Круто-круто! Прослушал вашу лекцию, и приятно удивлён тем, что существуют единомышленники в подобном направлении. Согласен, для того чтобы понять и прочувствовать эти идеи, нужно пересмотреть своё мышление и отойти от классического реляционного подхода.

Сейчас мой основной род деятельности — программирование, поэтому, в первую очередь, меня интересует практическая применимость концепции и совместимость с ORM-фремворками для разработки (например, с тем же Entity Framework). И, как показали мои эксперименты, от скрещивания реляционного и ассоциативного (безатрибутного) подхода вполне можно извлечь пользу.

Вы также упомянули вскользь, про симуляцию искусственного интелекта на основе безатрибутной модели. Действительно, реализовать алгоритмы мышления в ней достаточно просто.

А вообще давно вынашиваю в себе мысли попробовать создать обучаемую программу на основе частотного и вероятностного анализа слов из книг, например, художественных. Интересно самому, к чему это приведёт и отыщутся ли какие-то закономерности. Только пока до практической части дело ещё не дошло, тут нужно хорошо исследовать область, чтобы к чему-то прийти.

Спасибо!
Не знаю, замечали ли вы в жизни любопытную закономерность…

Начинаешь изучать одну область знания, другую, третью — совсем разные, такие непохожие друг на друга (от танцев, рисования до науки и программирования). Кажется, что между ними общего?

Но приходит день, когда начинаешь обращать внимание на некоторые параллели, аналогии. Дальше — глубже, глубже — больше, и находишь столько общего, что потом удивляешься, как этого раньше не замечал.

Это у чему я веду, ведь так и с разными людьми и мировоззрениями. Когда, действительно, углубляешься во что-то с головой, начинаешь видеть еденую основу во всём и понимать различия.
«История эта совершенно истинна, поскольку я ее выдумал от начала и до конца.» Борис Виан

Вы правы, представления о мире очень субъективны, однако процессы обучения и формализации как раз-таки направлены на универсализацию знаний и приближение их к объективной реальности (той реальности, которую способны воспринять и принять индивиды, находясь на определённом этапе интеллектуального развития). Конечно, не возможно создать копию разума другого человека, но те людские познания (сущности и ассоциации в БД), которые согласуются с точными физическими экспериментами претендуют на объективность.

Что касается примера, то обладая алфавитом и минимально необходимым словарным запасом доктора могут «договориться» и ввести новое понятие в язык.
Были подозрения, что подобные идеи в том или ином виде приходили уже кому-то в голову. Как говорят, нет ничего нового под солнцем. Но в университете такому не учили и на практике подобное тоже не встречалось.

А начали зарождаться эти мысли во время работы над дипломным проектом. Спустя несколько лет всё не раз передумалось, ещё более обобщилось и улеглось, поэтому решил оформить в статью.

На мой взгляд, ассоциативно-реляционный подход вполне применим на практике и позволяет существенно снизить количество таблиц в базах данных, упростить запросы и повысить производительность при грамотном использовании. По крайней мере, в учебном проекте это получилось сделать.

Чистый ассоциативный подход перспективен для моделирования мыслительных процессов.

Благодарю за ссылки.

Начал знакомиться со статьями maxstroy, действительно, тематика схожа…
Существует несколько программ подобного рода, некоторые дополнительно могут выполнять сжатие и обфускацию. Но их главная проблема в том, что если приложение вдруг перестанет запускаться, после выполненных процедур, то выяснить причину будет очень сложно. Касательно Poet, изначально были попытки воспользоваться готовыми утилитами, но полностью работоспособного исполняемого файла получить так и не удалось. Только применив подход, описанный в статье, с помощью отладчика, выявились места из-за которых возникали проблемы. В основном это были неправильные ссылки на ресурсы, содержащиеся в разных сборках.
Понял Вас. Во-первых, можно воочию увидеть реализацию всех функций, которые указаны в описании к приложению на сайте. Также интересны будут следующие моменты:
— локализация приложения и «горячая» смена языка
— вышеупомянутая компоновка сборок в исполняемый файл
— проверка орфографии веб-сервисами
— контроль количества открытых экземпляров программы и открытие файлов в них
— ассоциация приложения с файлами
— работа с системным треем
— работа с реестром
— реализация поиска по файлам
— рифмоплёт
— куча других более мелких «фишечек» и качественный код

— и, конечно, применение на практике свободной библиотеки Foundation Framework, зарождение которой началось с этого редактора. Пока у неё нет мануала, но кое-что можно почерпнуть из старых статей (ссылка1 и ссылка2), хотя сейчас библиотека приобрела ещё более совершенный вид и стала мультиплатформенной (Win Desktop, Win Phone, Win Store, отчасти Xamarin).
Спасибо! Исправил ссылку на Foundation Framework. Видимо, произошёл какой-то сбой с OneDrive, когда переименовывал файл.

Приобретать исходные коды вовсе не обязательно, но, возможно, они помогут сохранить кому-то много времени и сил в реальной работе. У меня в мыслях написать ещё несколько статей о нестандартных задачах, которые довелось решить при разработке этого редактора и других программ.
Есть опыт работы с обоими библиотеками. XNA-фреймворк установлен по умолчанию со студией, а NAudio нужно доплнительно загружать, хотя это не проблема. XNA родной и мультиплатформенный (Win Desktop, Win RT, Win Phone), а также проще в освоении и использовании, по крайней мере, что касается звука. NAudio не мультиплатформенный и более сложный, но охватывает круг аудиозадач более широкий нежели первый собрат.

Думаю, для простого захвата сигнала с микрофона и его анализа, всё-таки легче использовать первый вариант.
Наткнулся на интервью с создателем программы Melodyne, о которой упоминалось выше в комментариях.
Видео получасовое и на английском, но понять кое-что можно, даже если смотреть перематывая.
Возможно, кто-то отыщет для себя новое…

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность