Классы в ActionScript (в отличие от ActionScript 2) реализованы довольно нестандартным способом. Причина этого в том, что объектная модель первых трех версий ECMAScript ведет свою родословную не от С++, а от языка Self, в котором она, в свою очередь, является развитием конструкций из некоторых вариантов Smalltalk. Это так называемая прототипная модель, которая, как мы увидим дальше, хорошо подходит для интерпретируемых языков и использует те их преимущества, о которых мы уже вкратце говорили. Хорошая расширяемость такой объектной модели позволит нам эмулировать ряд аспектов множественного наследования, которое изначально в ActionScript не было предусмотрено.

Понятие прототипа

Чтобы наиболее наглядно проиллюстрировать, что такое прототип, мы попробуем эмулировать использование прототипа при помощи уже известных нам функций Флэш МХ. Как мы увидим далее, эмулировать можно не все, но достаточно много.

Прототип - обычный объект

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

На выходе получаем:

Лифт работает! Теперь посмотрим, сможем ли мы построить класс на основе этого объекта.

Упрощенное представление - копируем прототип

Наличие класса означает, что мы можем создавать множество независимых друг от друга объектов этого класса. Очевидно, что наивная запись lift2 = lift к добру не приведет - мы получим лишь еще одну ссылку на тот же самый объект. (Можно сказать, что эта запись делает два разных входа в здание с лифтом; однако, войдя через другой вход в дом мы все равно обнаружим лифт на том же самом этаже. Мы же хотим иметь два разных лифта в разных домах.) В самом деле, написав вместо старых операторов тестирования следующие строчки:

получим:

Действительно, мы имеем дело только с одним лифтом - на пятый этаж lift2 поехал не с первого этажа (как было бы, если бы мы в самом деле создали новый лифт) а с третьего.

Таким образом, нам нужно как-то скопировать объект. Вот первый (несовершенный) вариант:

Добавив этот код к коду из предыдущего подпараграфа (и убрав старые "пробные запуски" лифта), получаем на выходе:

Действительно, лифты ездят независимо друг от друга.

Заменяем и дополняем поля и методы

Теперь, когда мы создали новый объект "класса" lift, мы сможем несколько изменить его. Например, заставить ездить на 16 этаж и в подвал. А также издавать звуковой сигнал при закрывании дверей. Вот та часть кода, которая эта делает:

На выходе получаем:

Полное впечатление, что lift2 наследован от lift и в нем переопределена функция управления дверьми. С этой точки зрения каждый объект во Флэше - это класс (поскольку этот объект можно скопировать и наследовать от него другие объекты).

Создание настоящего класса

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

Анализ метода определения класса созданием объекта-прототипа

Что уже есть в созданной нами эмуляции

Итак, мы можем:

1. создавать однотипные объекты
2. менять их свойства и методы

Чего не хватает

Заметим, что в примере про лифт нам пришлось вручную устанавливать параметры нового лифта. То есть объектам нужен конструктор. Затем, чтобы дополнить функцию открывания дверей, нам пришлось копировать старую функцию в другое место. Это неудобно, желателен механизм, при котором подобные вещи делаются автоматически. И вообще, в каждом объекте мы заводим ссылки на (часто идентичные) нужные методы и поля. Хотя это и естественно, оказывается, есть механизмы, позволяющие не затрачивать на это лишнюю память. Наконец, когда мы вплотную приступим к работе с наследованием, нам будут нужны механизмы обращения к базовому классу - его конструктору и прочим методам.

Конструктор

Конструктор как обычная функция

Давайте обеспечим наш класс lift конструктором. Правило, согласно которому имя конструктора должно совпадать с именем класса, выполняется и во Флэше. В результате нам придется как-то избегать конфликта имен между объектом-прототипом и конструктором. Но начнем мы все же с конструктора, а проблемы с конфликтом имен, как мы увидим далее, решатся сами собой. Итак, при написании конструктора нам нужно знать, что это обычная функция, принадлежащая тому же объекту, которому должен принадлежать наш класс. Но при этом ключевое слово this будет обращением к объекту нашего класса, а не к объекту-хозяину. Это обеспечивается специальным механизмом вызова конструктора (в процессе выполнения оператора new, подробнее о котором далее). Приведенных только что сведений достаточно, чтобы написать следующий код:

