Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

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

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

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

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

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

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

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

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

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

Аннотация

Это третья статья, просвещенная порождающим шаблонам проектирования и связанным с ними вопросами. Здесь мы рассмотрим излюбленные приемы при создании объектов: фабрики, заводы, абстрактные фабрики, строители, прототипы, мультитоны, отложенные инициализации, а также немного коснемся pimpl идиомы или шаблона “мост”. Использование синглтонов было подробно рассмотрено в первой [1] и второй [2] статьях, однако, как вы увидите в дальнейшем, синглтоны часто используются совместно с другими шаблонами проектирования.

Эта статья является продолжением моей первой статьи “Использование паттерна синглтон” [0]. Сначала я хотел все, что связано со временем жизни, изложить в этой статье, но объем материала оказался велик, поэтому решил разбить ее на несколько частей. Это — продолжение целого цикла статей про использование различных шаблонов и методик. Данная статья посвящена времени жизни и развитию использования синглтона. Перед прочтением второй статьи настоятельно рекомендуется ознакомиться с моей первой статьей [0].

В предыдущей статье была использована следующая реализация для синглтона:

template<typename T>
T& single()
{
    static T t;
    return t;
}

Функция single возвращала нам заветный синглтон. Однако данный подход имеет изъян: в этом случае мы не контролируем время жизни объекта и он может удалиться в тот момент, когда мы хотим этим объектом воспользоваться. Поэтому следует использовать другой механизм создания объекта, используя оператор new.

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

Кристофер Александер в соавторстве с пятью другими специалистами по архитектуре действительно написал книгу об архитектурных шаблонах, в которой он действительно рассмотрел свыше двухсот оных. Краткое и широко известное название это книги — «A Pattern Language». Однако же достаточно взглянуть на обложку книги, чтобы увидеть ее полное название: «A Pattern Language: Towns, Buildings, Construction». Такие длинные названия книг и широкая распространенность только названий кратких — не редкость; например, все знают «Происхождение видов» сэра Чарльза Дарвина, но редко кто сможет вспомнить ее полное наименование: «Происхождение видов путем естественного отбора, или Сохранение благоприятных рас в борьбе за жизнь».

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

О паттерне проектирования Singleton банды четырёх уже сказано много всяких гадостей. О разных нарушаемых Singleton'ом принципах можно почитать, например, здесь. И, похоже, мне есть что добавить.

Первопричина всех бед с GoF Singleton'ом, в том, что для подавляющего большинства классов «Singleton'овость» – это деталь их реализации. Просто эти классы так удобнее реализовать, если вся система будет работать с одним единственным объектом каждого. GoF советует эту деталь реализации для всех Singleton'ов выносить наружу, в виде метода getInstance().

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

Паттерн Decorator предназначен для динамического подключения дополнительного поведения к объекту, расширяющего его функциональность.

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