Реализация игры на JAVA

Виды, в отличие  от редакторов, не обязательно связаны  с каким-либо конкретным ресурсом. Они  могут быть использованы для отображения  содержимого активного в данный момент редактора (наподобие вида Outline), элемента, выбранного в другом виде (история версий ресурса в CVS), а также данных, полученных любым другим путем (таких, как отчет о выполнении тестов JUnit).

В отличие  от редакторов, изменения, сделанные  пользователем при помощи вида, должны немедленно сохраняются или переносится в соответствующие ресурсы. Например, в виде Navigator отсутствует команда Save или подобная ей – такие действия пользователя, как копирование или переименование, немедленно производятся с соответствующими ресурсами.

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

В Eclipse входит множество элементов пользовательского  интерфейса – редакторов, видов, меню. Если бы кто-то попытался расположить  их все на экране, то в результате получилось бы беспорядочное нагромождение окон, в котором было бы практически невозможно ориентироваться. Создатели Eclipse решили эту проблему при помощи понятия перспективы (perspective).

Очевидно, что  пользователь Eclipse не может одновременно использовать все возможности среды. Когда вы отлаживаете программу, вам не нужны средства для работы с системой контроля версий. Как правило, во время написания кода нет необходимости видеть список установленных точек останова и т.п. Таким образом, в каждый момент времени пользователь выступает в некоторой роли, которая подразумевает ограниченный набор действий.

Перспективой, в терминологии Eclipse, называется конфигурация платформы, соответствующая определенной роли. Функциональность, необходимая  выступающему в этой роли пользователю, определяет набор и расположение окон, меню, горячих клавиш, и прочих элементов интерфейса для этой перспективы. Например, в перспективе для отладки присутствуют виды с текущим стеком, значениями локальных переменных и списком точек останова, а в перспективе для синхронизации содержимого проекта по CVS – виды со списками доступных серверов и историей изменений в выбранного файле.

Platform позволяет  разработчикам приложений создавать  новые перспективы, определять  их конфигурацию по умолчанию  (которая впоследствии может быть  изменена пользователем), а также подключать свои элементы интерфейса к существующим перспективам. Разумеется, поддерживается и добавление новых редакторов и видов.

Графический интерфейс

Фундаментом, на котором построены все графические  средства Eclipse, является входящий в Workbench компонент SWT (Standard widget toolkit). SWT является основным средством создания пользовательского интерфейса для приложений на основе Eclipse. Поскольку для прорисовки элементов интерфейса SWT максимально использует средства оконного менеджера операционной системы (Win32, GTK, Motif), приложения, построенные на базе SWT, визуально не отличаются от “родных” приложений, разработанных специально для конкретной операционной системы. При этом они сохраняют совместимость со всеми платформами, поддерживаемыми Eclipse.

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

SWT (в виде  набора библиотек) может быть использован в качестве замены Swing и AWT, отдельно от Eclipse и компонента Workbench.

До последнего времени основным недостатком SWT было отсутствие визуального редактора  для создания графических интерфейсов  на его основе. Безусловно, разработку кода графического приложения с нуля трудно назвать увлекательной или интеллектуальной задачей. Заполнить этот пробел призван недавно стартовавший проект Eclipse Visual Editor.

На основе SWT построен компонент JFace, который решает более высокоуровневые задачи построения пользовательского интерфейса. JFace содержит классы для создания диалогов, страниц свойств, управления шрифтами, поддержки архитектуры модель/вид и т.п. Наверное, для читателей не будет неожиданным тот факт, что сам Eclipse создан исключительно с использованием SWT и JFace.

JDT

JDT – второй  из основных подпроектов, составляющих Eclipse SDK. Это и есть упомянутая  “IDE для Java”, содержащая инкрементальный  компилятор Java, редакторы, средства  для отладки, тестирования, навигации  и рефакторинга исходного кода.

Важно понимать, что JDT построен исключительно на основе подпроекта Platform и не использует каких-либо закрытых или недокументированных  интерфейсов. Это значит, что при  наличии желания и ресурсов можно  разработать компонент, функционально  аналогичный JDT, для любого другого языка – от С++ до Python, и тем самым превратить Eclipse в, например, “IDE для Python”.

Вы можете полностью исключить JDT из конфигурации Eclipse и установить только свои компоненты, так что пользователям вашего продукта ничто не будет напоминать о Java. Единственный компонент из стандартной конфигурации, который является обязательным для функционирования приложений – это Platform.

Инкрементальная компиляция

Одним из самых  смелых решений, принятых разработчиками Eclipse, была автоматическая инкрементальная  компиляция проекта после каждого  изменения, сделанного разработчиком. Каждый раз, когда, работая в Eclipse, вы сохраняете измененный исходный файл на диске, инкрементальный билдер анализирует сделанные изменения и запускает компиляцию не только сохраненного файла, но и всех зависящих от него компонентов. Этот процесс может показаться неоправданно долгим, однако производительность современных компьютеров делает его практически незаметным для пользователя. Кроме того, интеллектуальный анализ изменений сводит к минимуму число необязательных перекомпиляций. К примеру, если вы сделали изменения в теле метода или отредактировали комментарий, то интерфейс класса остался прежним и перекомпиляция его клиентов не нужна – такие ситуации корректно обрабатываются инкрементальным Java билдером.

