ООП для чайников. Паттерны проектирования. Прокси (proxy)

Последний паттерн из группы структурных, — Прокси. Его назначение в том, что бы добавлять дополнительный слой функциональности между клиентом и подсистемой (субъектом). В такой, казалось бы избыточной работе есть масса смысла и пользы, приведу несколько примеров когда это оправдано: субъект находится на другой машине и Прокси скрывает протокол доступа, при обращениях создает экземпляр субъекта, только когда это действительно надо, кеширует результаты. может контролировать права доступа при вызовах производит синхронные вызовы в асинхронной среде На диаграмме прокси выглядит так: Короткий пример Прокси: class XMPPRequest(): def __init__(self, connect): pass def send(self, to, text): return

Continue Reading

ООП для чайников. Паттерны проектирования. Приспособленец (flyweight)

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

Continue Reading

ООП для чайников. Паттерны проектирования. Фасад (facade)

Еще один паттерн из группы структурирующих, – фасад. Фасад предоставляет унифицированный интерфейс, “оборачивая” собой подсистему. Им пользуются в случае если необходимо изолировать клиента от “разухабистого” API подсистемы, упрощая его и сокращая количество объектов о которых должен знать клиент. Фасад может упростить переносимость кода между разными платформами или подсистемами. Вот как выглядит Фасад на диаграмме: Простой пример, реализующий Фасад на Python: class Tree: def grow(self): print("grow tree") class Child: def born(self): print("born child") class House: def build(self): print("build house") class TheMenFacade:

Continue Reading

ООП для чайников. Паттерны проектирования. Декоратор (decorator)

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

Continue Reading

ООП для чайников. Паттерны проектирования. Компоновщик (composite)

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

Continue Reading

ООП для чайников. Паттерны проектирования. Мост (bridge)

Следующий патерн, также относится к типу структурных, и называется — мост. Смысл этого паттерна в том чтобы отделить абстракцию от реализации. В каком-то смысле он очень похож на адаптер, с той разницей что адаптер, «адаптирует» интерфейсы классов друг к другу, а мост, разделяет их, для того что бы сделать возможным изменение интерфейсов независимо от реализации. Вот как выглядит он выглядит на диаграмме: Этот патерн следует применять, например, когда нужно отвязать интерфейс от реализации во время выполнения. Мост повышает расширяемость, позволяя независимо расширять абстракции и реализации. Пример реализации паттарна Мост на Python: class SortAbstraction: def sortImpl(self, sortImpl): self._sortImpl = sortImpl

Continue Reading

ООП для чайников. Паттерны проектирования. Адаптер (adapter)

С недавнего времени, мы в команде завели такую практику как обмен опытом. Сначала мы пробовали просто готовить доклады, на всякого рода интересные темы касающиеся технологий, практик и подходов. Но, этот подход не совсем себя оправдал, и мы стали готовить небольшие доклады на заранее оговоренные темы, например, — паттерны проектирования. Идея состоит в том что мы выбираем несколько паттернов, делаем лаконичный пример использования, на каком-то языке не связанной с основной работой (php). Затем мы собираемся, показываем свои примеры, и обсуждаем конкретный паттерн и реализацию. Так у нас накопилось некоторое количество реализаций на Python, Ruby, Groovy. На самом деле, как мы потом убедились, выбор скриптового

Continue Reading

Site Footer

Sliding Sidebar

About Me

About Me

Для кого этот блог?

Для тех кого интересуют современные интернет технологи, IT бизнес, стартапы, менеджмент, контроль качества, личная эффективность, мотивация. Здесь я буду писать о том, что в первую очередь будет интересно мне, о проблемах и решениях. О том что пригодилось мне, и возможно будет интересно Вам.

Что заставило меня создать его?

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

Немного о себе.

Мой первый серьезный опыт в IT это работа над desktop приложениями в компании «Эксперт-Софт». У истоков её стояли несколько амбициозных и талантливых молодых людей, с огнем в глазах и желанием работать «как майкрософт». То чем мы там занимались вполне могли бы сегодня назвать «стартапом». Рук было откровенно мало, поэтому приходилось заниматься всем: кодированием на Delphi, написанием скриптов на VBA, дизайном, вёрсткой и поддержкой вебсайта, работой над рекламной полиграфией, проектированием интерфейсов и БД. Работы было много, но запал был велик, команда очень разношерстная, гармонично дополняя друг-друга в решении нетривиальных задач. Благодаря тому что пришлось попробовать многое, постепенно вырисовалось понимание того чем хочется заниматься, и как. Софтверным программированием я был сыт по горло. Массы проблем десктопного софта в вебе просто не было, по определению. Зато был четкий фокус на дизайне, юзабилити, скорости. Поэтому когда пришла пора уходить из «Эксперт-Софт», я без всякого сожаления стал искать работу как разработчик для web. Поскольку городишко у нас не очень большой, выбор был практически предопределен. Так я стал работать в «Оникс-Системз», где и продолжаю работать поныне. За время работы в компании я как разработчик принимал участие в работе над несколькими десятками проектов. Несколько десятков проектов было сделано мною как фрилансером. Самым большим проектом в котором я сыграл роль менеджера, считаю свою семью. Также довольно большой проект мы сейчас поднимаем с командой разработчиков (на данный момент команда состоит из четырех php разработчиков, одного flex кодера и тестировщика). Отсюда, большой интерес к современным практикам и методологиям, разным подходам в управлении командой, повышению эффективности и качества работы. По мере сил, вдохновения и свободного времени, я буду писать об этом.

Если у Вас возникли какие-то вопросы ко мне лично, буду рад если Вы свяжетесь со мной:

e-mail:
skype: denis.sheremetov
Старый сайт, с музычкой и флешом

Прочая онлайновая деятельность: