[Вопросы для собеседования](README.md) # Шаблоны проектирования + [Что такое _«шаблон проектирования»_?](#Что-такое-шаблон-проектирования) + [Назовите основные характеристики шаблонов.](#Назовите-основные-характеристики-шаблонов) + [Типы шаблонов проектирования.](#Типы-шаблонов-проектирования) + [Приведите примеры основных шаблонов проектирования.](#Приведите-примеры-основных-шаблонов-проектирования) + [Приведите примеры порождающих шаблонов проектирования.](#Приведите-примеры-порождающих-шаблонов-проектирования) + [Приведите примеры структурных шаблонов проектирования.](#Приведите-примеры-структурных-шаблонов-проектирования) + [Приведите примеры поведенческих шаблонов проектирования.](#Приведите-примеры-поведенческих-шаблонов-проектирования) + [Что такое _«антипаттерн»_? Какие антипаттерны вы знаете?](#Что-такое-антипаттерн-Какие-антипаттерны-вы-знаете) + [Что такое _Dependency Injection_?](#Что-такое-dependency-injection) ## Что такое _«шаблон проектирования»_? __Шаблон (паттерн) проектирования (design pattern)__ — это проверенное и готовое к использованию решение. Это не класс и не библиотека, которую можно подключить к проекту, это нечто большее - он не зависит от языка программирования, не является законченным образцом, который может быть прямо преобразован в код и может быть реализован по разному в разных языках программирования. Плюсы использования шаблонов: + снижение сложности разработки за счёт готовых абстракций для решения целого класса проблем. + облегчение коммуникации между разработчиками, позволяя ссылаться на известные шаблоны. + унификация деталей решений: модулей и элементов проекта. + возможность отыскав удачное решение, пользоваться им снова и снова. + помощь в выборе выбрать наиболее подходящего варианта проектирования. Минусы: + слепое следование некоторому выбранному шаблону может привести к усложнению программы. + желание попробовать некоторый шаблон в деле без особых на то оснований. [к оглавлению](#Шаблоны-проектирования) ## Назовите основные характеристики шаблонов. + __Имя__ - все шаблоны имеют уникальное имя, служащее для их идентификации; + __Назначение__ назначение данного шаблона; + __Задача__ - задача, которую шаблон позволяет решить; + __Способ решения__ - способ, предлагаемый в шаблоне для решения задачи в том контексте, где этот шаблон был найден; + __Участники__ - сущности, принимающие участие в решении задачи; + __Следствия__ - последствия от использования шаблона как результат действий, выполняемых в шаблоне; + __Реализация__ - возможный вариант реализации шаблона. [к оглавлению](#Шаблоны-проектирования) ## Типы шаблонов проектирования. + Основные (Fundamental) - основные строительные блоки других шаблонов. Большинство других шаблонов использует эти шаблоны в той или иной форме. + Порождающие шаблоны (Creational) — шаблоны проектирования, которые абстрагируют процесс создание экземпляра. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять созданный объект, а шаблон, порождающий объекты, делегирует создание объектов другому объекту. + Структурные шаблоны (Structural) определяют различные сложные структуры, которые изменяют интерфейс уже существующих объектов или его реализацию, позволяя облегчить разработку и оптимизировать программу. + Поведенческие шаблоны (Behavioral) определяют взаимодействие между объектами, увеличивая таким образом его гибкость. [к оглавлению](#Шаблоны-проектирования) ## Приведите примеры основных шаблонов проектирования. + __Делегирование (Delegation pattern)__ - Сущность внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту. + __Функциональный дизайн (Functional design)__ - Гарантирует, что каждая сущность имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие. + __Неизменяемый интерфейс (Immutable interface)__ - Создание неизменяемого объекта. + __Интерфейс (Interface)__ - Общий метод структурирования сущностей облегчающий их понимание. + __Интерфейс-маркер (Marker interface)__ - В качестве атрибута (как пометки объектной сущности) применяется наличие или отсутствие реализации интерфейса-маркера. В современных языках программирования вместо этого применяются атрибуты или аннотации. + __Контейнер свойств (Property container)__ - Позволяет добавлять дополнительные свойства сущности в контейнер внутри себя, вместо расширения новыми свойствами. + __Канал событий (Event channel)__ - Создаёт централизованный канал для событий. Использует сущность-представитель для подписки и сущность-представитель для публикации события в канале. Представитель существует отдельно от реального издателя или подписчика. Подписчик может получать опубликованные события от более чем одной сущности, даже если он зарегистрирован только на одном канале. [к оглавлению](#Шаблоны-проектирования) ## Приведите примеры порождающих шаблонов проектирования. + __Абстрактная фабрика (Abstract factory)__ - (Фабрика фабрик) это порождающий паттерн проектирования, который позволяет создавать семейства связанных объектов, не привязываясь к конкретным классам создаваемых объектов. Пример: + __Строитель (Builder)__ - это порождающий паттерн проектирования, который позволяет создавать сложные объекты пошагово. Строитель даёт возможность использовать один и тот же код строительства для получения разных представлений объектов. Пример: StringBuilder + __Фабричный метод (Factory method)__ - это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов. + __Прототип (Prototype)__ - это порождающий паттерн проектирования, который позволяет копировать объекты, не вдаваясь в подробности их реализации. + __Одиночка (Singleton)__ - это порождающий паттерн проектирования, который гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. [к оглавлению](#Шаблоны-проектирования) ## Абстрактная фабрика Представьте, что вы пишете симулятор мебельного магазина. Ваш код содержит: 1) Семейство зависимых продуктов. Скажем, Кресло + Диван + Столик. 2) Несколько вариаций этого семейства. Например, продукты Кресло, Диван и Столик представлены в трёх разных стилях: Ар-деко, Викторианском и Модерне. Вам нужен такой способ создавать объекты продуктов, чтобы они сочетались с другими продуктами того же семейства. Это важно, так как клиенты расстраиваются, если получают несочетающуюся мебель. Кроме того, вы не хотите вносить изменения в существующий код при добавлении новых продуктов или семейcтв в программу. Поставщики часто обновляют свои каталоги, и вы бы не хотели менять уже написанный код каждый раз при получении новых моделей мебели. __Решение__ Для начала паттерн Абстрактная фабрика предлагает выделить общие интерфейсы для отдельных продуктов, составляющих семейства. Так, все вариации кресел получат общий интерфейс Кресло, все диваны реализуют интерфейс Диван и так далее. Далее вы создаёте абстрактную фабрику — общий интерфейс, который содержит методы создания всех продуктов семейства (например, создатьКресло, создатьДиван и создатьСтолик). Эти операции должны возвращать абстрактные типы продуктов, представленные интерфейсами, которые мы выделили ранее — Кресла, Диваны и Столики. Для каждой вариации семейства продуктов мы должны создать свою собственную фабрику, реализовав абстрактный интерфейс. Фабрики создают продукты одной вариации. Например, ФабрикаМодерн будет возвращать только КреслаМодерн,ДиваныМодерн и СтоликиМодерн. Клиентский код должен работать как с фабриками, так и с продуктами только через их общие интерфейсы. Это позволит подавать в ваши классы любой тип фабрики и производить любые продукты, ничего не ломая. ```java // Этот паттерн предполагает, что у вас есть несколько семейств // продуктов, находящихся в отдельных иерархиях классов // (Button/Checkbox). Продукты одного семейства должны иметь // общий интерфейс. interface Button is method paint() // Семейства продуктов имеют те же вариации (macOS/Windows). class WinButton implements Button is method paint() is // Отрисовать кнопку в стиле Windows. class MacButton implements Button is method paint() is // Отрисовать кнопку в стиле macOS. interface Checkbox is method paint() class WinCheckbox implements Checkbox is method paint() is // Отрисовать чекбокс в стиле Windows. class MacCheckbox implements Checkbox is method paint() is // Отрисовать чекбокс в стиле macOS. // Абстрактная фабрика знает обо всех абстрактных типах // продуктов. interface GUIFactory is method createButton():Button method createCheckbox():Checkbox // Каждая конкретная фабрика знает и создаёт только продукты // своей вариации. class WinFactory implements GUIFactory is method createButton():Button is return new WinButton() method createCheckbox():Checkbox is return new WinCheckbox() // Несмотря на то, что фабрики оперируют конкретными классами, // их методы возвращают абстрактные типы продуктов. Благодаря // этому фабрики можно взаимозаменять, не изменяя клиентский // код. class MacFactory implements GUIFactory is method createButton():Button is return new MacButton() method createCheckbox():Checkbox is return new MacCheckbox() // Для кода, использующего фабрику, не важно, с какой конкретно // фабрикой он работает. Все получатели продуктов работают с // ними через общие интерфейсы. class Application is private field factory: GUIFactory private field button: Button constructor Application(factory: GUIFactory) is this.factory = factory method createUI() this.button = factory.createButton() method paint() button.paint() // Приложение выбирает тип конкретной фабрики и создаёт её // динамически, исходя из конфигурации или окружения. class ApplicationConfigurator is method main() is config = readApplicationConfigFile() if (config.OS == "Windows") then factory = new WinFactory() else if (config.OS == "Mac") then factory = new MacFactory() else throw new Exception("Error! Unknown operating system.") Application app = new Application(factory) ``` __Применимость__ Когда бизнес-логика программы должна работать с разными видами связанных друг с другом продуктов, не завися от конкретных классов продуктов. Абстрактная фабрика скрывает от клиентского кода подробности того, как и какие конкретно объекты будут созданы. Но при этом клиентский код может работать со всеми типами создаваемых продуктов, поскольку их общий интерфейс был заранее определён. Когда в программе уже используется Фабричный метод, но очередные изменения предполагают введение новых типов продуктов. В хорошей программе каждый класс отвечает только за одну вещь. Если класс имеет слишком много фабричных методов, они способны затуманить его основную функцию. Поэтому имеет смысл вынести всю логику создания продуктов в отдельную иерархию классов, применив абстрактную фабрику. __Шаги реализации__ + Создайте таблицу соотношений типов продуктов к вариациям семейств продуктов. + Сведите все вариации продуктов к общим интерфейсам. + Определите интерфейс абстрактной фабрики. Он должен иметь фабричные методы для создания каждого из типов продуктов. + Создайте классы конкретных фабрик, реализовав интерфейс абстрактной фабрики. Этих классов должно быть столько же, сколько и вариаций семейств продуктов. + Измените код инициализации программы так, чтобы она создавала определённую фабрику и передавала её в клиентский код. + Замените в клиентском коде участки создания продуктов через конструктор вызовами соответствующих методов фабрики. __Преимущества и недостатки__ + Гарантирует сочетаемость создаваемых продуктов. + Избавляет клиентский код от привязки к конкретным классам продуктов. + Выделяет код производства продуктов в одно место, упрощая поддержку кода. + Упрощает добавление новых продуктов в программу. + Реализует принцип открытости/закрытости. + - Усложняет код программы из-за введения множества дополнительных классов. + - Требует наличия всех типов продуктов в каждой вариации. ## Строитель Builder Представьте сложный объект, требующий кропотливой пошаговой инициализации множества полей и вложенных объектов. Код инициализации таких объектов обычно спрятан внутри монструозного конструктора с десятком параметров. Либо ещё хуже — распылён по всему клиентскому коду. Например, давайте подумаем о том, как создать объект Дом. Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и положить крышу. Но что, если вы хотите дом побольше да посветлее, имеющий сад, бассейн и прочее добро? Самое простое решение — расширить класс Дом, создав подклассы для всех комбинаций параметров дома. Проблема такого подхода — это громадное количество классов, которые вам придётся создать. Каждый новый параметр, вроде цвета обоев или материала кровли, заставит вас создавать всё больше и больше классов для перечисления всех возможных вариантов. Чтобы не плодить подклассы, вы можете подойти к решению с другой стороны. Вы можете создать гигантский конструктор Дома, принимающий уйму параметров для контроля над создаваемым продуктом. Действительно, это избавит вас от подклассов, но приведёт к другой проблеме. Большая часть этих параметров будет простаивать, а вызовы конструктора будут выглядеть монструозно из-за длинного списка параметров. К примеру, далеко не каждый дом имеет бассейн, поэтому параметры, связанные с бассейнами, будут простаивать бесполезно в 99% случаев. __Решение__ Паттерн Строитель предлагает вынести конструирование объекта за пределы его собственного класса, поручив это дело отдельным объектам, называемым строителями. Паттерн предлагает разбить процесс конструирования объекта на отдельные шаги (например, построитьСтены, вставитьДвери и другие). Чтобы создать объект, вам нужно поочерёдно вызывать методы строителя. Причём не нужно запускать все шаги, а только те, что нужны для производства объекта определённой конфигурации. Вы можете пойти дальше и выделить вызовы методов строителя в отдельный класс, называемый _директором_. В этом случае директор будет задавать порядок шагов строительства, а строитель — выполнять их. ```java // Строитель может создавать различные продукты, используя один // и тот же процесс строительства. class Car is // Автомобили могут отличаться комплектацией: типом // двигателя, количеством сидений, могут иметь или не иметь // GPS и систему навигации и т. д. Кроме того, автомобили // могут быть городскими, спортивными или внедорожниками. class Manual is // Руководство пользователя для данной конфигурации // автомобиля. // Интерфейс строителя объявляет все возможные этапы и шаги // конфигурации продукта. interface Builder is method reset() method setSeats(...) method setEngine(...) method setTripComputer(...) method setGPS(...) // Все конкретные строители реализуют общий интерфейс по-своему. class CarBuilder implements Builder is private field car:Car method reset() // Поместить новый объект Car в поле "car". method setSeats(...) is // Установить указанное количество сидений. method setEngine(...) is // Установить поданный двигатель. method setTripComputer(...) is // Установить поданную систему навигации. method setGPS(...) is // Установить или снять GPS. method getResult():Car is // Вернуть текущий объект автомобиля. // В отличие от других порождающих паттернов, где продукты // должны быть частью одной иерархии классов или следовать // общему интерфейсу, строители могут создавать совершенно // разные продукты, которые не имеют общего предка. class CarManualBuilder implements Builder is private field manual:Manual method reset() // Поместить новый объект Manual в поле "manual". method setSeats(...) is // Описать, сколько мест в машине. method setEngine(...) is // Добавить в руководство описание двигателя. method setTripComputer(...) is // Добавить в руководство описание системы навигации. method setGPS(...) is // Добавить в инструкцию инструкцию GPS. method getResult():Manual is // Вернуть текущий объект руководства. // Директор знает, в какой последовательности нужно заставлять // работать строителя, чтобы получить ту или иную версию // продукта. Заметьте, что директор работает со строителем через // общий интерфейс, благодаря чему он не знает тип продукта, // который изготовляет строитель. class Director is method constructSportsCar(builder: Builder) is builder.reset() builder.setSeats(2) builder.setEngine(new SportEngine()) builder.setTripComputer(true) builder.setGPS(true) // Директор получает объект конкретного строителя от клиента // (приложения). Приложение само знает, какого строителя нужно // использовать, чтобы получить определённый продукт. class Application is method makeCar() is director = new Director() CarBuilder builder = new CarBuilder() director.constructSportsCar(builder) Car car = builder.getResult() CarManualBuilder builder = new CarManualBuilder() director.constructSportsCar(builder) // Готовый продукт возвращает строитель, так как // директор чаще всего не знает и не зависит от // конкретных классов строителей и продуктов. Manual manual = builder.getResult() ``` __Область применения__ Когда вы хотите избавиться от «телескопического конструктора». Допустим, у вас есть один конструктор с десятью опциональными параметрами. Его неудобно вызывать, поэтому вы создали ещё десять конструкторов с меньшим количеством параметров. Всё, что они делают — это переадресуют вызов к базовому конструктору, подавая какие-то значения по умолчанию в параметры, которые пропущены в них самих. Когда ваш код должен создавать разные представления какого-то объекта. Например, деревянные и железобетонные дома. Строитель можно применить, если создание нескольких представлений объекта состоит из одинаковых этапов, которые отличаются в деталях. Интерфейс строителей определит все возможные этапы конструирования. Каждому представлению будет соответствовать собственный класс-строитель. А порядок этапов строительства будет задавать класс-директор. Когда вам нужно собирать сложные составные объекты, например, деревья Компоновщика. Строитель конструирует объекты пошагово, а не за один проход. Более того, шаги строительства можно выполнять рекурсивно. А без этого не построить древовидную структуру, вроде Компоновщика. Заметьте, что Строитель не позволяет посторонним объектам иметь доступ к конструируемому объекту, пока тот не будет полностью готов. Это предохраняет клиентский код от получения незаконченных «битых» объектов. __Шаги реализации__ + Убедитесь в том, что создание разных представлений объекта можно свести к общим шагам. + Опишите эти шаги в общем интерфейсе строителей. + Для каждого из представлений объекта-продукта создайте по одному классу-строителю и реализуйте их методы строительства. + Не забудьте про метод получения результата. Обычно конкретные строители определяют собственные методы получения результата строительства. Вы не можете описать эти методы в интерфейсе строителей, поскольку продукты не обязательно должны иметь общий базовый класс или интерфейс. Но вы всегда сможете добавить метод получения результата в общий интерфейс, если ваши строители производят однородные продукты с общим предком. + Подумайте о создании класса директора. Его методы будут создавать различные конфигурации продуктов, вызывая разные шаги одного и того же строителя. + Клиентский код должен будет создавать и объекты строителей, и объект директора. Перед началом строительства клиент должен связать определённого строителя с директором. Это можно сделать либо через конструктор, либо через сеттер, либо подав строителя напрямую в строительный метод директора. + Результат строительства можно вернуть из директора, но только если метод возврата продукта удалось поместить в общий интерфейс строителей. Иначе вы жёстко привяжете директора к конкретным классам строителей. __Преимущества и недостатки__ + Позволяет создавать продукты пошагово. + Позволяет использовать один и тот же код для создания различных продуктов. + Изолирует сложный код сборки продукта от его основной бизнес-логики. + - Усложняет код программы из-за введения дополнительных классов. + - Клиент будет привязан к конкретным классам строителей, так как в интерфейсе строителя может не быть метода получения результата. ## Фабричный метод Представьте, что вы создаёте программу управления грузовыми перевозками. Сперва вы рассчитываете перевозить товары только на автомобилях. Поэтому весь ваш код работает с объектами класса Грузовик. В какой-то момент ваша программа становится настолько известной, что морские перевозчики выстраиваются в очередь и просят добавить поддержку морской логистики в программу. Отличные новости, правда?! Но как насчёт кода? Большая часть существующего кода жёстко привязана к классам Грузовиков. Чтобы добавить в программу классы морских Судов, понадобится перелопатить всю программу. Более того, если вы потом решите добавить в программу ещё один вид транспорта, то всю эту работу придётся повторить. В итоге вы получите ужасающий код, наполненный условными операторами, которые выполняют то или иное действие, в зависимости от класса транспорта. __Решение__ Паттерн Фабричный метод предлагает создавать объекты не напрямую, используя оператор new, а через вызов особого фабричного метода. Не пугайтесь, объекты всё равно будут создаваться при помощи new, но делать это будет фабричный метод. На первый взгляд, это может показаться бессмысленным: мы просто переместили вызов конструктора из одного конца программы в другой. Но теперь вы сможете переопределить фабричный метод в подклассе, чтобы изменить тип создаваемого продукта. Чтобы эта система заработала, все возвращаемые объекты должны иметь общий интерфейс. Подклассы смогут производить объекты различных классов, следующих одному и тому же интерфейсу. Например, классы Грузовик и Судно реализуют интерфейс Транспорт с методом доставить. Каждый из этих классов реализует метод по-своему: грузовики везут грузы по земле, а суда — по морю. Фабричный метод в классе ДорожнойЛогистики вернёт объект-грузовик, а класс МорскойЛогистики — объект-судно. Для клиента фабричного метода нет разницы между этими объектами, так как он будет трактовать их как некий абстрактный Транспорт. Для него будет важно, чтобы объект имел метод доставить, а как конкретно он работает — не важно. ```java // Паттерн Фабричный метод применим тогда, когда в программе // есть иерархия классов продуктов. interface Button is method render() method onClick(f) class WindowsButton implements Button is method render(a, b) is // Отрисовать кнопку в стиле Windows. method onClick(f) is // Навесить на кнопку обработчик событий Windows. class HTMLButton implements Button is method render(a, b) is // Вернуть HTML-код кнопки. method onClick(f) is // Навесить на кнопку обработчик события браузера. // Базовый класс фабрики. Заметьте, что "фабрика" — это всего // лишь дополнительная роль для класса. Скорее всего, он уже // имеет какую-то бизнес-логику, в которой требуется создание // разнообразных продуктов. class Dialog is method render() is // Чтобы использовать фабричный метод, вы должны // убедиться в том, что эта бизнес-логика не зависит от // конкретных классов продуктов. Button — это общий // интерфейс кнопок, поэтому все хорошо. Button okButton = createButton() okButton.onClick(closeDialog) okButton.render() // Мы выносим весь код создания продуктов в особый метод, // который назвают "фабричным". abstract method createButton():Button // Конкретные фабрики переопределяют фабричный метод и // возвращают из него собственные продукты. class WindowsDialog extends Dialog is method createButton():Button is return new WindowsButton() class WebDialog extends Dialog is method createButton():Button is return new HTMLButton() class Application is field dialog: Dialog // Приложение создаёт определённую фабрику в зависимости от // конфигурации или окружения. method initialize() is config = readApplicationConfigFile() if (config.OS == "Windows") then dialog = new WindowsDialog() else if (config.OS == "Web") then dialog = new WebDialog() else throw new Exception("Error! Unknown operating system.") // Если весь остальной клиентский код работает с фабриками и // продуктами только через общий интерфейс, то для него // будет не важно, какая фабрика была создана изначально. method main() is this.initialize() dialog.render() ``` __Применимость__ Когда заранее неизвестны типы и зависимости объектов, с которыми должен работать ваш код. Фабричный метод отделяет код производства продуктов от остального кода, который эти продукты использует. Благодаря этому, код производства можно расширять, не трогая основной. Так, чтобы добавить поддержку нового продукта, вам нужно создать новый подкласс и определить в нём фабричный метод, возвращая оттуда экземпляр нового продукта. Когда вы хотите дать возможность пользователям расширять части вашего фреймворка или библиотеки. Пользователи могут расширять классы вашего фреймворка через наследование. Но как сделать так, чтобы фреймворк создавал объекты из этих новых классов, а не из стандартных? Решением будет дать пользователям возможность расширять не только желаемые компоненты, но и классы, которые создают эти компоненты. А для этого создающие классы должны иметь конкретные создающие методы, которые можно определить. Например, вы используете готовый UI-фреймворк для своего приложения. Но вот беда — требуется иметь круглые кнопки, вместо стандартных прямоугольных. Вы создаёте класс RoundButton. Но как сказать главному классу фреймворка UIFramework, чтобы он теперь создавал круглые кнопки, вместо стандартных? Для этого вы создаёте подкласс UIWithRoundButtons из базового класса фреймворка, переопределяете в нём метод создания кнопки (а-ля createButton) и вписываете туда создание своего класса кнопок. Затем используете UIWithRoundButtons вместо стандартного UIFramework. Когда вы хотите экономить системные ресурсы, повторно используя уже созданные объекты, вместо порождения новых. Такая проблема обычно возникает при работе с тяжёлыми ресурсоёмкими объектами, такими, как подключение к базе данных, файловой системе и т. д. Представьте, сколько действий вам нужно совершить, чтобы повторно использовать существующие объекты: + Сначала вам следует создать общее хранилище, чтобы хранить в нём все создаваемые объекты. + При запросе нового объекта нужно будет заглянуть в хранилище и проверить, есть ли там неиспользуемый объект. + А затем вернуть его клиентскому коду. + Но если свободных объектов нет — создать новый, не забыв добавить его в хранилище. Весь этот код нужно куда-то поместить, чтобы не засорять клиентский код. Самым удобным местом был бы конструктор объекта, ведь все эти проверки нужны только при создании объектов. Но, увы, конструктор всегда создаёт новые объекты, он не может вернуть существующий экземпляр. Значит, нужен другой метод, который бы отдавал как существующие, так и новые объекты. Им и станет фабричный метод. __Шаги реализации__ + Приведите все создаваемые продукты к общему интерфейсу. + В классе, который производит продукты, создайте пустой фабричный метод. В качестве возвращаемого типа укажите общий интерфейс продукта. + Затем пройдитесь по коду класса и найдите все участки, создающие продукты. Поочерёдно замените эти участки вызовами фабричного метода, перенося в него код создания различных продуктов. В фабричный метод, возможно, придётся добавить несколько параметров, контролирующих, какой из продуктов нужно создать. На этом этапе фабричный метод, скорее всего, будет выглядеть удручающе. В нём будет жить большой условный оператор, выбирающий класс создаваемого продукта. Но не волнуйтесь, мы вот-вот исправим это. + Для каждого типа продуктов заведите подкласс и переопределите в нём фабричный метод. Переместите туда код создания соответствующего продукта из суперкласса. + Если создаваемых продуктов слишком много для существующих подклассов создателя, вы можете подумать о введении параметров в фабричный метод, которые позволят возвращать различные продукты в пределах одного подкласса. Например, у вас есть класс Почта с подклассами АвиаПочта и НаземнаяПочта, а также классы продуктов Самолёт, Грузовик и Поезд. Авиа соответствует Самолётам, но для НаземнойПочты есть сразу два продукта. Вы могли бы создать новый подкласс почты для поездов, но проблему можно решить и по-другому. Клиентский код может передавать в фабричный метод НаземнойПочты аргумент, контролирующий тип создаваемого продукта. + Если после всех перемещений фабричный метод стал пустым, можете сделать его абстрактным. Если в нём что-то осталось — не беда, это будет его реализацией по умолчанию. __Преимущества и недостатки__ + Избавляет класс от привязки к конкретным классам продуктов. + Выделяет код производства продуктов в одно место, упрощая поддержку кода. + Упрощает добавление новых продуктов в программу. + Реализует принцип открытости/закрытости. + - Может привести к созданию больших параллельных иерархий классов, так как для каждого класса продукта надо создать свой подкласс создателя. ## Прототип Prototype У вас есть объект, который нужно скопировать. Как это сделать? Нужно создать пустой объект такого же класса, а затем поочерёдно скопировать значения всех полей из старого объекта в новый. Прекрасно! Но есть нюанс. Не каждый объект удастся скопировать таким образом, ведь часть его состояния может быть приватной, а значит — недоступной для остального кода программы. Но есть и другая проблема. Копирующий код станет зависим от классов копируемых объектов. Ведь, чтобы перебрать все поля объекта, нужно привязаться к его классу. Из-за этого вы не сможете копировать объекты, зная только их интерфейсы, а не конкретные классы. __Решение__ Паттерн Прототип поручает создание копий самим копируемым объектам. Он вводит общий интерфейс для всех объектов, поддерживающих клонирование. Это позволяет копировать объекты, не привязываясь к их конкретным классам. Обычно такой интерфейс имеет всего один метод clone. Реализация этого метода в разных классах очень схожа. Метод создаёт новый объект текущего класса и копирует в него значения всех полей собственного объекта. Так получится скопировать даже приватные поля, так как большинство языков программирования разрешает доступ к приватным полям любого объекта текущего класса. Объект, который копируют, называется прототипом (откуда и название паттерна). Когда объекты программы содержат сотни полей и тысячи возможных конфигураций, прототипы могут служить своеобразной альтернативой созданию подклассов.В этом случае все возможные прототипы заготавливаются и настраиваются на этапе инициализации программы. Потом, когда программе нужен новый объект, она создаёт копию из приготовленного прототипа. ```java // Базовый прототип. abstract class Shape is field X: int field Y: int field color: string // Обычный конструктор. constructor Shape() is // ... // Конструктор прототипа. constructor Shape(source: Shape) is this() this.X = source.X this.Y = source.Y this.color = source.color // Результатом операции клонирования всегда будет объект из // иерархии классов Shape. abstract method clone():Shape // Конкретный прототип. Метод клонирования создаёт новый объект // текущего класса, передавая в его конструктор ссылку на // собственный объект. Благодаря этому операция клонирования // получается атомарной — пока не выполнится конструктор, нового // объекта ещё не существует. Но как только конструктор завершит // работу, мы получим полностью готовый объект-клон, а не пустой // объект, который нужно ещё заполнить. class Rectangle extends Shape is field width: int field height: int constructor Rectangle(source: Rectangle) is // Вызов родительского конструктора нужен, чтобы // скопировать потенциальные приватные поля, объявленные // в родительском классе. super(source) this.width = source.width this.height = source.height method clone():Shape is return new Rectangle(this) class Circle extends Shape is field radius: int constructor Circle(source: Circle) is super(source) this.radius = source.radius method clone():Shape is return new Circle(this) // Где-то в клиентском коде. class Application is field shapes: array of Shape constructor Application() is Circle circle = new Circle() circle.X = 10 circle.Y = 10 circle.radius = 20 shapes.add(circle) Circle anotherCircle = circle.clone() shapes.add(anotherCircle) // anotherCircle будет содержать точную копию circle. Rectangle rectangle = new Rectangle() rectangle.width = 10 rectangle.height = 20 shapes.add(rectangle) method businessLogic() is // Плюс Прототипа в том, что вы можете клонировать набор // объектов, не зная их конкретные классы. Array shapesCopy = new Array of Shapes. // Например, мы не знаем, какие конкретно объекты // находятся внутри массива shapes, так как он объявлен // с типом Shape. Но благодаря полиморфизму, мы можем // клонировать все объекты «вслепую». Будет выполнен // метод clone того класса, которым является этот // объект. foreach (s in shapes) do shapesCopy.add(s.clone()) // Переменная shapesCopy будет содержать точные копии // элементов массива shapes. ``` __Применимость__ Когда ваш код не должен зависеть от классов копируемых объектов. Такое часто бывает, если ваш код работает с объектами, поданными извне через какой-то общий интерфейс. Вы не можете привязаться к их классам, даже если бы хотели, поскольку их конкретные классы неизвестны. Паттерн прототип предоставляет клиенту общий интерфейс для работы со всеми прототипами. Клиенту не нужно зависеть от всех классов копируемых объектов, а только от интерфейса клонирования. Когда вы имеете уйму подклассов, которые отличаются начальными значениями полей. Кто-то мог создать все эти классы, чтобы иметь возможность легко порождать объекты с определённой конфигурацией. Паттерн прототип предлагает использовать набор прототипов, вместо создания подклассов для описания популярных конфигураций объектов. Таким образом, вместо порождения объектов из подклассов, вы будете копировать существующие объекты-прототипы, в которых уже настроено внутреннее состояние. Это позволит избежать взрывного роста количества классов в программе и уменьшить её сложность. __Шаги реализации__ + Создайте интерфейс прототипов с единственным методом clone. Если у вас уже есть иерархия продуктов, метод клонирования можно объявить непосредственно в каждом из её классов. + Добавьте в классы будущих прототипов альтернативный конструктор, принимающий в качестве аргумента объект текущего класса. Этот конструктор должен скопировать из поданного объекта значения всех полей, объявленных в рамках текущего класса, а затем передать выполнение родительскому конструктору, чтобы тот позаботился о полях, объявленных в суперклассе. Если ваш язык программирования не поддерживает перегрузку методов, то вам не удастся создать несколько версий конструктора. В этом случае копирование значений можно проводить и в другом методе, специально созданном для этих целей. Конструктор удобнее тем, что позволяет клонировать объект за один вызов. + Метод клонирования обычно состоит всего из одной строки: вызова оператора new с конструктором прототипа. Все классы, поддерживающие клонирование, должны явно определить метод clone, чтобы использовать собственный класс с оператором new. В обратном случае результатом клонирования станет объект родительского класса. + Опционально, создайте центральное хранилище прототипов. В нём удобно хранить вариации объектов, возможно, даже одного класса, но по-разному настроенных. Вы можете разместить это хранилище либо в новом фабричном классе, либо в фабричном методе базового класса прототипов. Такой фабричный метод должен на основании входящих аргументов искать в хранилище прототипов подходящий экземпляр, а затем вызывать его метод клонирования и возвращать полученный объект. Наконец, нужно избавиться от прямых вызовов конструкторов объектов, заменив их вызовами фабричного метода хранилища прототипов. __Преимущества и недостатки__ + Позволяет клонировать объекты, не привязываясь к их конкретным классам. + Меньше повторяющегося кода инициализации объектов. + Ускоряет создание объектов. + Альтернатива созданию подклассов для конструирования сложных объектов. + - Сложно клонировать составные объекты, имеющие ссылки на другие объекты. ## Синглтон Singleton Одиночка решает сразу две проблемы, нарушая принцип единственной ответственности класса. Гарантирует наличие единственного экземпляра класса. Чаще всего это полезно для доступа к какому-то общему ресурсу, например, базе данных. Представьте, что вы создали объект, а через некоторое время пробуете создать ещё один. В этом случае хотелось бы получить старый объект, вместо создания нового. Такое поведение невозможно реализовать с помощью обычного конструктора, так как конструктор класса всегда возвращает новый объект. Предоставляет глобальную точку доступа. Это не просто глобальная переменная, через которую можно достучаться к определённому объекту. Глобальные переменные не защищены от записи, поэтому любой код может подменять их значения без вашего ведома. Но есть и другой нюанс. Неплохо бы хранить в одном месте и код, который решает проблему №1, а также иметь к нему простой и доступный интерфейс. Интересно, что в наше время паттерн стал настолько известен, что теперь люди называют «одиночками» даже те классы, которые решают лишь одну из проблем, перечисленных выше. __Решение__ Все реализации одиночки сводятся к тому, чтобы скрыть конструктор по умолчанию и создать публичный статический метод, который и будет контролировать жизненный цикл объекта-одиночки. Если у вас есть доступ к классу одиночки, значит, будет доступ и к этому статическому методу. Из какой точки кода вы бы его ни вызвали, он всегда будет отдавать один и тот же объект. ```java // Класс одиночки определяет статический метод `getInstance`, // который позволяет клиентам повторно использовать одно и то же // подключение к базе данных по всей программе. class Database is // Поле для хранения объекта-одиночки должно быть объявлено // статичным. private static field instance: Database // Конструктор одиночки всегда должен оставаться приватным, // чтобы клиенты не могли самостоятельно создавать // экземпляры этого класса через оператор `new`. private constructor Database() is // Здесь может жить код инициализации подключения к // серверу баз данных. // ... // Основной статический метод одиночки служит альтернативой // конструктору и является точкой доступа к экземпляру этого // класса. public static method getInstance() is if (Database.instance == null) then acquireThreadLock() and then // На всякий случай ещё раз проверим, не был ли // объект создан другим потоком, пока текущий // ждал освобождения блокировки. if (Database.instance == null) then Database.instance = new Database() return Database.instance // Наконец, любой класс одиночки должен иметь какую-то // полезную функциональность, которую клиенты будут // запускать через полученный объект одиночки. public method query(sql) is // Все запросы к базе данных будут проходить через этот // метод. Поэтому имеет смысл поместить сюда какую-то // логику кеширования. // ... class Application is method main() is Database foo = Database.getInstance() foo.query("SELECT ...") // ... Database bar = Database.getInstance() bar.query("SELECT ...") // Переменная "bar" содержит тот же объект, что и // переменная "foo". ``` __Применимость__ Когда в программе должен быть единственный экземпляр какого-то класса, доступный всем клиентам (например, общий доступ к базе данных из разных частей программы). Одиночка скрывает от клиентов все способы создания нового объекта, кроме специального метода. Этот метод либо создаёт объект, либо отдаёт существующий объект, если он уже был создан. Когда вам хочется иметь больше контроля над глобальными переменными. В отличие от глобальных переменных, Одиночка гарантирует, что никакой другой код не заменит созданный экземпляр класса, поэтому вы всегда уверены в наличии лишь одного объекта-одиночки. Тем не менее, в любой момент вы можете расширить это ограничение и позволить любое количество объектов-одиночек, поменяв код в одном месте (метод getInstance). __Шаги реализации__ + Добавьте в класс приватное статическое поле, которое будет содержать одиночный объект. + Объявите статический создающий метод, который будет использоваться для получения одиночки. + Добавьте «ленивую инициализацию» (создание объекта при первом вызове метода) в создающий метод одиночки. + Сделайте конструктор класса приватным. + В клиентском коде замените вызовы конструктора одиночка вызовами его создающего метода. __Преимущества и недостатки__ + Гарантирует наличие единственного экземпляра класса. + Предоставляет к нему глобальную точку доступа. + Реализует отложенную инициализацию объекта-одиночки. + - Нарушает принцип единственной ответственности класса. + - Маскирует плохой дизайн. + - Проблемы мультипоточности. + - Требует постоянного создания Mock-объектов при юнит-тестировании. ## Приведите примеры структурных шаблонов проектирования. + __Адаптер (Adapter)__ - это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе. Пример: + __Мост (Bridge)__ - это структурный паттерн проектирования, который разделяет один или несколько классов на две отдельные иерархии — абстракцию и реализацию, позволяя изменять их независимо друг от друга. Пример: + __Компоновщик (Composite)__ - это структурный паттерн проектирования, который позволяет сгруппировать множество объектов в древовидную структуру, а затем работать с ней так, как будто это единичный объект. Пример: + __Декоратор (Decorator)__ - это структурный паттерн проектирования, который позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «обёртки» без использования наследования. Пример: + __Фасад (Facade)__ - это структурный паттерн проектирования, который предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку. Пример: + __Приспособленец (Flyweight)__ - это структурный паттерн проектирования, который позволяет вместить бóльшее количество объектов в отведённую оперативную память. Легковес экономит память, разделяя общее состояние объектов между собой, вместо хранения одинаковых данных в каждом объекте. Представляющий себя как уникальный экземпляр в разных местах программы, но по факту не являющийся таковым. Пример: + __Заместитель (Proxy)__ - это структурный паттерн проектирования, который позволяет подставлять вместо реальных объектов специальные объекты-заменители. Эти объекты перехватывают вызовы к оригинальному объекту, позволяя сделать что-то до или после передачи вызова оригиналу. Пример: кеш в Hibernate, ленивая инициализация в Hibernate, транзакции в Spring [к оглавлению](#Шаблоны-проектирования) ## Приведите примеры поведенческих шаблонов проектирования. + __Цепочка обязанностей (Chain of responsibility)__ - это поведенческий паттерн проектирования, который позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи. + __Команда (Command)__ - это поведенческий паттерн проектирования, который превращает запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить запросы в очередь, логировать их, а также поддерживать отмену операций. + __Интерпретатор (Interpreter)__ - Решает часто встречающуюся, но подверженную изменениям, задачу. + __Итератор (Iterator)__ - это поведенческий паттерн проектирования, который даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления (без использования описаний каждого + __из объектов, входящих в состав агрегации). + __Посредник (Mediator)__ - это поведенческий паттерн проектирования, который позволяет уменьшить связанность множества классов между собой, благодаря перемещению этих связей в один класс-посредник. + __Снимок (Memento)__ - это поведенческий паттерн проектирования, который позволяет сохранять и восстанавливать прошлые состояния объектов, не раскрывая подробностей их реализации. + __Наблюдатель (Observer)__ - это поведенческий паттерн проектирования, который создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах. Пример: ContexLoaderListener в Hibernate. + __Состояние (State)__ - Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния. + __Стратегия (Strategy)__ - это поведенческий паттерн проектирования, который определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, после чего алгоритмы можно взаимозаменять прямо во время исполнения программы. + __Шаблонный метод (Template method)__ - это поведенческий паттерн проектирования, который определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Паттерн позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры. + __Посетитель (Visitor)__ - это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться. [к оглавлению](#Шаблоны-проектирования) ## Что такое _«антипаттерн»_? Какие антипаттерны вы знаете? __Антипаттерн (anti-pattern)__ — это распространённый подход к решению класса часто встречающихся проблем, являющийся неэффективным, рискованным или непродуктивным. __Poltergeists (полтергейсты)__ - это классы с ограниченной ответственностью и ролью в системе, чьё единственное предназначение — передавать информацию в другие классы. Их эффективный жизненный цикл непродолжителен. Полтергейсты нарушают стройность архитектуры программного обеспечения, создавая избыточные (лишние) абстракции, они чрезмерно запутанны, сложны для понимания и трудны в сопровождении. Обычно такие классы задумываются как классы-контроллеры, которые существуют только для вызова методов других классов, зачастую в предопределенной последовательности. Признаки появления и последствия антипаттерна + Избыточные межклассовые связи. + Временные ассоциации. + Классы без состояния (содержащие только методы и константы). + Временные объекты и классы (с непродолжительным временем жизни). + Классы с единственным методом, который предназначен только для создания или вызова других классов посредством временной ассоциации. + Классы с именами методов в стиле «управления», такие как startProcess. Типичные причины + Отсутствие объектно-ориентированной архитектуры (архитектор не понимает объектно-ориентированной парадигмы). + Неправильный выбор пути решения задачи. + Предположения об архитектуре приложения на этапе анализа требований (до объектно-ориентированного анализа) могут также вести к проблемам на подобии этого антипаттерна. __Внесенная сложность (Introduced complexity)__: Необязательная сложность дизайна. Вместо одного простого класса выстраивается целая иерархия интерфейсов и классов. Типичный пример «Интерфейс - Абстрактный класс - Единственный класс реализующий интерфейс на основе абстрактного». __Инверсия абстракции (Abstraction inversion)__: Сокрытие части функциональности от внешнего использования, в надежде на то, что никто не будет его использовать. __Неопределённая точка зрения (Ambiguous viewpoint)__: Представление модели без спецификации её точки рассмотрения. __Большой комок грязи (Big ball of mud)__: Система с нераспознаваемой структурой. __Божественный объект (God object)__: Концентрация слишком большого количества функций в одной части системы (классе). __Затычка на ввод данных (Input kludge)__: Забывчивость в спецификации и выполнении поддержки возможного неверного ввода. __Раздувание интерфейса (Interface bloat)__: Разработка интерфейса очень мощным и очень сложным для реализации. __Волшебная кнопка (Magic pushbutton)__: Выполнение результатов действий пользователя в виде неподходящего (недостаточно абстрактного) интерфейса. Например, написание прикладной логики в обработчиках нажатий на кнопку. __Перестыковка (Re-Coupling)__: Процесс внедрения ненужной зависимости. __Дымоход (Stovepipe System)__: Редко поддерживаемая сборка плохо связанных компонентов. __Состояние гонки (Race hazard)__: непредвидение возможности наступления событий в порядке, отличном от ожидаемого. __Членовредительство (Mutilation)__: Излишнее «затачивание» объекта под определенную очень узкую задачу таким образом, что он не способен будет работать с никакими иными, пусть и очень схожими задачами. __Сохранение или смерть (Save or die)__: Сохранение изменений лишь при завершении приложения. [к оглавлению](#Шаблоны-проектирования) ## Что такое _Dependency Injection_? __Dependency Injection (внедрение зависимости)__ - это набор паттернов и принципов разработки програмного обеспечения, которые позволяют писать слабосвязный код. В полном соответствии с принципом единой обязанности объект отдаёт заботу о построении требуемых ему зависимостей внешнему, специально предназначенному для этого общему механизму. [к оглавлению](#Шаблоны-проектирования) # Источники + [Википедия](https://ru.wikipedia.org/wiki/Шаблон_проектирования) + [Javenue](http://www.javenue.info/post/56) [Вопросы для собеседования](README.md)