Как мы уже говорили, конструктор будет вызван при создании объекта нашего класса с помощью оператора new. Но откуда оператор new возьмет прототип?

Конструктор как хранилище прототипа

Еще раз посмотрим, какая задача стоит перед нами. У нас имеется имя класса, оно же имя функции-конструктора. Так что оператор new, зная это имя, легко отыщет конструктор. Нет ли какого-то способа прицепить к конструктору прототип, чтобы не искать прототип отдельно?

Конечно же, есть! Объект функции-конструктора может содержать дополнительные поля, в одно из которых вполне можно положить ссылку на прототип. Именно так все и делается во Флэш МХ. У функции можно завести поле prototype и положить туда ссылку на объект-прототип. В тех случаях, когда функция используется в качестве конструктора (при вызове через оператор new), оператор new в качестве прототипа использует именно тот объект, ссылка на который лежит в поле prototype функции-конструктора. Так что к уже написанному коду, определяющему объект lift, нам надо добавить вот что:

После запуска этого кода получим в консоли:

Можно сделать следующие комментарии по поводу нашей работы. Во-первых, в конструкторе имеется ошибка: он не устанавливает начальный этаж, в результате лифт номер один поехал на четвертый с первого этажа, хотя минимальным является второй. Во-вторых, нам пришлось использовать явное указание на то, что конструктор берется из объекта _global. Иначе нам мешал бы уже имеющийся в _root (в котором был размещен наш код) объект по имени lift. Логично было бы не создавать конфликта имен, а сразу помещать все свойства и методы в prototype, тем более, что пустой объект, в который они будут добавлены, создается автоматически и надпись, аналогичная lift = {}; необязательна.

Методы и свойства в прототипе

В этом подпараграфе мы переработаем наш код с тем, чтобы все нужное для нашего класса было сразу помещено в прототип.

Добавляем методы в прототип

Итак, открываем новый Флэш-файл и пишем там вот что:

На выходе получаем:

Теперь, как видно, мы можем писать не new _global.lift, а просто new lift, поскольку объект по имени lift мы не создавали, а сразу разместили все нужные методы в поле prototype функции-конструктора. Также видно, что переработка конструктора дала свои плоды: лифт номер 1 поехал на четвертый этаж со второго, а не с первого, поскольку ниже второго этажа он спускаться не может.

Нужно ли добавлять поля в прототип

Мы можем добавить в прототип не только методы, но и поля. Те значения, которые мы установим для этих полей в прототипе, будут автоматически скопированы во все экземпляры классов. (Точнее, так будет казаться на первый взгляд, до тех пор, пока мы не разберемся в механизме copy-on-write.) Таким способом имеет смысл устанавливать значения полей по умолчанию или же значения констант. Если же значение поля в любом случае устанавливается в конструкторе, то можно обойтись и без помещения поля в прототип. В случае нашего лифта мы могли бы поместить в прототип поле doorsAreOpen и присвоить ему там значение true. Это соответствовало бы тому факту, что лифты нашей конструкции после монтажа стоят с открытыми дверьми.

Вездесущий this

Фактически, наиболее важные вещи для создания собственных классов мы уже узнали. Теперь самое время еще раз упомянуть об основном источнике ошибок при работе с классами во Флэш-программе. Программист, пишущий на С++ или Java, привык, что внутри метода класса поля этого класса доступны просто по имени. Во Флэше это не так, перед именем поля нужно обязательно ставить this! Иначе Флэш решит, что вы обращаетесь к переменной того объекта, внутри которого написан код определения рассматриваемого метода (в простейшем случае этот объект - _root). Поэтому, если вы написали очевидный код и он не работает, проверьте, чтобы все слова this были на месте. Обычно при такой проверке обнаруживается, что вы забыли поставить вовсе не один, а штук пять this'ов.

Что делает оператор new - попытка эмуляции

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

Оператор new и копирование объектов

Вариант с нерекурсивным копированием

Для того, чтобы обеспечить функциональность, похожую на функциональность настоящего оператора new, нам понадобится вспомогательная функция копирования объектов; сама же функция, эмулирующая оператор new, должна помимо копирования прототипа еще и вызывать конструктор. Так что возьмем код из предыдущего параграфа, но после определения класса lift напишем следующее:

