Классы

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

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

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

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

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

a = new Object();
ASSetPropFlags(a, null, 0, 1);
for (name in a) trace(name);
На выходе получаем:
__constructor__
constructor
__proto__

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

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

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