Последняя прочитанная мною книга была книга Влада В. Головача «Дизайн пользовательского интерфейса2 Искусство мыть слона». Сказать что она мне понравилась — это ничего не сказать. Во-первых, это лаконичный и содержательный материал, насыщенный примерами из богатого опыта автора. Во-вторых это умозаключения и выводы, которыми автор делится с читателем, и с позицией которого, я на сто процентов солидарен. Эту книгу, я советую каждому, кто в силу своей профессиональной деятельности, связан с проектированием пользовательских интерфейсов. К сожалению то, что является неотьемлемой частью успеха любого информационного продукта, а программное обеспечение, именно таковым и является, зачастую выпускается из виду программистами и дизайнерами, — дизайнерами, в силу …
Blog Posts
Если вы работаете с командой php-разработчиков, то вы знаете как много кода они пишут, особенно если это высокопроизводительная команда разработчиков. программистам свойственно автоматизировать любой рутинный труд, поэтому и труд по контролю над кодом тоже понемногу автоматизируется. Самым полезным, для меня, оказался инструмент Copy/Paste Detector for PHP code. Как ясно из названия, этот инструмент используется для дублирующегося кода, ярым поборником которого я являюсь. Устанавливается он очень просто, как PEAR пакет: sb@ubuntu ~ % pear channel-discover pear.phpunit.de Adding Channel "pear.phpunit.de" succeeded Discovery of channel "pear.phpunit.de" succeeded sb@ubuntu ~ % pear channel-discover …
Еще один паттерн из группы порождающих – фабричный метод (factory method). Этот паттерн позволяет скрывать от клиента логику создания запрашиваемого объекта. Этот паттерн следует применять когда заранее неизвестно объекты каких классов должны быть созданы, поскольку предполагается множество различных вариантов работы, либо объекты, которые класс создает должны быть определены уже в подклассе. Пример применения паттерна на UML диаграмме: А вот, пример применения паттерна в коде, – класс создающий разные типы документов, из одинаковых составных частей: // IChapter.java package patterns.factorymethod.report; public interface …
Сегодня мы рассмотрим паттерн абстрактная фабрика, или фабрика, как его часто называют. Этот паттерн относится к группе порождающих и решает проблему создания группы объектов. Классический пример использования фабрики для предоставления приложению элементов интерфейса в зависимости от платформы. Например, приложение на linux будет создавать при помощи фабрики кнопки, поля и прочие элементы через фабрику, которая в свою очередь, по запросу будет возвращать элементы XWindows, а приложение на windows будет возвращать элементы win32. Таким образом программе становится не важна платформа, платформо-зависимая логика …
Предыдущий опыт показал что скриптовые языки не очень подходят для иллюстрации паттернов и дальше мы ограничились использованием ООП языков со строгой типизацией, так сказать, для большей наглядности. Сегодня речь пойдет о паттерне Строитель, предназначенного для конструирования объектов. Если процесс создания какого либо сложного объекта из составных имеет схожие этапы, имеет смысл описать единый алгоритм создания включающий в себя действия по созданию необходимого объекта. Вот как это выглядит в UML: В моем простом примере логика создания простой игровой карты выносится в класс строителя WorldBuilder, в котором реализовано два метода для создания пустого …
Еще один паттерн, из группы поведенческих, — цепочка ответственности (chain of responsibility). Цепочка обязанностей выстраивает объекты составных частей приложения связанными между собой по цепочке, для передачи запроса на обработку от более низких, детализированных слоев системы к более высоким глобальным. Вот UML диаграмма: Классический пример это контекстная справка в Microsoft Office, вы можете нажать кнопку вопросительного знака и кликнуть на любом элементе интерфейса, а система попытается найти страницу справки, максимально соответствующую запрошенному элементу. Делается это следующим образом, — поскольку интерфейс системы иерархичен, то запрс справки начинает подниматься снизу вверх — от элемента по которому был произведен клик вверх, …
Последний паттерн из группы структурных, — Прокси. Его назначение в том, что бы добавлять дополнительный слой функциональности между клиентом и подсистемой (субъектом). В такой, казалось бы избыточной работе есть масса смысла и пользы, приведу несколько примеров когда это оправдано: субъект находится на другой машине и Прокси скрывает протокол доступа, при обращениях создает экземпляр субъекта, только когда это действительно надо, кеширует результаты. может контролировать права доступа при вызовах производит синхронные вызовы в асинхронной среде На диаграмме прокси выглядит так: Короткий пример Прокси: class XMPPRequest(): def __init__(self, connect): pass def send(self, to, text): return …
Следующий паттерн, — Приспособленец. Приспособленцы моделируют сущности, число которых слишком велико для представления объектами. В моем примере это отрисовка игровой карты (или участка карты). Например ваша карта состоит из плиток пола и стен, но по разному отрисовываются, с учетом света, времени суток, и других факторов. Создавать для каждого сегмента карты отдельный экземпляр, — слишком большая роскошь. Поэтому мы создаем по одному экземпляру каждого типа и с их помощью отрисовываем всю карту. На диаграмме Приспособленец, выглядит следующим образом: Имеет использовать Приспособленца если одновременно выполняются следующие условия: в приложении используется большое число обьектов, из-за этого высоки расходы …
Еще один паттерн из группы структурирующих, – фасад. Фасад предоставляет унифицированный интерфейс, “оборачивая” собой подсистему. Им пользуются в случае если необходимо изолировать клиента от “разухабистого” 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: …
Еще один паттерн из группы структурирующих, — декоратор. Его назначение в том чтобы возложить дополнительные обязанности (прозрачные для клиентов) на отдельный объект, а не на класс в целом. Функциональность обязанностей реализуется в небольших объектах. Преимущество состоит в возможности динамически добавлять эту функциональность до или после основной функциональности объекта ConcreteComponent. Декоратор позволяет разгрузить приложение от классов с похожей функциональностью. Классический пример Декоратора, — это какой-нибудь класс, рисующий прямоугольник, с добавлением декораторов, которые рисуют рамки, заливают цветом или изображением. Причем, применение декоратора, рисующего рамку дважды, нарисует двойную рамку. На диаграмме Декоратор выглядит так: Пример реализации паттерна Декоратор: class …