Тестировочные операторы оставляем такими же, как раньше, и убеждаемся, что на выходе получается то же самое:

А это значит, что не только создались наши объекты со всеми нужными методами, но и конструкторы отработали правильно.

(В данном примере был использован вызов метода одного объекта в качестве метода другого при помощи функции apply. Если вы подзабыли детали этого способа - просмотрите еще раз в лекции о функциях конец параграфа про объект arguments. Там же описывается работа функций apply и call. А более подробные примеры их применения вы найдете в лекции о наследовании - в параграфе про вызов функции с явным указанием базового класса.)

Недостатки нерекурсивного варианта. Как скопировать объект

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

Надо заметить, что, совершенствуя функцию newFunc в этом направлении, мы удаляемся от оригинала. Здесь уже пора приоткрыть краешек тайны и сказать о том, что настоящий оператор new вовсе не копирует объекты. Точнее, он делает возможным использование в дальнейшем так называемого механизма copy-on-write, то есть "копирование при записи". Что же касается размножения "вложенных" объектов, то эта задача возлагается на конструктор - и программист сам проследит за созданием новых объектов. Тем не менее, раз уж мы взялись за задачу размножения объектов, давайте доведем ее до конца. Хотя метод создания дочерних объектов в конструкторе наиболее универсален, он все же требует создания соответствующего кода в каждом конкретном конструкторе. В некоторых случаях может оказаться удобным использовать готовую функцию копирования.

Рекурсивный вариант функции копирования

Вот код рекурсивной функции copyObj. Мы проверим его работу в отдельном файле.

Этот пример ничего не выводит в консоль, но, нажав Ctrl+Alt+V (List Variables), мы получим:

Все поля объекта obj1 скопировались в obj2, включая поля вложенного подобъекта; более того, после изменения значения поля подобъекта, на который есть ссылка в obj1, значение поля аналогичного подобъекта в obj2 не изменилось. Отсюда мы можем сделать вывод, что рекурсивная функция копирования действительно работает. Так что теперь в нашей функции newFunc можно заменить вызов copyOneLevelObj на вызов copyObj (приводить результаты проверки нового варианта newFunc в примере с лифтами мы не будем, поскольку лифты не содержат пока ссылок на другие объекты и результат работы примера остается тем же самым).

Обсуждение результатов

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

Во-вторых, не сделано копирование массивов. Копирования ссылки на массив недостаточно, если массив мы собираемся изменять. Хорошо бы определять заранее, что мы имеем дело с массивом, и копировать его при помощи метода slice (заставляя этот метод выдать фрагмент массива размером с целый массив). Копирование массивов также реализовано в примере, рассмотренном в лекции о наследовании (параграф "Наследование от необычных типов", подпараграф "Наследование от функции").

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

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

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

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

Есть изящное решение всех этих проблем. Нужно хранить в самом объекте только те поля и методы, которые изменились по сравнению с прототипом (или вовсе в прототипе отсутствуют). А за всеми прочими методами и полями обращаться прямо в прототип. Но для того, чтобы реализовать это, объект должен иметь возможность каким-то образом связаться с прототипом и "вытащить" из него все, что нужно. А есть ли в объекте ссылка на прототип? Если мы пройдемся по полям объекта в цикле for...in, мы не обнаружим ничего необычного. Тем не менее, в документации написано, что такая ссылка есть и называется она __proto__ (обратите внимание на два подчеркивания с каждой стороны). Почему же for...in ничего не сообщает нам о ней? Дело в том, что эта ссылка, как и ряд других, имеет специальный атрибут, скрывающий ее от итерирования в цикле for...in. Однако нам сейчас важно все подобные ссылки разыскать, и, оказывается, существуют средства для работы и изменения подобных атрибутов ссылок. Средства эти, правда, недокументированные, но воспользоваться ими в исследовательских целях сейчас самое время.

Применение функции ASSetPropFlags для копирования скрытых полей и методов

Функция ASSetPropFlags, о которой сейчас пойдет речь, - это недокументированная функция для работы с атрибутами полей. Эти атрибуты показывают, какие действия с данным полем являются запрещенными. У каждого поля можно установить такие атрибуты. Но для полей, которые создаются обычным образом, ни один подобный атрибут не установлен.

