паттерн

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

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

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

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

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

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

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