дублер каскадера

АЛЕКСАНДР ГЛАДЫШ

Спецвыпуск: Хакер, номер #071, стр. 071-068-1

ВЕДУЩИЙ ПРОГРАММИСТ КОМПАНИИ «STEP CREATIVE GROUP» (WWW.STEPGAMES.RU)

АЛЬТЕРНАТИВА XML

ПРОБЛЕМА ОПИСАНИЯ ДАННЫХ СТОИТ ПЕРЕД СОЗДАТЕЛЕМ ПРАКТИЧЕСКИ ЛЮБОГО ПРИЛОЖЕНИЯ. ВНЕ ЗАВИСИМОСТИ ОТ ТОГО, КАКОВА ПРИРОДА ДАННЫХ. ВНЕ ЗАВИСИМОСТИ ОТ ТОГО, ДОЛЖНО ЛИ ПРИЛОЖЕНИЕ ИХ СОЗДАВАТЬ И ИЗМЕНЯТЬ ИЛИ ДАННЫЕ ИСПОЛЬЗУЮТСЯ ТОЛЬКО ДЛЯ ЧТЕНИЯ, ПЕРЕДАЮТСЯ ДАННЫЕ ПО СЕТИ ИЛИ СУЩЕСТВУЮТ НА ЖЕСТКОМ ДИСКЕ, ОНИ ДОЛЖНЫ ХРАНИТЬСЯ В ДОСТАТОЧНО УДОБНОМ ФОРМАТЕ

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

Для удобства использования немаловажен объем имеющихся наработок по данному формату – наличие сторонних и собственных библиотек, средств перевода «живых» объектов логики приложения в сохраненные данные и обратно (сериализации, от английского serialization) и прочее. Такие средства могут предоставлять разную степень интеграции с логикой программы – от API для создания, сохранения, загрузки и модификации «голых» данных до инструментария тесной интеграции, позволяющего сериализовать объекты логики без написания промежуточного кода работы с форматом данных.

В отличие от данных, для хранения которых существуют устоявшиеся форматы (например, видео — AVI, WMV, музыка — MP3, OGG, документы — DOC, PDF), для данных, специфичных для логики конкретного приложения, в общем случае разработчик должен создать формат хранения самостоятельно (хотя некоторые средства разработки и языки программирования упрощают этот процесс вплоть до полной автоматизации). При этом зачастую одному приложению требуется несколько различных форматов хранения для разных наборов данных.

Как и всегда, разработка формата хранения данных с нуля чревата многими проблемами. Поскольку сериализация объектов логики обычно не предъявляет экстремальных требований к эффективности по скорости и объемам данных, лучше использовать одно из обобщенных решений – создать конкретный формат при помощи некоего готового «метаформата» и связанного с ним набора технологий.

[существующие решения.]

Самое распространенное на данный момент «обобщенное» решение – использование языка XML. Вокруг этого языка существует огромная развитая как в плане технологий, так и в плане инструментария инфраструктура. Широчайшая распространенность и связанные с этим бонусы – главное преимущество XML.

Однако у XML существует ряд недостатков. Основной из них – избыточность, увеличивающая объем, занимаемый данными, замедляющая процесс чтения и записи данных и усложняющая их ручное редактирование. Эта избыточность усугубляется тем, что XML – сугубо текстовый формат (впрочем, имеется несколько нестандартизованных вариантов Binary XML).

Помимо XML, в динамических языках (Python, Ruby и т.д.) получила распространение технология YAML (www.yaml.org). В языках программирования, ориентированных на веб-разработку, нередко используется JSON (JavaScript Ob-ject Notation, www.json.org). Обширный список альтернатив XML можно изучить по адресу www.pault.com/pault/pxml/xmlalternatives.html.