Снимаем и ставим защиту

Глобальная функция ASSetPropFlags имеет четыре параметра. Первый из них - это ссылка на объект, с которым мы будем работать. Второй - список полей, с которыми нужно совершать действия по изменению атрибутов. Этот список может быть представлен в виде массива строк или же в виде одной строки, внутри которой имена полей разделены запятыми. Последнее, кстати, означает, что мы можем передать в качестве второго аргумента строку с именем одного-единственного поля. Наконец, в качестве второго аргумента можно передать null, и тогда указанные нами действия будут производиться со всеми полями объекта. О том, какие же это будут действия, говорят третий и четвертый параметры. В третьем параметре передается информация о том, какие атрибуты нужно установить: атрибут hidden (скрытие от for...in), атрибут protect delete (защита от удаления) или атрибут protect overwrite (защита от перезаписи). Первому из атрибутов соответствует самый младший бит (соответствующий 2⁰, то есть 1), второму - следующий (2¹ = 2), третьему - бит, соответствующий 2² = 4. Прочие биты этого параметра не используются, или, точнее, если и используются, то для внутренних секретных целей Флэш. Нам они не понадобятся. Что же касается четвертого параметра функции, то он полностью аналогичен третьему, но определяет те атрибуты, которые будут стерты у соответствующего поля. Это как раз то, что нам нужно: в дальнейшем мы будем использовать ASSetPropFlags для того, чтобы стирать у различных полей атрибут hidden. А пока что посмотрим на тестовых примерах, как работает установка различных атрибутов. Для того чтобы проверять, установлен или нет какой-либо атрибут, нам придется пойти на некоторые ухищрения: удачное удаление говорит, что не установлена защита от удаления, удачная замена значения сообщает, что нет защиты от перезаписи. Для проверки, установлен ли атрибут hidden мы могли бы попробовать отыскать данное поле при помощи for...in. Но, оказывается, можно обойтись и без этого: существует недокументированная функция isPropertyEnumerable, которая записана в Object.prototype и, таким образом, может быть вызвана в качестве метода любого объекта. Итак, вот обещанный пример:

После запуска этого кода мы получаем в консоли вот какие надписи:

Из нашего примера видно, что при конфликте третьего и четвертого аргумента (то есть при попытке установить и сбросить один и тот же флаг) приоритетом обладает третий.

Что прячется в системных объектах

Теперь, конечно, трудно удержаться от того, чтобы снять флаги hidden со всех полей разнообразных системных объектов и вывести их при помощи for...in. Для начала проделаем это с объектом _global, а также посмотрим, какие методы наследуются во все объекты из Object.prototype. Вот код, который выводит в консоль все интересующие нас сведения.

В результате получаем вот что:

Мы видим, что те методы, которые мы можем найти в каждом объекте, действительно происходят из Object.prototype. Кроме того, мы видим там и несколько недокументированных функций. Огромное число как документированных, так и недокументированных объектов и функций мы находим в объекте _global. В частности, именно там мы видим ссылки на конструкторы самых важных классов, таких, как Number, String, Array, MovieClip и т.д. Даже функция ASSetPropFlags, с помощью которой мы обнаружили все это хозяйство, находится там. Мы не станем здесь подробно описывать поведение каждой их недокументированных функций, ведь эта книга ни в коей мере не является справочником. Тем, кто интересуется подробностями, порекомендуем ресурс http://web.archive.org/web/20040603171453/chattyfig.figleaf.com/flashcoderswiki/index.php?Undocumented+Features (это архивная копия документа с ныне закрытой wiki-конференции flashcoders-wiki). Также можно зайти на сайт FlashGuru http://www.flashguru.co.uk/tutorials.php. По этому адресу расположен список статей, в котором можно найти многие из обнаруженных нами недокументированных вещей. Также можно воспользоваться поиском на сайте Macromedia - многие классы и функции из недокументированных возможностей Flash MX превратились во вполне стандартные свойства системы Flash MX 2004, в описании которой вы сможете с ними познакомиться.

Могущество, но не всемогущество

