С заслуженным инженером, главным Java-архитектором Java-центра в Вашингтоне Джоном Крупи беседует Леонид Черняк

Встреча с Джоном Крупи, одним из трех соавторов книги «Core J2EE Patterns. Best Practice Design Strategies», стала возможной благодаря его приезду в Москву на конференцию по Java-технологиям, организованную представительством Sun Microsystems. Джон сделал несколько докладов общего характера, но его конек — технологии проектирования, поэтому предмет беседы задала книга, написанная им совместно с Дипаком Алюром и Дэном Малксом.

Но прежде несколько слов о переводе названия книги. Во-первых, слово «pattern» настолько многозначно в английском языке, что в своем докладе Джон даже вынужден был сделать специальный комментарий. В качестве иллюстрации того, какой смысл он вкладывает в это слово, Джон избрал слайд, на котором представил выкройку, по которой когда-то женщины шили себе платья. Тем самым он явно хотел подчеркнуть такие значения этого слова, как «образец, модель и пример для подражания», а вовсе не более часто используемое значение «шаблон». Согласитесь, у того, кто изберет для проектируемого объекта некоторый прототип (выкройку) и не будет слепо следовать ему, остается определенная свобода творчества. Напротив, слово «шаблон» предполагает буквальное повторение, тем более, что в русском языке оно имеет явно выраженный негативный оттенок. Прислушайтесь: «шаблонное мышление». Подходят для «pattern» еще и такие варианты перевода, как «система, структура, принцип или модель». Впрочем, остановимся на нейтральном слове «прототипе». Вторая сложность: как перевести словосочетание «best practice»? В современном английском языке это не просто «лучший» или «передовой» опыт, а распространенное идиоматическое выражение, закрепляющее в себе прагматический американский стиль мышления, рациональное стремление использовать опыт предшественников. В итоге получается пусть нескладно, но точно по смыслу: «Суть прототипов в J2EE. Стратегия проектирования, основанная на накопленном положительном опыте».

Джон, уточните, пожалуйста, что же такое «прототип», какой смысл вы вкладываете в это понятие?

Мы с моими коллегами не оригинальны в своей трактовке. За несколько десятилетий сложилось общепринятое представление о прототипах в проектировании, причем оно родилось вне программирования и, следовательно, не ограничено рамками проектирования программного обеспечения. Родоначальником идеологии использования прототипов в проектировании как средства передачи знаний стал в 70-е годы Кристофер Александер. Он написал несколько книг, в которых задокументировал ряд образцовых решений в строительстве и архитектуре, с тем, чтобы их положительный опыт мог быть использован другими. Позже эту идею стало активно перенимать сообщество разработчиков программного обеспечения, хотя, конечно же, в неназванном, или неоформленном, виде она присутствовала всегда. Главным импульсом к распространению методов проектирования программного обеспечения с использованием прототипов стала книга «Прототипы проектирования, элементы повторно используемого объектно-ориентированного программного обеспечения», авторство которой принадлежит, как их часто называют, «банде четырех» (Gang of Four, GoF) в составе Эрика Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влисидеса. Они проделали весьма нужную и актуальную работу. Не изобретая ничего самостоятельно, члены «банды» собрали удачные проектные решения и документально их оформили. С тех пор вышел еще целый ряд книг по технологии программирования с использованием прототипов; они различаются областями приложения и функциональным назначением, но в отношении того, что такое прототип, все авторы солидарны.

Существует несколько близких определений того, что такое прототип. Самому Кристоферу Александеру принадлежит следующее определение: «Каждый прототип представляет собой правило, состоящее из трех составляющих, которые выражают отношения контекста, проблемы и решения». Есть более общее определение, по Мартину Фоулеру: «Прототип есть идея, которая однажды была практически реализована и, вероятно, может быть использована в будущем».

