Автор: Пользователь скрыл имя, 10 Октября 2011 в 15:33, курсовая работа
Игры на Eclipse
Проект Eclipse1
Данная статья представляет собой краткий обзор основных особенностей архитектуры Eclipse SDK. Пользовательский интерфейс Eclipse остается за ее рамками – с его исчерпывающим описанием можно ознакомится в документации, входящей в дистрибутив продукта. Вместо этого читатели получат представление о внутреннем устройство Eclipse, которое может представлять интерес не только для разработчиков приложений на базе этой платформы, но и послужить источником идей для архитекторов больших и нетривиальных проектов.
Что такое Eclipse? Ответ, который первым приходит в голову – “это еще одна IDE для Java”. Однако Eclipse – нечто большее, чем просто IDE, и к тому не ограничен рамками Java. Сами создатели Eclipse называют его платформой для разработки интегрированных приложений. Какой смысл они вкладывают в это понятие?
В настоящее время разработка Eclipse ведется в рамках нескольких проектов. Кратко рассмотрим основные из них – Eclipse и Eclipse Tools. Читатели могут получить полную информацию о проектах, исходные коды и собранные дистрибутивы на сайте http://eclipse.org.
Проект Eclipse включает в себя платформу для разработки приложений, IDE для Java, построенную на ее основе а также средства, необходимые разработчику приложений. Дистрибутив, объединяющий эти компоненты вместе с исходными кодами и пользовательской документацией, называются Eclipse SDK – именно с него рекомендуется начинать знакомство с Eclipse. Eclipse SDK содержит все необходимое для разрабочиков Java: инкрементальный компилятор, редактор Java с подсветкой синтаксиса, контекстным автозавершением и поддержкой шаблонов, отладчик, поддержку автоматического рефакторинга и навигации по исходному коду. Для работы Eclipse SDK необходима JRE (Java runtime environment) версии не ниже 1.4.1 и операционная система Windows 98/ME/2000/XP, Linux, Solaris, AIX, HP-UX или Mac OSX.
В проекте Eclipse Tools собраны приложения, созданные на базе Eclipse, такие как CDT (IDE для С и C++) и EMF (поддержка генерации исходного кода Java для приложений моделирования). Именно тот факт, что все приложения Eclipse используют общие концепции, интерфейсы и технические решения, позволяет говорить об их упомянутой выше интеграции.
Разработка Eclipse началась в апреле 1999 года совместными усилиями компаний OTI и IBM. В октябре 2001 года вышел релиз 1.0, а месяцем позже IBM полностью открыла исходный код Eclipse. Тогда же был образован совет управляющих (Board of Stewards) Eclipse, призванный обеспечить развитие проекта и создать вокруг него сообщество разработчиков. К концу 2002 года в совет входило около тридцати компаний-участников
Тем не менее, поддержку Eclipse со стороны крупных компаний-разработчиков ПО существенно ограничивал тот факт, что весь проект и, самое главное, перспективы его развития, прочно ассоциировались с одной компанией – IBM. Действительно, вклад IBM в создание Eclipse был настолько велик, что весь проект неизбежно воспринимался как ее собственная разработка. Однако главной задачей самой IBM, сделавшей ставку на технологию Java (а не .NET), было добиться широкого распространения качественных продуктов для разработчиков на этой платформе. Чтобы завоевать доверие крупных поставщиков ПО, в начале 2004 года Eclipse был преобразован в некоммерческую ассоциацию, гарантирующую, что все технологии и исходный код Eclipse останутся открытыми и бесплатными.
Eclipse построен в виде набора расширяемых подсистем, а не как единое монолитное приложение. В Eclipse входят три подпроекта, разрабатываемых более или менее независимо друг от друга – Platform, JDT (Java development tools) и PDE (Plug-in development environment). Platform предоставляет базовые сервисы, JDT позволяет разрабатывать приложения Java, а PDE – новые компоненты Eclipse. Далее в статье анализируются основные свойства и внутреннее устройство каждого из подпроектов.
Platform является ядром Eclipse. Сама по себе эта подсистема не содержит особенно полезной для пользователей функциональности, но без нее невозможна работа остальных подпроектов Eclipse. Сервисы, которые обеспечивает Platform, позволяют разработчикам определять видимые пользователю артефакты, создавать пользовательские интерфейсы, работать с системами контроля версий, средами отладки и справочной системой. Соответствующими компонентами Platform, реализующими эти сервисы, являются Workspace (управление контентом), Workbench (базовый пользовательский интерфейс Eclipse), Team, Debug и Help.
Рассмотрим сервисы, реализованные в компоненте Workspace. С концептуальной точки зрения этот компонент определяет основные объекты, с которыми могут работать пользователи и приложения Eclipse, структурирует эти объекты и предоставляет возможность управления ими. В техническом плане основная задача, которую решает этот компонент –унифицированный доступ к локальным и удаленным объектам.
Базовые понятия, определяемые Workspace – это рабочая область (workspace), проект (project), папка (folder) и файл (file). В терминологии Eclipse все эти объекты называются ресурсами (resources).
Рабочая область
всегда существует в единственном экземпляре.
Вы можете переключаться между
Рабочая область – это прежде всего контейнер для проектов. Кроме этого, в ней содержатся настройки, сохраняемые компонентами Eclipse, и вспомогательные данные. Физически рабочая область представляет собой директорию, поддиректории которой соответствуют проектам, а директория .metadata используется как хранилище настроек и данных.
Каждый из проектов, содержащихся в рабочей области, объединяет набор ресурсов (файлов и папок), правил для их обработки и других свойств проекта (таких, как настройки компилятора). Примерами проектов являются приложения Java, библиотеки jar или новые компоненты Eclipse. Для разработки каждого из этих артефактов необходимо создать отдельный проект.
Проекты могут зависеть друг от друга – это значит, что проект A может ссылаться на проект B и использовать ресурсы из него.
Папки и файлы полностью аналогичны папкам и файлам обычных файловых систем. Почему же разработчики Eclipse начали придумывать дополнительные сущности, вместо того, чтобы использовать привычные, известные каждому программисту, объекты? Дело в том, что работа с ресурсами Workspace позволяет программисту использовать множество новых возможностей в дополнение к традиционным свойствам файлов и директорий.
Для ресурсов, представляющих файлы, сохраняется история последних изменений их содержимого. Пользователь, таким образом, имеет возможность просматривать сделанные им изменения, сравнивать между собой различные версии файлов и в любой момент вернуться к одной из них.
Ресурсы могут быть локальными или находиться в репозитории системы контроля версий. В обоих случаях доступ к содержимому ресурсов и управление ими осуществляется через стандартный интерфейс, общий для локальных и удаленных объектов.
Большинство правильно спроектированных приложений Eclipse никогда не обращается к файлам напрямую, используя для этого стандартные средства Java или какие-либо иные способы. Вместо этого доступ к файловой системе осуществляется при помощи интерфейсов Workspace. Впрочем, использование стандартных средств Workspace не является обязательным – если это по какой-либо причине неприемлемо (например, ваше приложение не использует стандартный механизм объединения ресурсов в виде проектов), вполне допустимо использовать альтернативные механизмы.
Перед разработчиками приложений Eclipse часто встает задача отображения сообщений, привязанных к определенному фрагменту в ресурсе. Примерами являются сообщения компилятора Java или закладки (bookmarks), определяемые пользователем для быстрой навигации между файлами. Platform содержит маркеры (markers) – универсальный механизм для работы с такими объектами. Именно маркеры используются для создания, сохранения и отображения сообщений компилятора и пользовательских закладок.
Маркер – это объект, привязанный к заданной позиции в определенном ресурсе, и обладающий несколькими предопределенными и произвольным числом определяемых разработчиком атрибутов. Стандартные атрибуты, такие, как текст сообщения маркера и его позиция в файле, определяют то, как маркер будет отображен платформой Eclipse (а именно, компонентом Workbench). Дополнительные атрибуты могут отражать новую функциональность вашего приложения. Например, атрибуты сообщения об ошибке могут содержать информацию для ее автоматического исправления.
Любой маркер может быть объявлен как сохраняемый (persistent) – такие маркеры автоматически сохраняются платформой и после ее перезапуска будут восстановлены в изначальном виде. Обратной стороной использования сохраняемых маркеров является то, что легко получить множество устаревших маркеров, которые могут запутывать пользователя; при этом у пользователя нет стандартного способа удаления маркеров. Поэтому приложения, использующие сохраняемые маркеры, должны очень аккуратно управлять процессом их создания и удаления.
Очень удобным свойством маркеров является возможность их взаимодействия с текстовыми редакторами. При редактировании файла позиции всех маркеров, определенных в этом файле, корректируются соответствующим образом. Маркеры будут перемещаться вместе с ассоциированными фрагментами текста, поэтому, например, маркеры, созданные средством поиска текстовых строк в файлах, будут корректно указывать на найденные вхождения образца даже после произвольного числа сделанных пользователем изменений.
Каким образом Eclipse будет интерпретировать тот или иной проект, целиком зависит от его свойств. Наиболее важными из поддерживаемых Platform свойств являются типы проектов (project natures) и билдеры (builders).
Билдеры, в самом общем понимании, – это компоненты, обрабатывающие ресурсы, входящие в проект, такие как компилятор Java, преобразующий исходные тексты в бинарные .class файлы. После первоначальной обработки проекта, билдеры должны реагировать на изменения, происходящие в его ресурсах. Очень важным здесь является понятие инкрементальной обработки – для улучшения производительности билдеры должны по возможности обрабатывать только те ресурсы, которые были изменены с момента последнего запуска билдера.
Билдеры, зарегистрированные для проекта, запускаются каждый раз, когда измененный ресурс из этого проекта сохраняется на диске. Логика инкрементальной обработки определяется исключительно разработчиком билдера, поэтому все, что делает Eclipse Platform – вызывает зарегистрированные билдеры при обновлении ресурсов и передает им информацию о произошедших изменениях (какие именно ресурсы были добавлены, удалены или изменены).
Тип проекта (nature) определяет множество билдеров, которые могут работать с ресурсами, входящими в проект. К примеру, с проектом, представляющим собой Java-приложение, должен работать компилятор Java. С одним проектом может работать несколько билдеров – как правило, каждый билдер предназначен для определенного типа файлов. Разработчики приложений Eclipse могут также определять специфические действия для конфигурирования проектов определенного типа.
Компонент Workbench определяет базовый пользовательский интерфейс (UI) Eclipse, а также предоставляет другим компонентам средства для создания своих собственных интерфейсов. Основные объекты интерфейса, с которыми работает Workbench – это редакторы (editors), виды (views) и перспективы (perspectives).
Редакторы в Eclipse вполне соответствуют интуитивному представлению о том, как должен работать редактор. Пользователь может создать экземпляр редактора для существующего файла, внести необходимые изменения, сохранить их и закрыть редактор. Изменения, сделанные в процессе редактирования, остаются в буфере и не записываются в открытый файл до тех пор, пока пользователь не выберет команду сохранения. В редакторе, созданном для одного файла, невозможно открыть какой-либо другой файл.
Назначение редакторов заключается в предоставлении возможности просмотра и редактирования файлов. Визуальное представление содержимого файла зависит от его типа и может меняться от традиционного текстового редактора с подсветкой синтаксиса для сценариев Ant до графического редактора для изображений в формате gif.