Казалось бы, мы можем теперь снять защиту с любого метода и переопределить его. На самом деле это не так. Например, мы не сможем переопределить метод trace. Также мы не можем вмешаться в работу некоторых других механизмов, например, в работу механизма ссылок на _parent у MovieClip (правда, можно завести переменную с именем _parent и она скроет, хотя и не переопределит, системную ссылку _parent; удалив эту переменную, мы увидим информацию в системной ссылке _parent в целости и сохранности).

Тем не менее, большинство полей и методов в объектах Flash MX может быть переопределено (в том числе рисовательные методы MovieClip, с которыми мы познакомимся в лекции 10). Причем эти методы можно не только переопределить в производных классах, но и вовсе подменить в прототипе, скажем, MovieClip. Аналогичным образом можно заменять метод toString во всех объектах (меняя метод прямо в прототипе Object). Думаем, не стоит говорить, что пользоваться этими возможностями следует с особой осторожностью. Особенно если фрагментами системы (библиотекой, программными компонентами), написанными вами, будут п ользоваться другие программисты. Ведь они, как правило, будут рассчитывать на то поведение объектов и функций, которое описано в документации по Flash MX, а не на то, которое устроите вы.

Используем полученные знания

Теперь мы можем, наконец, приступить к исследованиям скрытых механизмов реализации наследования и порождения объектов класса. То есть посмотрим, нет ли каких-нибудь скрытых полей, которые отсутствуют в прототипе Object, но имеются у вновь создаваемых объектов. Итак, запустим следующий простенький код.

Поскольку в этот раз мы не раскрывали поля из Object.prototype, то их мы сейчас не видим (более подробное объяснение этого факта мы сможем дать лишь после того, как окончательно разберемся с механизмом наследования). Так что три поля, которые мы сейчас обнаружили, - это скорее всего и есть то, что нужно для создания новых объектов класса. Вскоре мы поймем, что это предположение - верное. А следующий параграф как раз посвящен тому, для чего обнаруженные нами поля нужны и каковы конкретные механизмы их использования.

Механизмы взаимодействия объекта и прототипа

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

Что означают скрытые поля

Поле __proto__

Как мы уже говорили, про это поле написано в документации, так что не нужно считать скрытые от for...in поля чем-то запретным. Итак, в поле __proto__ любого объекта хранится ссылка на прототип того класса, к которому объект принадлежит. Представим себе, что у нас имеется объект неизвестного нам класса. В таком случае нам неизвестен конструктор, и обратиться к прототипу через поле prototype конструктора мы не можем. Так вот, поле __proto__ решает эту пр облему - оно есть в каждом объекте и искать конструктор вовсе не нужно.

Поле constructor

Впрочем, на самом-то деле, имея объект, мы можем добраться и до его конструктора. Не зря же мы обнаружили поле constructor в каждом объекте. Разумеется, именно в нем и записана ссылка на конструктор класса, к которому принадлежит наш объект. Хотя пользоваться этим полем надо с осторожностью - оно недокументированное.

Итак, мы видим, что, имея объект myObject, мы можем обратиться к его прототипу двумя способами: или myObject.__proto__, или myObject.constructor.prototype.

Поле __constructor__

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

На выходе мы получим:

Только в объекте, созданном new обнаружилось поле __constructor__. То есть мы нашли способ выяснить, создан ли объект класса Object с помощью фигурных скобок или с помощью new! Но предназначение поля __constructor__, разумеется, отнюдь не в этом. Предназначено оно для использования при наследовании и вызова конструктора базового класса с помощью ключевого слова super. Собственно, ссылка на базовый конструктор в этом поле и хранится. Но подробнее об этом мы поговорим в следующей лекции.

Механизм copy on write для содержимого прототипа

Мы разобрались, что означают и куда указывают ссылки, создаваемые в объектах оператором new. Но для чего они используются?

Недостатки прямого копирования