Джон, насколько мне известно, прототипирование не стало массовым в нашей стране. Думаю, здесь обнаруживается расхождение в менталитете, системе образования: мы все хотим делать сами и с самого начала, хотя это не всегда рационально. Попытаюсь дать сказанному вами более близкую мне трактовку. В конечном счете, получается, что прототип есть ни что иное, как формализация накопленного инженерного знания. Годами в отсутствие такого механизма передача инженерного опыта и знаний выполнялась на интуитивном уровне. Когда-то перед группой молодых специалистов большого предприятия, где я работал, однажды выступил Давид Борисович Юдин, замечательный математик, специалист по линейному программированию и один из самых образованных людей из тех, с кем мне довелось быть знакомым. Он сказал: «Молодые люди, учеными из вас станут единицы, большинство будет инженерами, а на этом пути для вас самым главным является накопление опыта; для инженера главное — опыт». Жизнь подтвердила справедливость этих слов. Это было почти тридцать лет назад, с тех пор забыто очень многое, но эти наставления не стерлись из памяти, потому что на самом деле инженер состоит на 95% из опыта и только на 5% — из академических знаний. И еще одно соображение, в подтверждение тому, что вы говорите. Очень многие испытывали интуитивную потребность в том, что вы называете прототипом, и осуществляли наивные попытки реализовать нечто подобное. В годы, о которых я говорил, в той лаборатории, где пришлось работать, программировали в основном на языке Ассемблера, который сами же и реализовали, назвав его ЯМБП («язык макро блочного программирования»). Этот ЯМБП позволял обмениваться наработками внутри небольшого коллектива и не повторять пути, уже пройденного другими. У нас даже была своя библиотека прототипов, но о ее существовании никто не задумывался. Полагаю, что нашим специалистам стоит немного перестроить свое сознание.

Я согласен с вами. Особенно теоретизировать в этой области не стоит, иначе легко скатиться в демагогию, такова специфика предмета. Существуют более серьезные попытки определения и классификации прототипов, но обычно они внутренне противоречивы, поэтому, составляя каталог прототипов J2EE для своей последней книги, мы постарались отказаться от всякой надуманности и распределили их всего по трем очевидным уровням: представление; бизнес; интеграция.

Такая структура каталога делает его открытым и легко пополняемым. Мы стремились сохранить простоту и не вводить лишних псевдонаучных понятий и терминов. Наши прототипы — не плод досужих измышлений. Они появились в Java-центре компании Sun Microsystems в результате обобщения опыта работы с клиентами, использующими платформу J2EE. Этот центр является частью подразделения Sun Professional Services и консультирует тех, кто строит решения на базе Java-технологий. Мы одними из первых начали работать с J2EE, и на протяжении нескольких лет копили свой опыт в неформализованном виде. В какой-то момент объем знаний достиг достаточного уровня, когда уже можно и нужно было строить шаблоны, полезные нашим клиентам. Но прежде необходимо было выполнить сортировку и отбор того, что достойно быть представлено в виде прототипов. Наибольшая сложность заключалась в фильтрации и выделении непересекающихся между собой прототипов. Тот же Кристофер Александер в своей книге «Язык прототипов» писал, что ни один прототип не может существовать как изолированная сущность, он существует в той своей части, которая поддерживается другими прототипами. Он может быть встроен в прототип большего размера, поддерживать горизонтальную связь с прототипами того же размера или же содержать в себе меньшие прототипы. Поэтому наша книга — это не просто каталог, мы описываем то, как каждый из прототипов поддерживается другими или сам поддерживает других. В ряде случаев мы используем прототипы, описанные другими авторами.

Хочу подчеркнуть, что мы не только предлагаем образцы хорошего и полезного опыта. Мы считаем, что стоит учиться на чужих ошибках, поэтому в предшествующих собственно каталогу главах пишем и о «плохом опыте» (bad practice). Кроме того, мы предлагаем переход от плохого опыта к хорошему; мы назвали этот процесс refactoring, т.е. нечто вроде придания нового качества.

На обложку своей книги вы вынесли слова Джона Влисидеса, одного из членов «банды четырех»: «Ландшафт Java замусорен множеством библиотек, инструментов и спецификаций. При этом всегда недоставало того, что могло бы сплавить все их вместе в конкретное решение для реального мира. Прототипы — вот строительный раствор, скрепляющий конструкцию J2EE». Поэтому несколько слов о прототипах в контексте J2EE.

J2EE стандартизует целый ряд технологий, обеспечивая надежную платформу для построения распределенных многоуровневых приложений корпоративного класса. Для программиста, знакомого со стандартным изданием J2SE, изучение этой технологии вовсе не сложно. Но мы убеждены в том, что просто изучение технологии самой по себе не может побудить нас к проектированию систем на ее основе. Мы считаем, что параллельно с изучением самой технологии необходимо давать примеры того, как эта технология используется в практике проектирования. Прототипы и есть тот необходимый инструмент, который осуществляет аккумулирование и перенос знаний. Использование прототипов избавляет от хронического синдрома «изобретения колеса».

