Э. Гамма, Р. Хелм
 Скачать 6.37 Mb.
|
|
23 Мотивация Сценарий, иллюстрирующий задачу проектирования и то, как она реша- ется данной структурой класса или объекта. Благодаря мотивации можно лучше понять последующее, более абстрактное описание паттерна. Применимость Описание ситуаций, в которых можно применять данный паттерн. При- меры неудачного проектирования, которые можно улучшить с его по- мощью. Распознавание таких ситуаций. Структура Графическое представление классов в паттерне с использованием но- тации, основанной на методике Object Modeling Technique (OMT) [RBP+91]. Мы пользуемся также диаграммами взаимодействий [JCJO92, Boo94] для иллюстрации последовательностей запросов и отношений между объектами. В приложении Б эта нотация описывается подробно. Участники Классы или объекты, задействованные в данном паттерне проектирова- ния, и их обязанности. Отношения Взаимодействие участников для выполнения своих обязанностей. Результаты Насколько паттерн удовлетворяет поставленным требованиям? К каким результатам приводит паттерн, на какие компромиссы приходится идти? Какие аспекты структуры системы можно независимо изменять при ис- пользовании данного паттерна? Реализация О каких сложностях и подводных камнях следует помнить при реализации паттерна? Существуют ли какие-либо советы и рекомендуемые приемы? Есть ли у данного паттерна зависимость от языка программирования? Пример кода Фрагменты кода, демонстрирующие возможную реализацию на языках C++ или Smalltalk. 24 Глава 1. Введение в паттерны проектирования Известные применения Возможности применения паттерна в реальных системах. Приводятся по меньшей мере два примера из различных областей. Родственные паттерны Какие паттерны проектирования тесно связаны с данным? Какие важ- ные различия существуют между ними? С какими другими паттернами хорошо сочетается данный паттерн? В приложениях приводится общая информация, которая поможет вам лучше понять паттерны и связанные с ними вопросы. Приложение A со- держит глоссарий употребляемых нами терминов. В уже упомянутом при- ложении Б дано описание разнообразных нотаций. Некоторые аспекты применяемой нотации мы поясняем по мере ее появления в тексте книги. Наконец, в приложении В приведен исходный код фундаментальных классов, встречающихся в примерах. 1.4. КАТАЛОГ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ Каталог, начинающийся на с. 108, содержит 23 паттерна. Ниже для удоб- ства перечислены их имена и назначение. В скобках после названия каж- дого паттерна указан номер страницы, откуда начинается его подробное описание. Abstract Factory (абстрактная фабрика) (113) Предоставляет интерфейс для создания семейств связанных между собой или зависимых объектов без указания их конкретных классов. Adapter (адаптер) (171) Преобразует интерфейс класса в другой интерфейс, ожидаемый клиен- тами. Обеспечивает совместную работу классов, которая была бы невоз- можна без данного паттерна из-за несовместимости интерфейсов. Bridge (мост) (184) Отделяет абстракцию от реализации, чтобы их можно было изменять независимо друг от друга. 1.4. Каталог паттернов проектирования 25 Builder (строитель) (124) Отделяет конструирование сложного объекта от его представления, чтобы один процесс конструирования мог использоваться для создания различных представлений. Chain of Responsibility (цепочка обязанностей) (263) Можно избежать формирования жесткой связи между отправителем запроса и его получателем, для чего возможность обработки запроса предоставляется нескольким объектам. Объекты-получатели объединя- ются в цепочку, и запрос передается по цепочке, пока не будет обработан каким-либо объектом. Command (команда) (275) Инкапсулирует запрос в виде объекта, позволяя тем самым параметри- зовывать клиентов по типу запроса, ставить запросы в очередь, протоко- лировать их и поддерживать отмену выполнения операций. Composite (компоновщик) (196) Группирует объекты в древовидные структуры для представления иерар- хий типа «часть — целое». Позволяет клиентам работать с единичными объектами так же, как с группами объектов. Decorator (декоратор) (209) Динамически наделяет объект новыми обязанностями. Декораторы при- меняются для расширения существующей функциональности и являются гибкой альтернативой порождению подклассов. Facade (фасад) (221) Предоставляет унифицированный интерфейс к набору интерфейсов в некоторой подсистеме. Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой. Factory Method (фабричный метод) (135) Определяет интерфейс для создания объектов, позволяя подклассам решить, экземпляр какого класса следует создать. Позволяет классу пере- дать ответственность за создание экземпляра в подклассы. 26 Глава 1. Введение в паттерны проектирования Flyweight (приспособленец) (231) Применяет механизм совместного использования для эффективной под- держки большого числа мелких объектов. Interpreter (интерпретатор) (287) Для заданного языка определяет представление его грамматики вместе с интерпретатором, который использует представление для интерпрета- ции предложений языка. Iterator (итератор) (302) Дает возможность последовательно обойти все элементы составного объ- екта, не раскрывая его внутреннего представления. Mediator (посредник) (319) Определяет объект, в котором инкапсулирована информация о взаимо- действии объектов из некоторого множества. Способствует ослаблению связей между объектами, позволяя им работать без явных ссылок друг на друга. Это, в свою очередь, дает возможность независимо изменять схему взаимодействия. Memento (хранитель) (330) Позволяет без нарушения инкапсуляции получать и сохранять во внеш- ней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить в точно таком же состоянии. Observer (наблюдатель) (339) Определяет между объектами зависимость типа «один-ко-многим», так что при изменении состояния одного объекта все зависящие от него по- лучают уведомление и автоматически обновляются. Prototype (прототип) (146) Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования. Proxy (заместитель) (246) Подменяет другой объект для контроля доступа к нему. 1.5. Организация каталога 27 Singleton (одиночка) (157) Гарантирует, что некоторый класс может существовать только в одном экземпляре, и предоставляет глобальную точку доступа к нему. State (состояние) (352) Позволяет объекту изменять свое поведение при модификации внутренне- го состояния. При этом все выглядит так, словно поменялся класс объекта. Strategy (стратегия) (362) Определяет семейство алгоритмов, инкапсулируя их все и позволяя под- ставлять один вместо другого. Позволяет менять алгоритм независимо от клиента, который им пользуется. Template Method (шаблонный метод) (373) Определяет скелет алгоритма, перекладывая ответственность за неко- торые его шаги на подклассы. Позволяет подклассам переопределять отдельные шаги алгоритма, не меняя его общей структуры. Visitor (посетитель) (379) Представляет операцию, которую надо выполнить над элементами объ- ектной структуры. Позволяет определить новую операцию без изменения классов элементов, к которым он применяется. 1.5. ОРГАНИЗАЦИЯ КАТАЛОГА Паттерны проектирования различаются степенью детализации и уровнем абстракции. Паттернов проектирования довольно много, поэтому их нуж- но как-то организовать. В данном разделе описывается классификация, позволяющая ссылаться на семейства взаимосвязанных паттернов. Она поможет быстрее освоить паттерны, описанные в каталоге, а также укажет направление поиска новых. Мы будем классифицировать паттерны по двум критериям (табл. 1.1). Первый — цель — отражает назначение паттерна. Паттерны делятся на по- рождающие, структурные и паттерны поведения. Первые связаны с процес- сом создания объектов. Вторые имеют отношение к композиции объектов 28 Глава 1. Введение в паттерны проектирования и классов. Паттерны поведения характеризуют то, как классы или объекты взаимодействуют. Таблица 1.1. Пространство паттернов проектирования Цель Уровень Порождающие паттерны Структурные паттерны Паттерны поведения Класс Фабричный метод (135) Адаптер (171) Интерпретатор (287) Шаблонный метод (373) Объект Абстрактная фабрика (113) Адаптер (171) Итератор (302) Одиночка (157) Декоратор (209) Команда (275) Прототип (146) Заместитель (246) Наблюдатель (339) Строитель (124) Компоновщик (196) Посетитель (379) Мост (184) Посредник (319) Приспособленец (231) Состояние (352) Фасад (221) Стратегия (362) Хранитель (330) Цепочка обязанностей (263) Второй критерий — уровень — сообщает, к чему обычно применяется паттерн: к объектам или классам. Паттерны уровня классов описывают отношения между классами и их подклассами. Такие отношения выражаются с помощью наследования, поэтому они статичны, то есть зафиксированы на этапе компи- ляции. Паттерны уровня объектов описывают отношения между объектами, которые могут изменяться во время выполнения и потому более динамичны. Почти все паттерны в какой-то мере используют наследование. Поэтому к категории «паттерны классов» отнесены только те, что концентрируются лишь на отношениях между классами. Обратите внимание: большинство паттернов действует на уровне объектов. Порождающие паттерны классов частично делегируют ответственность за создание объектов своим подклассам, тогда как порождающие паттерны объектов передают ответственность другому объекту. Структурные паттер- ны классов используют наследование для составления классов, в то время как структурные паттерны объектов описывают способы сборки объектов из частей. Поведенческие паттерны классов используют наследование для описания алгоритмов и потока управления, а поведенческие паттерны 1.6. Как решать задачи проектирования с помощью паттернов 29 объектов описывают, как объекты, принадлежащие некоторой группе, со- вместными усилиями выполняют задачу, которая ни одному отдельному объекту не под силу. Существуют и другие способы классификации паттернов. Некоторые пат- терны часто используются вместе. Например, компоновщик применяется с итератором или посетителем. Некоторыми паттернами предлагаются аль- тернативные решения. Так, прототип нередко можно использовать вместо абстрактной фабрики. Применение части паттернов приводит к схожему дизайну, хотя изначально их назначение различно. Например, структурные диаграммы компоновщика и декоратора похожи. Классифицировать паттерны можно и по их ссылкам (см. разделы «Род- ственные паттерны»). На рис. 1.1 такие отношения изображены графически. Ясно, что организовать паттерны проектирования допустимо многими спо- собами. Оценивая паттерны с разных точек зрения, вы глубже поймете, как они функционируют, как их сравнивать и когда применять тот или другой паттерн. 1.6. КАК РЕШАТЬ ЗАДАЧИ ПРОЕКТИРОВАНИЯ С ПОМОЩЬЮ ПАТТЕРНОВ Паттерны проектирования позволяют решать многие повседневные задачи, с которыми сталкиваются проектировщики объектно-ориентированных приложений. Поясним эту мысль примерами. ПОИСК ПОДХОДЯЩИХ ОБЪЕКТОВ Объектно-ориентированные программы состоят из объектов. Объект со- четает данные и процедуры для их обработки. Такие процедуры обычно называют методами или операциями. Объект выполняет операцию, когда получает запрос (или сообщение) от клиента. Отправка запроса — это единственный способ заставить объект выпол- нить операцию. А выполнение операции — единственный способ изменить внутреннее состояние объекта. Из-за этих двух ограничений говорят, что внутреннее состояние объекта инкапсулировано: к нему нельзя обратиться напрямую, а его представление невидимо за пределами объекта. 30 Глава 1. Введение в паттерны проектирования Хранитель Адаптер Заместитель Мост Команда Итератор Строитель Компоновщик Декоратор Приспособленец Посетитель Интерпретатор Цепочка обязанностей Стратегия Посредник Наблюдатель Состояние Шаблонный метод Прототип Фабричный метод Абстрактная фабрика Фасад Одиночка сохранение состояния итерации создание составных объектов добавление новых обязанностей объекту перечисление потомков компоновка с помощью совместное использование составных объектов избежание запаздывания определение обхода определение грамматики добавление операций добавление операций определение цепочки изменение облика, а не внутреннего устройства совместное использование стратегий совместное использование состояний совместное использование терминальных символов управление сложными зависимостями определение шагов алгоритма прочие применения динамическое конфигурирование фабрики единственный экземпляр единственный экземпляр реализация с помощью Рис. 1.1. Отношения между паттернами проектирования 1.6. Как решать задачи проектирования с помощью паттернов 31 Самая трудная задача в объектно-ориентированном проектировании — раз- ложить систему на объекты. При решении приходится учитывать множество факторов: инкапсуляцию, глубину детализации, наличие зависимостей, гибкость, производительность, возможную эволюцию, повторное использо- вание и т. д. и т. п. Все это влияет на декомпозицию, причем часто противо- речивым образом. Методологии объектно-ориентированного проектирования отражают разные подходы. Можно сформулировать задачу письменно, выделить из получив- шейся фразы существительные и глаголы, после чего создать соответству- ющие классы и операции. Другой путь — сосредоточиться на отношениях и разделении обязанностей в системе. Можно построить модель реального мира или перенести выявленные при анализе объекты в свой дизайн. Раз- работчики никогда не придут к единому мнению относительно того, какой подход самый лучший. Многие объекты возникают в проекте из построенной в ходе анализа модели. Однако нередко появляются и классы, не имеющие аналогов в реальном мире. Это могут быть классы как низкого уровня, например массивы, так и высокого. Паттерн компоновщик (196) вводит такую абстракцию для единообразной трактовки объектов, у которой нет физического аналога. Если придерживаться строгого моделирования и ориентироваться только на реальный мир, то получится система, отражающая сегодняшние потреб- ности, но, возможно, не учитывающая будущего развития. Абстракции, возникающие в ходе проектирования, — ключ к гибкому дизайну. Паттерны проектирования помогают выявить не вполне очевидные абстрак- ции и объекты, которые могут их использовать. Например, объектов, пред- ставляющих процесс или алгоритм, в действительности нет, но они являются неотъемлемыми составляющими гибкого дизайна. Паттерн стратегия (362) описывает способ реализации взаимозаменяемых семейств алгоритмов. Пат- терн состояние (352) представляет состояние некоторой сущности в виде объекта. Эти объекты редко возникают во время анализа и даже на ранних стадиях проектирования. Они появляются позднее, при попытках сделать дизайн более гибким и пригодным для повторного использования. ОПРЕДЕЛЕНИЕ СТЕПЕНИ ДЕТАЛИЗАЦИИ ОБЪЕКТА Размеры и число объектов могут изменяться в широком диапазоне. С помо- щью объектов можно представить все, от физических устройств до программ. Как же решить, что должен представлять объект? 32 Глава 1. Введение в паттерны проектирования Паттерны проектирования помогут решить и эту проблему. Паттерн фасад (221) показывает, как представить в виде объекта целые подси- стемы, а паттерн приспособленец (231) — как поддерживать большое число объектов при высокой степени детализации. Другие паттерны ука- зывают путь к разложению объекта на меньшие подобъекты. Абстрактная фабрика (113) и строитель (124) описывают объекты, единственной целью которых яв ляется создание других объектов, а посетитель (379) и команда (275) — объекты, отвечающие за реализацию запроса к другому объекту или группе. ОПРЕДЕЛЕНИЕ ИНТЕРФЕЙСОВ ОБЪЕКТА Для любой операции, объявляемой объектом, должны быть заданы: имя операции, объекты, передаваемые в качестве параметров, и значение, возвра- щаемое операцией. Эту триаду называют сигнатурой операции. Множество сигнатур всех определенных для объекта операций называется интерфейсом этого объекта. Интерфейс описывает все множество запросов, которые мож- но отправить объекту. Любой запрос, сигнатура которого входит в интерфейс объекта, может быть ему отправлен. Тип представляет собой имя, используемое для обозначения конкретного интерфейса. Говорят, что объект имеет тип Window , если он готов принимать запросы на выполнение любых операций, определенных в интерфейсе с име- нем Window . У одного объекта может быть много типов. Напротив, сильно отличающиеся объекты могут разделять общий тип. Одна часть интерфейса объекта может характеризоваться одним типом, а другие части — другими типами. Два объекта одного типа могут разделять только часть своих ин- терфейсов. Интерфейсы могут содержать другие интерфейсы в качестве подмножеств. Мы говорим, что один тип является подтипом другого, если интерфейс первого содержит интерфейс второго. В этом случае второй тип называется супертипом для первого. Часто говорят также, что подтип на- следует интерфейс своего супертипа. В объектно-ориентированных системах интерфейсы играют фундаменталь- ную роль. Все взаимодействие с объектами осуществляется через их интер- фейсы. Никакого способа получить информацию об объекте или заставить его что-то сделать в обход интерфейса не существует. Интерфейс объекта ничего не говорит о его реализации; разные объекты вправе реализовывать сходные запросы совершенно по-разному. Это означает, что два объекта с различными реализациями могут иметь одинаковые интерфейсы. 1.6. Как решать задачи проектирования с помощью паттернов 33 Когда объекту посылается запрос, то операция, которую он выполнит, зависит как от запроса, так и от объекта-адресата. Разные объекты, под- держивающие одинаковые интерфейсы, могут выполнять в ответ на такие запросы разные операции. Ассоциирование запроса с объектом и одной из его операций во время выполнения называется динамическим связыванием. Динамическое связывание означает, что отправка некоторого запроса не определяет никакой конкретной реализации до момента выполнения. Следовательно, возможно написать программу, рассчитанную на объект с конкретным интерфейсом, точно зная, что любой объект с подходящим интерфейсом сможет принять этот запрос. Более того, динамическое свя- зывание позволяет во время выполнения подставить вместо одного объекта другой, если он имеет идентичный интерфейс. Такая взаимозаменяемость называется полиморфизмом и является важнейшей особенностью объектно- ориентированных систем. Она позволяет клиенту ограничиваться мини- мальными предположениями об объектах — а именно поддержкой этими объектами определенного интерфейса. Полиморфизм упрощает определение клиентов, позволяет отделить объекты друг от друга и дает объектам воз- можность изменять отношения между ними во время выполнения. Паттерны проектирования позволяют определять интерфейсы посред- ством задания их основных элементов и того, какие данные можно пере- давать через интерфейс. Паттерн может также сообщить, что не должно включаться в интерфейс. Хорошим примером в этом отношении является хранитель (330). Он описывает, как инкапсулировать и сохранить внутрен- нее состояние объекта таким образом, чтобы в будущем его можно было восстановить точно в таком же состоянии. Объекты, удовлетворяющие требованиям паттерна хранитель, должны определить два интерфейса: один ограниченный, который позволяет клиентам держать у себя и копировать хранителей, а другой привилегированный, которым может пользоваться только исходный объект для сохранения и извлечения информации о своем состоянии в хранителе. Паттерны проектирования также определяют отношения между интерфей- сами. В частности, нередко они требуют, чтобы некоторые классы имели схожие интерфейсы, а иногда налагают ограничения на интерфейсы клас- сов. Так, декоратор (209) и заместитель (246) требуют, чтобы интерфейсы объектов этих паттернов были идентичны интерфейсам декорируемых и за- мещаемых объектов соответственно. Интерфейс объекта, использующего паттерн посетитель (379), должен отражать все классы объектов, с которыми он будет работать. |