Всем привет!

Сегодня я хочу вам показать результат взаимодействия двух широкоро распространенных паттернов проектирования Strategy и Composite, в результате чего у нас получится так называемый «Компоновщик стратегий».

Сразу хочу сказать, что в статье я не буду описывать как надо работать с Data Provider-ом. Это можно найти и в документации и в многочисленных статьях в интернете.
Здесь я расскажу про шаблоны проектирования Domain Model, Singleton, Repository, про подход Behavior Driven Development (BDD) и как я их использовал в своей программе.

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

Например, в моей программе предметная область состоит из данных расписания, заданного в виде нескольких будильников, для будильника можно задать дни недели и время, а также признак «будильник включен». Так же есть несколько алгоритмов, например получить будильник, который сработает следующим и дату и время его срабатывания. Поскольку будильник может дремать, получается что у одного будильника есть несколько срабатываний с разными действиями: первое срабатывание, дремание, и последнее дремание, когда кнопка дремать уже не доступна. Поэтому есть еще алгоритм поучения ближайшего абсолютного времени и действия.
Так же есть алгоритмы для создания нового будильника и редактирования/удаления существующих.

То есть в моей предметной области есть данные в виде нескольких будильников и несколько алгоритмов, которые реализуют логику предметной области.

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

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

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

Такой подход называется Behavior Driven Development. Его достоинство в том, что я могу тестировать модель в терминах предметной области, то есть в модульных тестах я имитирую обычное поведение пользователя. Благодаря тому, что это реализовано через механизм модульных тестов, я перед каждым релизом могу эти тесты прогнать и быть уверенным, что моя программа программа нормально отрабатывает основные действия пользователя.

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

Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

После моей недавней статьи несколько человек поинтересовались в личке как сделать Dashboard. Dashboard является одним из основных UI паттернов для Android, подробней о которых Вы можете прочесть здесь. Поиск по хабру подсказал как можно реализовать QuickAction диалоги и ActionBar. В этой статье я расскажу как легко сделать свой Dashboard.

Каждый прогер наверняка использовал паттерн «Компоновщик», а большинство из нас также сталкивалось с необходимостью реализовать его в своем проекте. И часто так получается, что каждая его реализация налагает особые требования на определяемую бизнес-логику, при этом с точки зрения работы с иерархической структурой мы хотим иметь одинаково широкий набор возможностей: одних методов Add и Remove часто недостаточно, так почему бы не добавить Contains, Clear и с десяток других? А если еще нужны специальные методы обхода поддеревьев через итераторы? И вот такую функциональность хочется иметь для различных независимых иерархий, а также не обременять себя необходимостью определять реализацию таких методов в каждом из множества элементов Composite. Ну и листовые компоненты тоже не помешало бы упростить.

Чуть ниже я предложу свой вариант решения такой проблемы, применительно к возможностям C#.

Недавно я столкнулся с задачей, которая оказалось гораздо менее тривиальной, чем показалась на первый взгляд. Пусть есть некоторый класс(в моём примере immutable), для которого есть builder. Необходимо иметь возможность наследоваться от этого класса, предоставляя builder, унаследованный от builder-a своего предка. Под катом я покажу ход своих размышлений, неудачные варианты и окончательное решение задачи.

Исключения в C++ являются одним из самых серьезных механизмов языка. Предоставляя достаточно мощные возможности для анализа и обработки ошибок. Но работа с исключениями не всегда бывает такой уж удобной.

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

Добрейшего.

В последнее время занялся чтением и рецензированием книг по любимой тематике — SCM, куда в первую очередь входят контроль версий, отслеживание изменений, отстройка и выпуск релизов и несколько других не менее важных тем. На этот раз под раздачу попала ещё одна книжка из числа тех, что выбрал себе для детального ознакомления. Называется Software Configuration Management Patterns: Effective Teamwork, Practical Integration, авторы — Стёпа Берчук (Stephen P. Berczuk) и Брэд Эпплтон (Brad Appleton). На русский можно перевести как «Шаблоны управления конфигурацией ПО: Эффективная работа команды, практическая интеграция.»


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

Тема шаблонов в разработке софта прорабатывается уже достаточно давно. Причем, как выяснилось, начало своё она берет из архитектуры. Сергей Тепляков не так давно рассказал на страницах RSDN Magazine об истоках этого направления, почитайте (после этой заметки, конечно же).