На первый взгляд все, что вы, Джон, говорите, выглядит чрезвычайно убедительным. Тем не менее, могли бы вы более конкретно пояснить, в чем состоят практические преимущества, которые получит пользователь, если будет пользоваться прототипами J2EE?

Описанные в книге прототипы можно — и это разумнее всего — использовать на начальном этапе проектирования системы. Но на практике к ним можно обратиться на любом этапе жизненного цикла проекта, для чего и служит специфическое преобразование, получившее название refactoring. Я должен предупредить, что работа с прототипами сложнее, чем может показаться на первый взгляд; иногда возникает парадоксальная ситуация, когда оказывается легче использовать прототип, чем понять его. Еще сложнее процесс представления образцов хорошего опыта. Во-первых, очень сложным является процесс селекции, во-вторых, необходимо описать отобранное и выразить словами. Отвечая на ваш вопрос точнее, можно назвать три категории преимуществ.

Опора на проверенное решение. Документированный прототип основан на решении, которое неоднократно использовалось при решении аналогичных задач, но в другое время и в других процессах.

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

Ограничение пространства решений. Прототипы строго очерчивают границу допустимого для разработчика; это только на первый взгляд является ограничением для возможностей его творчества, на самом же деле они скорее лимитируют ему выход в пространство ошибочных решений.

Я вновь апеллирую к своему личному опыту. Языки высокого уровня начались с Фортрана и Алгола. Тогда они назывались алгоритмическими и использовались для программирования, а точнее, для решения задач вычислительного характера, где особого опыта не требовалось. В наибольшей степени это относится к Алголу. При достаточной математической подготовке достаточно было внимательно изучить формальное описание синтаксиса, выполненное в нотации Бэкуса-Наура, после чего вполне можно было приступать к программированию. Фортрану немного стоило поучиться, была даже книга, называвшаяся «Книга для чтения по Фортрану», автор, кажется, Ламуатье. Можно сказать, что в ней тоже предлагались шаблоны программирования. Однако Фортран и Алгол были языками для решения вычислительных задач научного характера или близких к науке. Людей, способных программировать на них, требовалось немного, и практически никто толком их не учил. Сейчас обстановка совершенно иная; необходимо создавать большие системы, притом силами программистов весьма средней квалификации. Программирование становится в большей степени инженерной или даже технической работой. Мне известны прецеденты, когда профессионально программировать на Java начинают перевалившие за сорокалетний рубеж люди, пройдя полугодичное обучение. Java вообще и прототипы в частности — это путь к стандартизации и упрощению программирования за счет лучшей организации технологического процесса, не так ли?

Я не застал в своей профессиональной жизни ни Фортрана, ни Алгола. Я начинал программировать позже и много писал на Си и Си++. На основании своего опыта могу сказать, что полгода — это все же самый минимальный срок. Для того чтобы стать хорошим программистом на Java, нужно проработать на нем не менее года. Но если работать на Си, то на достижение того же квалификационного уровня уйдет три года как минимум.

Простота освоения — вот одна из причин повального увлечения языком Java. Произошло глобальное принятие Java, но в том, как именно это случилось, есть какая-то фатальность. Ведь начиналось все довольно скромно, с поддержки графики в Web-браузерах, однако затем пришло осознание того, что Java освобождает от тех сложностей, которыми нагружен программист, работающий, скажем, на Си++. Это покорило сообщество разработчиков, и Java завоевал корпоративное пространство. Возможно, это стало неожиданностью даже для его авторов, ведь никто из тех, кто разрабатывал предшествовавшие Java проекты в начале 90-х годов, а затем и сам язык, не имел никакого отношения к корпоративным системам. Сообщество бы никогда не приняло Java, если бы этот язык не избавил его от необходимости выполнения рутинных задач, таких, например, как сборка мусора. Кроме того, Java позволяет начать проектирование на более высоком уровне абстракции, чем Си или Си++.

В итоге можно говорить о трех факторах: простота освоения, удобство работы, лучшая приспособленность к задачам проектирования. Они способствуют тому, что число программирующих на Java разработчиков огромно, оно исчисляется миллионами. Только в Соединенных Штатах их так много, что востребованы новые формы организации массовой технологии. Массовость и создала спрос на технологии, которым посвящена наша книга, предлагающая каталог прототипов. Нас как авторов радует, что книга востребована, лидирует сегодня по продажам среди изданий Prentice Hall.

Общие характеристики прототипов по Джону Крупи

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