НЕМНОГО О СЕДЬМОМ Flash (статья)

[john]

НЕМНОГО О СЕДЬМОМ FLASH

Хочу в одной статье зафиксировать мысли, которые возникли у меня при изучении неких материалов о седьмом Flash.

СРЕДА РАЗРАБОТКИ

С выходом семерки мы будем иметь два редактора Flash: для дизайнеров и для разработчиков.
В редакторе для дизайнеров, можно заниматься только графикой. Дизайнеру не нужно писать код, и он может пользоваться только готовыми решениями, которые будут храниться в специальном меню: «behaviors» (по принципу DreamWeaver)
Редактор для разработчиков(developers), создан уже для других задач и для других товарищей . Он будет включать в себя все возможности «дизайнерской» редакции, но будет основан на «традициях» и наработках сообщества программистов.
Работа с кодом, с компонентами, с библиотекой будет реализована уже на другом уровне. Будут созданы специальные функции для управления проектом и командой разработчиков.
Пока не понятно, каким по счету будет заявленный недавно редактор Royale. Выскажу предположение. Судя по крупицам информации, которая доступна на данный момент, Royale будет еще одним шагом от «визуальной» и «дизайнерской» среды разработки в сторону общепринятых стандартов в профессиональных средах разработки приложений. То есть мы в будущем, возможно, будем иметь три варианта Flash редактора.

РАСШИРЯЕМАЯ СРЕДА РАЗРАБОТКИ

Выполняя пожелания разработчиков значительно упростится работа с рутинными операциями. Запись и воспроизведение макросов, создание собственных инструментов и меню. Создание специальных приложений для упрощение командной работы.
Разработчики смогут как обмениваться своими наработками, так и продавать их.
Для этого разработан специальный язык на основе JavaScript, из которого можно вызвать любую команду Flash редактора, и работать с каждым его объектом.
И если вас что-то не устраивает в вашем Flash-редакторе – перепишите это!

РАБОТА С ПРОЕКТАМИ

С некоторого времени стало очевидным, что разработка во Flash значительно упрощается и упорядочивается, если использовать компоненты. Опыт разработки показывает, что идеология разработки на основе компонентов постепенно превращается в главную и основополагающую стратегию разработки Flash-приложений (Component based strategy). Где каждый элемент приложения – компонент и само приложение – это компонент.
Личное мнение: идеология компонентов очень успешно может быть использована и в графическом дизайне (Component based design).
Очевидно, что в седьмой версии работа с компонентами значительно более развита.
В МХ компонент – это элемент библиотеки. В «семерке» компонент – это внешний, уже скомпилированный файл. Это как значительно убыстряет тестирование и компиляцию всего проекта, так и позволяет разработчиками «скрывать» реализацию своих компонентов. Выскажу предположение, что для новых компонентов будет использован подход из Java.
Не совсем понятно, как будут помещаться компоненты в конечный файл (или у разработчика будет выбор?). Либо код из компонента будет перенесен в конечный SWF? Или же компонент будет находиться «внешне» и будет «становится частью приложения» уже при его инициализации?
Очевидно, что разрабатывать «начинку» для компонентов будут программисты. Как следствие, значительно упрощена работа с компонентами для программистов. Работа с ними станет менее «визуальна», и настраивать параметры компонентов можно будет прямо в коде. Код хранится во внешних файлах, код для работы компонента легко может быть импортирован из другого компонента.

РЕВОЛЮЦИИ В СИНТАКСИСЕ AS

Что называется «допросились». И Макромедия дала нам то, что многие ее просили. «Хотели ООП – получите Java Style OOP». Вот примерно такие чувства вызывает у меня изучение новых возможностей ActionScript.
Пройдемся по главным нововведениям в синтаксисе.
Работа с классами как в Java
Пример, в котором используется синтаксис МХ и Семерки для создания класса:

//*************************************************************************
// шестерка

function ClassName()
{
	// код инициализации
}

ClassName.prototype = new MovieClip();

ClassName.prototype.counter = 12;

ClassName.prototype.method = function()
{
	// код метода
}

//*************************************************************************
// семерка

class ClassName extends MovieClip
{
	var counter = 12;
	
	function ClassName()
	{
		// код инициализации
	}
	
	function method()
	{
		// код метода
	}
}

Как видно из примера в «семерке», работа с классами практически повторяет синтаксис Java.
Отличие только в использовании ключевого слова «function» (сделано думаю для обеспечения преемственности)

Доступ к классам

Нововведения при работе с классами не ограничены только появлением новой конструкцией для их создания. Вторая революция в синтаксисе, заключается в управлении доступа к методам и свойствам класса. Используя спецификаторы public, private и static, мы можем легко разрешить и запретить доступ к нашему классу «извне».
Пример:

class ClassName extends MovieClip
{
	static var counter = 12;
	
	// доступ к методу закрыт "снаружи"
	private function ClassName()
	{
		// код инициализации
	}
	
	// метод доступен "снаружи"
	public function method()
	{
		// код метода
	}
}

Серьезный подход из серьезных языков. Управляя и описывая доступ к классам мы на голову увеличиваем «объектность» наших приложений.

Типы данных

Тот же пример класса, но уже с типами данных:

//*************************************************************************
// семерка

class ClassName extends MovieClip
{
	static var counter:Number = 12;// указыавем тип Number параметру counter
	
	public function method(s:String)// указыавем типа "строка" аргументу s
	{
		trace(s)
	}
}

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

Общие данные для всех экземпляров класса

Почти неизведанные возможности для Flash разработчиков таятся в новом спецификаторе static. Точнее сказать так, подобные возможности можно было реализовать и раньше, но выглядело это так «криво», что почти никто подобным приемом не пользовался.
А все просто и удобно, например мы хотим знать количество всех экземпляра некого класса. И изменяя это поле, новое значение будет доступно всем экземплярам класса.
Два примера реализации одного и того же (в «шестерке» и в «семерке»)

//*************************************************************************
// 6 style
function className()
{
	// при создании экземпляра увеличить счетчик на единицу
	this.__proto__.counter++;
}


className.prototype.getCounter = function()
{
	return counter;
}
//*************************************************************************
// 7 style

class className
{
	static var counter;
	
	function className()
	{
		// при создании экземпляра увеличить счетчик на единицу
		counter++;
	}
	
	function getCounter()
	{
		return counter;
	}
}

Указывая спецификатор static мы гарантируем, то что каждый экземпляр будет «работать» не со своим полем, а общим полем для всего класса.