Прежде чем ответить на этот вопрос, давайте еще раз вспомним, в чем основные недостатки функции new, которую мы уже реализовали, и почему настоящая функция вряд ли может работать таким образом. Итак, мы уже говорили, что вариант с рекурсивным копированием очевидно избыточен - он тратит слишком много памяти. Как правило, изменяемых подобъектов в реальном объекте немного и каждый из них можно создать в конструкторе явным образом. Более того, нерекурсивное копирование также избыточно, поскольку мы создаем дублирующие ссылки на функции, из которых лишь немногие будут изменены (переопределены). Мы вынуждены производить копирование только потому, что не знаем, какие именно функции потребуется изменить впоследствии. Особенно сильно объекты раздувались бы при наследовании - каждый производный класс добавлял бы свои функции, и все приходилось бы копировать. Наконец, копирование большого объекта требует еще и значительных временных затрат. Но можно ли обойтись без копирования? Оказывается, можно.

Сущность copy on write

Поможет решить нашу проблему механизм, известный под названием copy on write, то есть копирование при записи. В данном случае мы можем трактовать его так: пока мы не пытаемся изменить объект, все значения его полей берутся из прототипа. То есть в объекте не заводится ни одной реальной ссылки. И только если мы захотим изменить значение какого-либо из полей - только тогда это поле действительно заводится в самом объекте. Конечно, это требует поддержки со стороны языка. Алгоритм работы извлечения значения поля мы можем представить себе таким образом: сначала ищем поле в самом объекте, если не находим - обращаемся к прототипу (а если и там нет - к его прототипу и т.д.). Все это мы можем проиллюстрировать следующим кодом:

Запустив этот код, обнаружим в консоли следующее:

То есть наша эмуляция механизма работы __proto__ вполне соответствует реальному положению вещей. (Заметим только, что для аналогичного вызова функций нам надо было бы передать по цепочке ссылку на первоначальный объект и потом сделать apply). Более того, мы видим, что безо всякого использования new, одной только установкой поля __proto__ мы устроили нечто вроде наследования! Впрочем, с подробным анализом открывающихся здесь возможностей мы подождем до следующей лекции.

Как на самом деле работает new

Итак, как мы теперь понимаем, оператор new производит пять операций.

1. Создает новый (пустой) объект.
2. Устанавливает ссылку __proto__, чтобы она указывала на прототип (это и делает объект принадлежащим к данному классу).
3. Устанавливает (недокументированную) ссылку constructor - она будет указывать на конструктор класса.
4. Устанавливает (недокументированную) ссылку __constructor__ - она будет указывать на конструктор базового класса.
5. Вызывает для вновь созданного объекта конструктор и передает ему указанные аргументы.

Исправляем эмуляцию new

А теперь, когда мы знаем детали работы new, мы можем исправить его эмуляцию. Давайте перепишем работу newFunc из последнего примера с лифтами и посмотрим, что получится.

Запустив пример с этой исправленной функцией, получим:

Таким образом, видим, что лифты ездят как надо, хотя мы не скопировали в них ни единого поля из прототипа.

Можно ли создать статическое поле в прототипе

Кое-что похожее на статическое поле создать можно без особых усилий. Во всяком случае, это будет некое хранилище данных, доступных для всех экземпляров класса. Выглядеть это будет так:

Этот код выводит вот что:

Как и следовало ожидать. Однако нужно соблюдать осторожность: если мы попробуем изменить staticField напрямую через объект (например, a.staticField = 10), мы, разумеется, внесем изменения лишь в сам объект, а не в прототип. И другим объектам этого класса изменения будут недоступны. Можно исправить ситуацию, заведя не просто статическое поле, а свойство с функциями доступа. Получается вот что:

На выходе получаем, как и в прошлый раз

К сожалению, недостатки есть и у этого варианта. Вспомним: в С++ и в Java к статической переменной можно обращаться не только через объект, но и через класс. Мы, конечно, можем написать что-то вроде MyClass.prototype.staticField = 10, но... нельзя ли, чтоб было совсем похоже на С++ или Java (особенно на Java)? Без всякого слова prototype? Можно! Добро пожаловать за этим в следующий параграф!

Способы эмуляции статических и приватных полей и методов

Этот параграф может быть пропущен при первом чтении. Заинтересует же он прежде всего тех, кто хочет непременно эмулировать на Флэше любимые элементы семантики Java и C++. А также любителей головоломок.

Статическое поле (свойство)

Усовершенствовать статические поля из предыдущего параграфа можно по двум направлениям:

