Перед прочтением необходимо почитать о шаблоне EventAggregator. EventAggregator обеспечивает взаимодействие компонент и сервисов составного приложения, через слабую связанность.

EventAggregator можно найти во многих WPF-каркасах: Mvvm Light -класс Messenger, Catel – класс MessageMediator. Я познакомился с EventAggregator вместе с WPF каркасом Prism. Использование EventAggregator оказалось простым и гибким. Компоненты системы становятся независимыми друг от друга – изменяя один компонент, я не боюсь сломать другой.

При рассмотрении отдельных компонент все так и есть, но поднявшись на уровень работы компонентов в системе, можно разглядеть серьёзные проблемы:


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

Оптимизации пользовательского интерфейса посвящается.

Пользовательский интерфейс должен быть быстрым, очень быстрым, невероятно быстрым.

В попытках сэкономить наносекунды зачастую упускаются места где можно экономить секунды. Забавно, однажды на мое возмущение о двух секундной отрисовке небольшого списка, я получил ответ «Дабпиэф ничего не поделаешь», серьезно? Изучая всевозможные варианты реализации INotifyPropertyChanged habrahabr.ru/post/281294 возникает вопрос об идеальном балансе производительности пользовательского интерфейса и разработчика, который занимается этим интерфейсом. Захотелось понять как повлияет на работу интерфейса выбор конкретной реализации.

Поддавшись общей истерии на хабре,

(а именно «Предупреждаю Недвижимость Изменился» переводит Гуглекс всеми любимый «I Notify Property Changed») по поводу уведомлений об изменении. Я решил посмотреть на сколько далеко продвинулось человечество в изобретении велосипедов.

Абстракции? Кому нужны абстракции?
EF наикрутейшая ORM от MS. habrahabr.ru/post/157267 это действительно круто. Разработать такую систему очень затратно по всем направлениям. CodeFirs вещь, знания проектирования БД, да какой там! Не нужны сами знания SQL – и это круто. Но так ли все радужно?
Julie Lerman может много рассказать msdn.microsoft.com/en-us/magazine/ff898427.aspx

Ничего не напоминает?

Data Access Layer – одна из наиболее больных тем.
Написание хорошего слоя доступа к данным – это не тривиальная задача. Примеров реализации невероятно много, но адекватных среди них единицы.
Можно ли считать реализацию шаблона Repository — DAL?
Вот что предлагают MS msdn.microsoft.com/en-us/library/ff649690.aspx

А вот и местные работы habrahabr.ru/post/52173
Варианты довольно нормальные.
Но когда я вижу

«Репозиторий – это фасад для доступа к базе данных.»

…

Всегда ли нужно использовать то, что предлагают?

Разобравшись с посетителем и слушателем, пришло время попробовать «Велосипед». Изучая способы построения внешних DSL я столкнулся с проблемой получения практики. Не буду далеко ходить книга Фаулера про то, как построить язык мечты «DSL», к сожалению, оказалась совсем не обезболивающим, а скорее на оборот тропой в кустах крапивы.

Глава 12 Symbol Table

Место для хранения во время синтаксического анализа всех
идентифицируемых объектов для разрешения ссылок.

Понятно? Конечно понятно, к описанию претензий нет.

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

Посещать или слушать? Дело вкуса – не более. Или нет?
Предыстория.

Разобрав исходный текст, на выходе образовалось дерево:



Само по себе дерево не имеет ни какого смысла, оно “Деревянное”, смыслом и какой либо ценностью обладает результат анализа (обхода) этого дерева. Для тех кто не готов напрягаться и писать самописные сани по спуску с дерева (например, меня) в antlr4 добавлена возможность получить анализатор почти бесплатно.

1. Visitor

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

2. Listener

Новшество, появившееся в четвертой версии. Поведение этого класса уже далеко не классическое (Observer или Publish/Subscribe). В классическом исполнении наблюдается менеджер который оповещает подписчиков о наступлении событий. Поведения рассматриваемого слушателя больше похоже на работу инспектора. Инспектор перед проверкой узла делает заметку “Я проверяю Х узел”, далее идет обход потомков узла, после обхода, которых можно сделать “Заключение о результатах обхода узла Х”.

1. Пролог

Несколько лет назад разработал внутренний язык для расчета отчетов, который используется в нашей фирме. Язык получился странным, в нем нет ни циклов, ни стандартных условных операторов (if), динамическая типизация, но со своими функциями он справлялся. Идея языка была реализовать простой expression evaluator. Со временем требований становилось все больше, как следствие язык стал расширяться, пришлось разработать простой сценарий добавления новых функций.

На сегодняшний момент внутренний язык предназначенный для расчета отчетов превратился в монстра, не поворотливого мутанта. Это творение породили на свет отсутствие документации, простота расширения и лень разработчиков (проще написать, что то новое, чем разобраться в том что есть и найти нужное). Язык стал уметь много, слишком много того, для чего он не предназначался (разве что блинчики его печь не научили, а жаль).