Э. Гамма, Р. Хелм
 Скачать 6.37 Mb.
|
|
ГЛАВА 6 ЗАКЛЮЧЕНИЕ Возможно, кто-то скажет, что практическая ценность этой книги не так уж велика. Ведь в ней не описываются никакие ранее неизвестные алгоритмы или приемы программирования. Здесь не предлагается строгой методологии проектирования систем, не делается попытки разработать новую теорию проектирования, а всего лишь документируются существующие приемы. А из этого выходит, что данная книга является неплохим руководством начального уровня, но уж опытному специалисту в области объектно-ори- ентированного проектирования она ни к чему. Надеемся, вы думаете по-другому. Каталогизация паттернов проектирования важна сама по себе. Она задает стандартные названия и определения тем приемам, которыми мы постоянно пользуемся. Если не изучать паттерны проектирования программ, их нельзя будет и усовершенствовать, а приду- мывать новые будет сложнее. Данная книга — только начало. Приведенные в ней паттерны постоянно ис- пользуются в объектно-ориентированном проектировании, но узнать о них можно только из устной молвы или путем изучения существующих систем. После прочтения ранних вариантов этой книги многие проектировщики ста- ли записывать, какими паттернами они пользуются, а в своей окончательной форме книга побудит к аналогичной работе еще более широкую аудиторию. Хочется верить, что это положит начало движению за документирование опыта практического программирования. В данной главе обсуждается, какое влияние окажут паттерны на развитие проектирования, как они связаны с другими его сторонами и как самостоя- тельно включиться в работу по поиску и каталогизации паттернов. 6.1. Чего ожидать от паттернов проектирования 403 6.1. ЧЕГО ОЖИДАТЬ ОТ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ Вот несколько вариантов того, как паттерны, описанные в книге, могут по- влиять на ваш подход к проектированию объектно-ориентированных про- грамм. Приведенные соображения основаны на нашем опыте повседневной работы с ними. ЕДИНЫЙ СЛОВАРЬ ПРОЕКТИРОВАНИЯ Изучение работы высококвалифицированных программистов, пишущих на традиционных языках, показало, что их знания и опыт основаны не только на синтаксисе языка, но и на более крупных концептуальных структурах, таких как алгоритмы, структуры данных и идиомы [AS85, Cop92, Cur89, SS86], а также планировании шагов по достижению поставленных целей [SE84]. Возможно, они прилагают основные усилия к тому, чтобы найти аналогии текущей задаче в тех планах, алгоритмах, структурах данных и идиомах, которыми они пользовались ранее или о которых было известно. Специалисты в области информатики выбирают имена и каталогизируют алгоритмы и структуры данных, но зачастую мы не заботимся о том, чтобы как-то назвать другие виды паттернов. Паттерны предоставляют проектиров- щикам единую терминологию, которой можно пользоваться для общения, документирования и изучения возможных альтернатив. Система начинает выглядеть менее сложной, поскольку появляется возможность говорить о ней на более высоком уровне абстракции, чем нотация языка проектиро- вания или программирования. После знакомства с паттернами проектирования, описанными в книге, ваш язык проектирования почти наверняка изменится. И вы начнете включать названия паттернов в обсуждения проектов: «Здесь стоит вос- пользоваться “Наблюдателем”» или «А эти классы можно преобразовать в “стратегию”». ПОМОЩЬ ПРИ ДОКУМЕНТИРОВАНИИ И ИЗУЧЕНИИ Знание описанных в книге паттернов проектирования помогает понять су- ществующие объектно-ориентированные системы, в большинстве которых паттерны применяются. Люди, изучающие объектно-ориентированные языки, часто жалуются на то, что наследование в системах используется запутанно, а разобраться в логике передачи управления очень трудно. 404 Глава 6. Заключение Паттерны проектирования также повысят вашу квалификацию как проек- тировщика. Они предоставляют стандартные решения для типичных задач. Если вы достаточно долго проработаете с объектно-ориентированными си- стемами, то, возможно, освоите описываемые здесь паттерны на собственном опыте. Книга существенно ускорит процесс изучения. Отметим также, что знание паттернов поможет начинающему проектировщику работать так, как работает эксперт. Понять систему, которая описана в категориях применяемых в ней паттер- нов проектирования, намного проще. В противном случае для выявления паттернов пришлось бы восстанавливать дизайн по исходным текстам. Наличие единого словаря означает, что вам нет нужды описывать паттерн целиком; достаточно просто назвать его, а читатель поймет, о чем идет речь. Проектировщик, незнакомый с паттернами, должен будет сначала найти информацию о них, но это все равно проще, чем обратное конструирование. Мы постоянно применяем паттерны в своих проектах и считаем их исключи- тельно полезными. Тем не менее, кто-то сочтет, что наши способы примене- ния паттернов слишком просты: мы используем паттерны при выборе имен для классов, как основу для размышлений и обучения хорошему проекти- рованию, а также для описания проектов [BJ94]. Но легко представить себе и более изощренные способы применения паттернов, например основанные на них CASE-средства или гипертекстовые документы. Впрочем, паттерны окажут значительную помощь и без сложных инструментов. ДОПОЛНЕНИЕ СУЩЕСТВУЮЩИХ МЕТОДОВ С помощью объектно-ориентированного проектирования можно создать хороший дизайн, обучить начинающих проектировщиков правильным при- емам работы и стандартизовать методики разработки хороших проектов. Обычно метод проектирования определяет обозначения (как правило, гра- фические) для моделирования различных аспектов проекта, а также набор правил, диктующих, как и когда применять каждое обозначение; зачастую удается описать проблемы, с которыми пришлось столкнуться в ходе рабо- ты над проектом, способы их разрешения и способы оценки полученного результата. Но опыт квалифицированных разработчиков не исчерпывается одними методами проектирования, которые они используют. Думается, что наши паттерны оказываются важным дополнением к методам объектно-ориентированного проектирования. Они показывают, как при- менять такие базовые приемы, как объекты, наследование и полиморфизм, демонстрируют, как можно параметризовать систему алгоритмом, поведением, 6.1. Чего ожидать от паттернов проектирования 405 состоянием или видом объектов, которые предполагается создавать. Паттерны проектирования позволяют не просто зафиксировать результаты решений, а ответить на многочисленные «почему», возникающие в ходе проектирова- ния. Разделы «Применимость», «Результаты» и «Реализация» в описаниях паттернов помогут вам сориентироваться при принятии решения. Паттерны проектирования особенно полезны тогда, когда нужно преобразо- вать аналитическую модель в модель реализации. Вопреки многочисленным заверениям о беспрепятственном переходе от объектно-ориентированного анализа к проектированию, на практике этот процесс никогда не происходит гладко. В гибком проекте, ориентированном на повторное использование, имеются объекты, которых нет в аналитической модели. На проект оказы- вают влияние выбранные язык программирования и библиотеки классов. Аналитические модели часто приходится пересматривать, чтобы обеспечить повторное использование. Многие паттерны, включенные в каталог, непо- средственно связаны с такого рода вопросами, почему мы и называем их паттернами проектирования. Полноценная методика проектирования основывается не только на паттер- нах проектирования. Тут могут быть паттерны и анализа, и пользовательско- го интерфейса, и оптимизации производительности. Но паттерны — очень важная составная часть методики проектирования, которая до сих пор от- сутствовала. ЦЕЛЬ РЕФАКТОРИНГА Повторно используемое программное обеспечение часто приходится под- вергать рефакторингу [OJ90]. Паттерны проектирования помогают вам решить, как именно провести рефакторинг, и могут уменьшить вероятность рефакторинга в будущем. По Брайану Футу (Brian Foote), жизненный цикл объектно-ориентирован- ной программы состоит из трех фаз: прототипизации, экстенсивного роста и консолидации [Foo92]. Фаза прототипизации характеризуется высокой активностью проектиров- щиков, направленной на то, чтобы программа начала работать. При этом быстро создается прототип, который последовательно изменяется до тех пор, пока не будут решены первоначальные задачи. Обычно на данном этапе программа представляет собой набор иерархий классов, отражающих сущ- ности предметной области. Основной вид повторного использования — это принцип «прозрачного ящика» посредством наследования. 406 Глава 6. Заключение После ввода в эксплуатацию развитие программы определяется двумя противоречивыми факторами: (1) программе необходимо отвечать все новым требованиям и (2) одновременно должна повышаться степень ее повторной используемости. Новые требования диктуют необходимость добавления новых классов и операций, быть может, даже целых иерархий классов. Эти требования могут удовлетворяться, когда начинается фаза экстенсивного ро- ста программы. Тем не менее, данный период не может продолжаться долго. В конце концов, программа становится слишком негибкой и не поддается дальнейшим изменениям. Иерархии классов более не соответствуют одной предметной области. Напротив, они отражают множество разных пред- метных областей, а классы определяют совершенно разнородные операции и переменные экземпляров. Чтобы программа могла развиваться и дальше, ее необходимо пересмотреть и реорганизовать; этот процесс и называется рефакторингом. Именно в этот период часто формируются каркасы. При рефакторинге классы, описывающие специализированные и универсальные компоненты, от- деляются друг от друга, операции перемещаются вверх-вниз по иерархии, а интерфейсы классов становятся более рациональными. В фазе консоли- дации появляется много новых объектов, часто в результате декомпози- ции существующих и использования композиции вместо наследования. Таким образом, «прозрачный ящик» заменяется «черным». В связи с не- прекращающимся потоком новых требований и стремлением ко все более высокой степени повторной используемости объектно-ориентированная программа должна вновь и вновь проходить через фазы экстенсивного роста и консолидации. Экстенсивный рост Новые требования Большая степень повторной используемости Прототипирование Консолидация От этого цикла никуда не деться. Но хороший проектировщик предвидит изменения, которые могут потребовать рефакторинга. Он знает, какие структуры классов и объектов позволят избежать рефакторинга, его про- ект устойчив к изменениям требований. Тщательный анализ требований поможет выявить требования, которые с большой вероятностью изменятся 6.2. Краткая история 407 на протяжении жизненного цикла программы, и в хорошем проекте все это учитывается. В наших паттернах проектирования отражены многие структуры, появив- шиеся в результате рефакторинга. Применение паттернов на ранних стадиях проекта часто предотвращает рефакторинг в будущем. Но даже если вы не увидели возможностей для применения паттерна, пока не создали всю систему, паттерн все равно «подскажет» пути ее возможного изменения. 6.2. КРАТКАЯ ИСТОРИЯ Начало этому каталогу положила докторская диссертация Эриха [Gam91, Gam92]. Почти половина всех паттернов была представлена в этой работе. К моменту проведения конференции OOPSLA ’91 диссертацию официаль- но признали независимым каталогом, и для продолжения работы над ним к Эриху присоединился Ричард. Вскоре после этого к компании примкнул и Джон. Незадолго до конференции OOPSLA ’92 в группу влился Ральф. Мы изо всех сил старались, чтобы каталог был готов к публикации в тру- дах ECOOP ’93, но вскоре осознали, что статью на 90 страницах не примут. Поэтому пришлось составить краткий реферат каталога, который и был опубликован. Вскоре после этого мы решили превратить каталог в книгу. Названия, которые мы присваивали паттернам, по ходу дела менялись. «Обертка» (Wrapper) стала декоратором, «клей» (Glue) — фасадом, «холо- стяк» (Solitaire) — одиночкой, «бродяга» (Walker) — посетителем. Парочка паттернов осталась за бортом, поскольку мы не сочли их достаточно важ- ными. Но в остальном набор паттернов в каталоге почти не менялся с конца 1992 г. Однако сами паттерны эволюционировали очень сильно. На самом деле заметить, что нечто представляет собой паттерн, несложно. Мы все четверо активно трудимся над созданием объектно-ориентированных систем и обнаружили, что, когда поработаешь с достаточно большим числом таких систем, выявлять паттерны становится просто. Но найти паттерн куда проще, чем описать его, тем более так, чтобы проектировщики, незнакомые с ним, поняли назначение этого приема и уяснили, почему он важен. Если вы строите системы, а затем размышляете над тем, что было сделано, вы увидите паттерны в результатах своей работы. Но паттерны трудно опи- сать так, чтобы незнакомые с ними люди поняли их и осознали их важность. Специалисты уже на самых ранних стадиях осознали ценность каталога. Но понять паттерны смогли лишь те, кто их уже использовал. 408 Глава 6. Заключение Так как одной из главных целей книги было научить объектно-ориентиро- ванному проектированию, то мы пришли к выводу о необходимости улуч- шить каталог. Увеличили средний объем описания одного паттерна с двух до десяти с лишним страниц, включив подробный раздел «Мотивация» и пример кода. Мы также решили рассматривать различные плюсы и ми- нусы, а также разные способы реализации паттернов. В результате изучать паттерны стало легче. Еще одно важное изменение, внесенное не так давно: задаче, которую призван решить тот или иной паттерн, стало уделяться более пристальное внимание. Проще взглянуть на паттерн как на решение, а не как на прием, который можно приспособить под собственные нужды и повторно использовать. Труднее увидеть, когда паттерн подходит — то есть охарактеризовать те за- дачи, которые он решает, и тот контекст, в котором он является наилучшим вариантом. Проще разглядеть, что делается, чем понять, почему так дела- ется. Понимать назначение паттерна тоже важно, поскольку это помогает определить, какой паттерн стоит применить. Также паттерны помогают по- нять структуру существующих систем. Автор паттерна должен определить и охарактеризовать проблему, которую решает паттерн, даже если он сделает это «задним числом» после обнаружения решения. 6.3. ПРОЕКТИРОВЩИКИ ПАТТЕРНОВ Мы не единственные, кому интересно писать книги, которые содержат каталог паттернов, применяемых специалистами. Мы — часть обширного сообщества, заинтересованного в паттернах вообще и в паттернах, имеющих отношение к программному обеспечению, в частности. Кристофер Алек- сандр — это архитектор, который первым начал изучать паттерны в стро- ительстве и разработал «язык паттернов» для их генерирования. Работа Александра постоянно вдохновляла нас. Поэтому уместно и поучительно сравнить его и наши старания. Затем мы обратимся к работам других авторов по паттернам, связанным с программным обеспечением. ЯЗЫКИ ПАТТЕРНОВ АЛЕКСАНДРА Наша работа напоминает работу Александра во многих отношениях. Обе основаны на изучении существующих систем и нахождении в них пат- тернов. И там, и там есть шаблоны для описания паттернов, хотя и совер- шенно различные. Работы основаны на естественном языке и примерах, 6.3. Проектировщики паттернов 409 а не на формальных языках. В обеих для каждого паттерна приводятся обоснования. Но во многих отношениях наши работы различаются: люди строят здания много тысяч лет, так что существует множество классических примеров. Программные же системы мы начали создавать сравнительно недавно, и лишь немногие признаны классикой; Александр приводит порядок, в котором следует использовать его пат- терны, мы — нет; в паттернах Александра упор сделан на проблемах, в то время как пат- терны проектирования гораздо подробнее описывают решение; Александр утверждает, что его паттерны способны сгенерировать про- ект всего здания. Мы не считаем, что наши паттерны могут создать за- конченную программу. Когда Александр говорит, что можно спроектировать здание, просто приме- няя паттерны один за другим, то он преследует те же цели, что и методисты объектно-ориентированного проектирования, которые приводят пошаго- вые правила. Александр не отрицает творческого подхода; некоторые из его паттернов требуют понимания привычек и обычаев людей, которые будут жить в здании, а его вера в «поэзию» проектирования подразумевает, что уровень проектировщика отнюдь не должен ограничиваться владением языком 1 . Но из его описания того, как паттерны генерируют проект, следу- ет, что язык способен сделать процесс проектирования детерминированным и повторяемым. Точка зрения Александра помогла нам сместить акцент на компромиссы проектирования — различные «силы», которые формируют дизайн. Под влиянием этого человека мы упорно трудились над тем, чтобы понять при- менимость и последствия каждого из наших паттернов. Идеология работы Александра уберегла нас от волнений по поводу формального представления паттернов. Хотя такое представление, возможно, помогло бы автоматизи- ровать паттерны, мы полагаем, что на данном этапе важнее исследовать пространство паттернов проектирования, а не формализовать его. С точки зрения Александра паттерны, описанные в книге, не составляют языка. Принимая во внимание многообразие программных систем, трудно представить себе, как предложить «полный» набор паттернов, из которого можно было бы вывести пошаговые инструкции по созданию приложения. 1 См. «The poetry of the language» [AIS+77]. 410 Глава 6. Заключение Для некоторых классов приложений (скажем, систем генерирования отчетов или ввода данных путем заполнения форм) это возможно. Но наш каталог представляет собой лишь набор взаимосвязанных паттернов, мы не пытаемся выдать его за язык паттернов. Вряд ли когда-либо будет создан полный язык паттернов для проектиро- вания программ. Но, безусловно, можно создать каталог более полный, чем наш. В него можно было бы включить описание каркасов и способов их при- менения [Joh92], паттернов проектирования пользовательского интерфейса [BJ94], паттернов анализа [Coa92] и прочих аспектов разработки программ. Паттерны проектирования — это всего лишь часть более широкого языка паттернов в программном обеспечении. |