• Устроить так, чтобы все-таки можно было обращаться к статическому полю только через имя класса.
• Спрятать получше переменную в прототипе, чтобы к ней нельзя было обратиться напрямую. (Это нужно, если ваши getter и setter делают какую-то дополнительную работу, кроме простой выдачи и установки значения; и вы хотите, чтобы весь доступ к свойству шел только через них.)

Вот три варианта кода. Один решает только первую из указанных проблем, второй решает обе (хотя делает он тривиальные getter и setter). Наконец, третий позволяет getter и setter задавать. Во всех вариантах дополнительная функция добавляется в Function.prototype и становится доступной как метод любого объекта-функции (в том числе - конструктора класса). Отметим также, что использованные здесь идеи принадлежат Тимоти Гролео (Timothee Groleau), его прекрасные статьи, упомянутые в списке литературы мы всячески рекомендуем. Итак, сначала самый простой вариант:

На выходе получим:

Так что статическое свойство успешно работает. Теперь давайте скроем данные, к которым обращается свойство, - поместим их не в прототип, а в контекст вызова addStaticProperty. Вот так:

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

Обратите внимание, что getter в данном случае принимает аргумент: значение внутренней переменной, в которой хранятся данные; setter, в отличие от обычного поведения, возвращает значение, которое будет этой внутренней переменной присвоено.

Запускаем код на выполнение и получаем:

Забавный эффект: начальное значение свойства не прошло через функцию-setter и поэтому не приведено к верхнему регистру. Если вы считаете, что подобное поведение провоцирует ошибки (а не "дает некоторую гибкость", например), вы легко можете это исправить, вставив в конце функции addStaticProperty_GS строчку propVal = argSetter(propVal).

Статический метод

Аппетит приходит во время еды; теперь мы можем вспомнить о том, что в C++ и Java бывают также и статические методы. Им разрешен доступ только к статическим полям и методам класса, но вызывать их можно как через класс, так и через объект. Раз уж поля мы сделали статическими, никто не мешает сделать статическими и методы. К статическим свойствам эти методы будут обращаться через класс. Более того, и вызваны эти методы должны быть как методы класса (то есть как если бы они были полями объекта-функции конструктора). Тогда this в этих методах будет указывать на класс, а не на конкретный объект. Иначе статические методы получат доступ и к обычным (не статическим) полям и методам, чего мы как раз хотим избежать. Таким образом, для заводимых в прототипе ссылок на нужные нам статические методы мы должны будем где-то сохранить ссылку на класс (то есть его конструктор). Далее мы будем следовать методике Тимоти Гролео и хранить все нужные вещи в контексте вызова функции addStaticMethod, которая приведена ниже.

Выводит этот код, как и ожидалось,

Вы видите, что к полю someStr у нашего статического метода нет доступа. В то же время статическое свойство testProp ему замечательно видно.

Для более глубокого понимания происходящих здесь вещей попробуйте угадать, что выведет вызов b.printTest() в том случае, когда мы добавим f не с помощью addStaticMethod, а с помощью addStaticProperty. Для того чтобы побольше запутать вас, приведем сначала неправильный способ рассуждений. Он состоит в том, что getter возвращает объект-функцию, который хранится в контексте вызова addStaticProperty. Тогда this указывает на этот контекст, в котором отсутствуют как testProp, так и someStr. Таким образом, вместо их значений мы получим пустоту. Следующая мысль, которая приходит в голову, - это то, что getter, возвращая ссылку на объект-функцию, сохраняет ее в неком временном хранилище, к которому и будет относиться this. (Для сравнения загляните в лекцию 5, параграф "Функция как объект" и еще раз просмотрите пример, иллюстрирующий использование возвращаемых значений типа Function.) Вывод тот же самый - мы увидим пустое место вместо значений строк. Однако запустите наш код, заменив вызов addStaticMethod на addStaticProperty. И вы увидите, что будет выведен, в частности, следующий фрагмент:

Правильное же решение, которое полностью избавляет от всех сомнений, состоит в том, что Flash MX делает поведение свойств максимально похожим на поведение обычных полей. Так что раз уж мы написали b.printTest(), то в функцию printTest в качестве this будет передана именно ссылка на b. А то, что ссылка на printTest хранится где-то в другом месте (не в b) и нам ее возвращает getter - это нас волновать уже не должно.