Что дает такой  подход, помимо, разумеется, возможности  оперативного просмотра и исправления ошибок компиляции? При первой компиляции проекта в памяти строится дерево зависимостей файлов в проекте, что позволяет в дальнейшем производить компиляцию очень быстро, поскольку нет необходимости анализировать все исходные файлы в проекте. Надо заметить, что дерево зависимостей сохраняется на диске, так что после перезапуска Eclipse нет необходимости проводить анализ зависимостей в проектах с нуля.

Информация, собранная в процессе компиляции проекта, также используется для  выполнения рефакторинга и специализированного Java-поиска (ссылок на декларации, объявления классов и т.п.). Именно доступность этой информации позволяет запускать рефакторинг и поиск без задержек, которые были бы необходимы для ее сбора в случае отсутствия автоматической компиляции. (И рефакторинг, и поиск будут работать и для не откомпилированных проектов, однако в этом случае точность полученных результатов не гарантируется.)

Что можно  сказать о применимости автоматической компиляции для больших проектов – не окажется ли время, затрачиваемое на нее, неприемлемо большим? Как показывает практика, Eclipse позволяет комфортно работать с исходным кодом объемом порядка одного миллиона строк при условии, что он структурирован – разделен на проекты относительно небольшого размера. В случае, когда весь исходный код находится в одном проекте (я рекомендую избегать подобных ситуаций), может оказаться целесообразным отключить автоматическую компиляцию.

Экстремальное программирование и Eclipse

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

Еще одним  приятным свойством JDT, упрощающим применение рекомендаций методики экстремального программирования или Test driven development (TDD), является возможность запуска тестов JUnit прямо из IDE. Какой бы незначительной ни казалась эта деталь, она экономит существенное количество времени в процессе разработки. При работе в традиционной IDE цикл кодирование-модульное тестирование (unit testing) выглядит следующим образом: кодирование, сборка проекта, запуск JUnit, запуск тестов и анализ результатов. В JDT проект всегда находится в откомпилированном виде, поэтому этапы сборки и запуска JUnit пропадают, а выполнение набора тестов становится быстрее и проще. Этого оказывается достаточно для того, чтобы подход с написанием модульных тестов перед собственно кодом приложения начал выглядел намного более привлекательно.

PDE

Последний из подпроектов Eclipse, PDE, обеспечивает поддержку  разработки расширений Eclipse – таких  как плагины, редакторы, виды и страницы настроек. Именно PDE позволяет разрабатывать Eclipse в самом Eclipse.

Плагины

Как было отмечено выше, Eclipse предоставляет широкие  возможности для расширения. В  основе архитектуры, делающей это возможным, лежит использование плагинов (plug-in). Вместо того чтобы находиться в одном монолитном jar-файле, код Eclipse разделен на множество модулей, загружаемых динамически и независимо друг от друга (хотя каждый плагин может указать список плагинов, которые должны быть загружены до него). Для того, чтобы сократить время запуска платформы, плагины загружаются только перед непосредственным использованием (разумеется, полный список установленных плагинов доступен всегда).

Для того, чтобы Eclipse загрузил ваш плагин, необходимо написать дескриптор плагина – файл в формате XML под названием plugin.xml, который можно создать как при помощи PDE, так и в любом текстовом редакторе. Дескриптор сообщает Eclipse, какие ресурсы входят в плагин и каким образом платформа может их использовать. В ресурсы обычно входят библиотеки jar, текстовые сообщения в файлах .properties, графические изображения и т.п.

Разработчики  могут создавать свои плагины, которые  имеют абсолютно равные права  с компонентами, изначально входящими  в Eclipse; фактически приложение Eclipse представляет собой набор плагинов (для удобства конфигурирования группа связанных плагинов может быть объединена в подсистему (feature).

Eclipse поддерживает  концепцию так называемых фрагментов (fragment) плагинов. Фрагменты плагина дополняют основной плагин – они очень похожи на обычные плагины, за исключением того, что не является самостоятельными модулями и могут быть использованы только в комплекте с основным плагином. Eclipse рассматривает плагин и все его обнаруженные фрагменты как единый логический плагин.

Для чего нужны  фрагменты плагинов? Их основным свойством  является возможность установки независимо от основного плагина. Как правило, фрагменты используются для добавления локализованных ресурсов и зависимых от операционной системы компонентов. Если некоторый плагин поддерживает локализацию, вы можете добавить поддержку нового языка при помощи отдельного фрагмента без изменения оригинального плагина и, более того, абсолютно независимо от его разработчиков (разумеется, по мере выхода новых версий плагина вам может понадобится вносить изменения в его фрагменты).

Расширения

Модульная архитектура еще не обеспечивает расширяемости платформы - она всего  лишь обеспечивает механизм загрузки кода, написанного разработчиками. Новая функциональность может быть добавлена в Eclipse с помощью механизма  расширений. Ключевое понятие здесь – точка расширения (extension point). Точка расширения определяет группу сервисов и дает возможность разработчикам плагинов добавлять свои сервисы в общий список.

Каким образом  разработчики могут добавлять в Eclipse, например, свои редакторы? Eclipse, а точнее входящий в компонент Workbench плагин org.eclipse.ui, определяет точку расширения для редакторов. (Как мы помним, именно Workbench определяет пользовательский интерфейс Eclipse.) Основная задача точки расширения – объявить уникальный идентификатор, который будет использован конкретными расширениями для ссылки на точку расширения. Вот как выглядит соответствующий фрагмент дескриптора плагина org.eclipse.ui: