Сегодня мы рассмотрим паттерн абстрактная фабрика, или фабрика, как его часто называют. Этот паттерн относится к группе порождающих и решает проблему создания группы объектов. Классический пример использования фабрики для предоставления приложению элементов интерфейса в зависимости от платформы. Например, приложение на linux будет создавать при помощи фабрики кнопки, поля и прочие элементы через фабрику, которая в […]

Предыдущий опыт показал что скриптовые языки не очень подходят для иллюстрации паттернов и дальше мы ограничились использованием ООП языков со строгой типизацией, так сказать, для большей наглядности. Сегодня речь пойдет о паттерне Строитель, предназначенного для конструирования объектов. Если процесс создания какого либо сложного объекта из составных имеет схожие этапы, имеет смысл описать единый алгоритм создания включающий в себя действия по созданию необходимого объекта. […]

Еще один паттерн, из группы поведенческих, — цепочка ответственности (chain of responsibility). Цепочка обязанностей выстраивает объекты составных частей приложения связанными между собой по цепочке, для передачи запроса на обработку от более низких, детализированных слоев системы к более высоким глобальным. Вот UML диаграмма: Классический пример это контекстная справка в Microsoft Office, вы можете нажать кнопку вопросительного знака и кликнуть на любом элементе интерфейса, а система попытается найти страницу […]

Последний паттерн из группы структурных, — Прокси. Его назначение в том, что бы добавлять дополнительный слой функциональности между клиентом и подсистемой (субъектом). В такой, казалось бы избыточной работе есть масса смысла и пользы, приведу несколько примеров когда это оправдано: субъект находится на другой машине и Прокси скрывает протокол доступа, при обращениях создает экземпляр субъекта, только когда это действительно надо, кеширует результаты. может контролировать права доступа […]

Следующий паттерн, — Приспособленец. Приспособленцы моделируют сущности, число которых слишком велико для представления объектами. В моем примере это отрисовка игровой карты (или участка карты). Например ваша карта состоит из плиток пола и стен, но по разному отрисовываются, с учетом света, времени суток, и других факторов. Создавать для каждого сегмента карты отдельный экземпляр, — слишком большая роскошь. Поэтому мы создаем по одному экземпляру каждого типа и с их помощью отрисовываем […]

Еще один паттерн из группы структурирующих, – фасад. Фасад предоставляет унифицированный интерфейс, “оборачивая” собой подсистему. Им пользуются в случае если необходимо изолировать клиента от “разухабистого” API подсистемы, упрощая его и сокращая количество объектов о которых должен знать клиент. Фасад может упростить переносимость кода между разными платформами или подсистемами. Вот как выглядит Фасад на диаграмме: Простой […]

Еще один паттерн из группы структурирующих, — декоратор. Его назначение в том чтобы возложить дополнительные обязанности (прозрачные для клиентов) на отдельный объект, а не на класс в целом. Функциональность обязанностей реализуется в небольших объектах. Преимущество состоит в возможности динамически добавлять эту функциональность до или после основной функциональности объекта ConcreteComponent. Декоратор позволяет разгрузить приложение от классов с похожей функциональностью. Классический пример Декоратора, — это какой-нибудь класс, рисующий прямоугольник, с добавлением декораторов, […]

Следующий паттерн, – компоновщик (composite), тоже из группы структурирующих. Компоновщик организует объекты в древовидные структуры для представления иерархии часть-целое. Всевозможные иерархии деревьев страниц в каталогах, файлов в папках являются яркими представителями паттерна Компоновщик. Диаграмма для Компоновщика, выглядит так: Реализовывая Компоновщик, нужно помнить о том чтобы интерфейс Component был максимально дополнен используемыми публичными методами, избавляя клиента […]

Следующий патерн, также относится к типу структурных, и называется — мост. Смысл этого паттерна в том чтобы отделить абстракцию от реализации. В каком-то смысле он очень похож на адаптер, с той разницей что адаптер, «адаптирует» интерфейсы классов друг к другу, а мост, разделяет их, для того что бы сделать возможным изменение интерфейсов независимо от реализации. Вот как выглядит он выглядит на диаграмме: Этот патерн следует применять, например, когда нужно отвязать интерфейс […]

Первый раз, мне в руки попала книга Дэвида Аллена задолго до того как это стало культовой и модной штукой. Как и все хорошие книги такого содержания, она совершила очередной «переворот в мозгах», — «как я жил раньше не организовывая и планируя каждый шаг», стучало в голове. Эта книга подталкивают вас к действиям, — но если ничего не предпринимать, суть этого знания начинает ускользать и забываться. Так случилось и со мной. Все же, желание […]