1. Архитектурный шаблон проектирования для Java

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

Антипаттерны проектирования

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

Интерфейс для констант - используем Java интерфейс не по назначению; Вресенная сложность - добавляем ненужные сущности в иерархию классов.

Поведенческие паттерны проектирования

Наконец, третья группа - поведенческие шаблоны (behavioral). Они определяют эффективные способы взаимодействия различных объектов в системе.

Strategy - описываем набор взаимозаменяемых алгоритмов с единым интерфейсом; Iterator - обеспечиваем доступ к коллекциям объектов без раскрытия внутреннего устройства этих коллекций; Observer - создаем объект для отслеживания изменений в подсистеме и нотификации других подсистем; Memento - сохраняем внутреннее состояние объекта для последующего использования без нарушения инкапсуляции; Command - описываем объект, представляющий собой некоторое действие, которое можно выполнить в необходимый момент; Interpreter - определяем способ вычисления выражений некоторого языка; Mediator - создаем объект, которые регулирует взаимодействие между набором подсистем; State - позволяем объекту менять свое поведение при изменении его внутреннего состояния; Template method - описываем алгоритм, возлагая реализацию некоторых частей алгоритма на подклассы; Visitor - отделяем алгоритм от структуры, с которыми алгоритм работает; Chain of responsibility - пропускаем некоторый запрос через набор обработчиков событий, до тех пор пока запрос не будет обработан.

Структурные паттерны

Вторая группа - структурные паттерны (structural). Они описывают создание более сложных объектов, либо упрощают работу с другими объектами сисетмы.

Adapter - на основании некоторого класса создаем необходимый клиенту интерфейс; Facade - описываем унифицированный интерфейс для облегчения работы с набором подсистем; Composite - работаем с базовыми и составными объектами единым образом; Decorator - динамически добавляем новую функциональность некоторому объекту, сохраняя его интерфейс; Proxy - создаем объект, который перехватывает вызовы к другому объекту; Bridge - разделяем абстракцию от интерфейса, позволяя им меняться независимо; Flyweight - эффективно работаем с огромным количеством схожих объектов.

Паттерны создания объектов

Первая группа - это creational паттерны. Они в той или иной степени работают с механизмами создания объектов.

Singleton - обеспечиваем существование в системе ровно одного экземпляра некоторого класса; Factory Method - делегируем процесс создания объектов классам-наследникам; Prototype - клонируем объекты на основании некоторого базового объекта; Builder - отделяем процесс создания комплексного объекта от его представления; Abstract Factory - описываем сущность для создания целых семейств взаимосвязанных объектов.

Шаблон проектирования или паттерн (англ. design pattern) в разработке программного обеспечения — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

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

«Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные.

На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.

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

В сравнении с полностью самостоятельным проектированием, шаблоны обладают рядом преимуществ. Основная польза от использования шаблонов состоит в снижении сложности разработки за счёт готовых абстракций для решения целого класса проблем. Шаблон даёт решению своё имя, что облегчает коммуникацию между разработчиками, позволяя ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация деталей решений: модулей, элементов проекта, — снижается количество ошибок. Применение шаблонов концептуально сродни использованию готовых библиотек кода. Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова. Набор шаблонов помогает разработчику выбрать возможный, наиболее подходящий вариант проектирования.^[1]

Хотя легкое изменение кода под известный шаблон может упростить понимание кода, по мнению Стива Макконнелла, с применением шаблонов могут быть связаны две сложности. Во-первых, слепое следование некоторому выбранному шаблону может привести к усложнению программы. Во-вторых, у разработчика может возникнуть желание попробовать некоторый шаблон в деле без особых оснований.^[2]

Многие шаблоны проектирования в объектно-ориентированном проектировании можно рассматривать как идиоматическое воспроизведение элементов функциональных языков^[3]. Питер Норвиг утверждает, что 16 из 23 шаблонов, описанных в книге «Банды Четверых», в динамически-типизируемых языках реализуются существенно проще, чем в С++, либо оказываются незаметны^[4]. Пол Грэхэм считает саму идею шаблонов проектирования — антипаттерном, сигналом о том, что система не обладает достаточным уровнем абстракции, и необходима её тщательная переработка^[5]. Нетрудно видеть, что само определение шаблона как «готового решения, но не прямого обращения к библиотеке» по сути означает отказ от повторного использования в пользу дублирования. Это, очевидно, может быть неизбежным для сложных систем при использовании языков, не поддерживающих комбинаторы и полиморфизм типов, и это в принципе может быть исключено в языках, обладающих свойством гомоиконничности (хотя и не обязательно эффективно), так как любой шаблон может быть реализован в виде исполнимого кода^[6].

Паттерны проектирования в Java

2015-12-21 ООП и паттерны проектирования 

Уверен, каждый программист слышал словосочетание "паттерны проектирования" (или шаблоны). Если очень коротко - это описание проблем, которые встречаются при написании объектно-ориентированного кода, а так же примеры решения этих проблем.

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

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

Надеюсь, цикл моих статей поможет вам сохранить хладнокровие в вопросах использования паттернов и при этом расширить свои познания в ООП.

За основу возьмем каталог паттернов из книги GoF - Design Patterns. А дальше как пойдет :).

В каждой статье я попытаюсь:

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