Изменяемые статические методы

Что делать, если мы хотим изменить поведение статического метода, созданного нами? Простейший способ - снова вызвать addStaticMethod и передать ему в качестве первого аргумента то же самое имя метода, а вот в качестве второго - уже другую функцию. Однако великий и ужасный Тимоти Гролео предлагает другое решение. Это решение хорошо тем, что мы можем просто присваивать свойству, через которое мы доступаемся к нашему статическому методу, любую функцию; главное, чтобы эта функция подразумевала, что this внутри нее - ссылка на класс (то есть конструктор). Такое поведение удобно, особенно если мы передаем объекты с уже созданными там статическими методами в код, уже давно созданный и предполагающий именно такое (стандартное) поведение. Или же этот код будет создаваться другими людьми и нам проще им сказать "все работает как обычно", чем объяснять, что надо всякий раз вызывать addStaticMethod. Итак, новая версия addStaticMethod от Гролео, позволяющая просто присваивать новые статические методы на место старых, вылядит так:

Заменим на этот вариант addStaticMethod из предыдущего примера; и добавим в конце примера следующий проверочный код:

Запускаем все это и получаем:

Итак, setter сработал как надо: сгенерировал новую функцию, которая вызывает g, передавая ей с помощью apply ссылку на объект-функцию конструктора. И далее при работе g эта ссылка используется в качестве this. Таким образом, мы действительно получили доступ к статическому свойству testProp и не получили - к обычному полю объекта b (а именно, к полю someStr).

Создание приватных полей

Как вы, наверное, помните, даже с помощью недокументированных приемов нам не удается полностью скрыть поля (или методы) от воздействия внешних функций. В результате мы не можем быть уверены, что человек, использующий наши классы, не изменит там какое-нибудь поле (а потом все будут долго искать ошибку). Вывод: во многих случаях полезно защитить наши поля от неверного использования извне. Применение контекста вызова как места хранения данных поможет нам и в этом случае. Следуя по стопам Гролео, рассмотрим три различных варианта. Первый вариант: функции getter и setter должны быть вызваны явно. Второй вариант: используем addProperty, getter и setter вызываются неявно при обращении к свойству как к обычному полю. Наконец, третьим будет вариант с перекрестным использованием приватных свойств несколькими различными методами класса. Следует заметить, что для первых двух вариантов будет применен прием, с которым мы встречались в предыдущих параграфах: добавление нужных функций в прототип одного из системных типов (в данном случае - в Object), в результате чего все объекты этого типа смогут использовать добавленные нами методы. Как мы увидим в следующей лекции, эта возможность использования новых методов относится и к объектам производных типов.

Итак, сначала мы рассмотрим, как делаются первые два варианта приватных свойств. Правила для применяемых здесь getter'ов и setter'ов те же, что и при реализации статических свойств: getter принимает аргумент - значение внутреннего поля, в котором хранятся данные; setter возвращает значение, которое нужно этому внутреннему полю присвоить. Вот код, в котором для первого варианта применяется функция addExplicitPrivateProperty, а для второго - addImplicitPrivateProperty:

На выходе этот код дает:

Мы видим, что свойства замечательно работают, но до самих внутренних данных мы добраться не можем даже с помощью функции dumpObj (в случае объекта b свойство testText, которое мы видим - это созданное нами свойство. Это можно распознать по тому факту, что перед текстом выведен префикс "Значение:", то есть сработал getter).

Но как быть, если у нас есть несколько разных свойств, которые мы хотим сделать приватными, но при этом к ним (именно ко внутренним данным) должны иметь доступ несколько различных функций? В этом случае Гролео рекомендует заводить как сами свойства, так и функции, которые будут с ними работать, в контексте вызова конструктора. Сейчас мы приведем пример использования такой техники. Пример будет описывать "шифрованную" строчку. Шифрование применим простейшее - циклическим сдвигом. При этом внутренние данные будут храниться в нешифрованном виде, но наружу они будут выдаваться уже зашифрованными. Также мы сделаем функцию для проверки, правильно ли расшифрована строка. Вот код этого примера:

В результате выполнения этого кода увидим вот что:

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