Основания для оптимизма

Отсутствие множественного наследования - это одна из тех вещей, которая сильно раздражает программистов, переходящих с С++ на Java. (Есть еще довольно объемистый список таких вещей. Например, отсутствие перегрузки операторов и типизованных коллекций. А также отсутствие параметров по умолчанию в функциях и т.д.) К счастью, множество недостатков ActionScript первой версии слегка компенсируется тем, что какие-то вещи можно в той или иной степени эмулировать. Например, параметры по умолчанию эмулировать совсем просто:

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

Или можно сделать даже так:

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

Вот и все - параметры по умолчанию готовы. Ранее вы могли видеть, как были эмулированы статические и приватные поля и методы. Так что возможности для эмуляции "всего на свете" интерпретатор ActionScript предоставляет весьма богатые. А это, в свою очередь, дает нам некоторые основания для оптимизма и в задаче об эмуляции множественного наследования.

Переходим к делу

Сразу отметим: авторы осознают, что проекты такого размера, которые требуют полноценного множественного наследования, на Флэш МХ вряд ли будут делаться. Хотя: как знать? Так или иначе, данная лекция является, скорее, демонстрацией возможностей языка ActionScript (а также и ECMA-Script, который, напоминаем, в виде JavaScript используется в браузерах). И хотя полноценное множественное наследование вам, скорее всего, не понадобится, возможно некоторые приемы, которыми мы сейчас воспользуемся, когда-нибудь используете и вы.

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

При этом надо взять в качестве sourceObj не что иное, как sourceClass.prototype; аналогично, в качестве destObj берем destClass.prototype. Более того, видимо, именно так и следует поступить, если все, что вам нужно от одного из базовых классов - это его поля и методы. Совсем другая ситуация возникает, если серьезная инициализационная работа производится в конструкторах, которые в свой черед вызывают базовые конструкторы и т.д. В таком случае цепочку __proto__ "сворачивать", копируя все методы, нельзя. Но возникает другая идея: а нельзя ли скопировать эту цепочку целиком? Скопировать каждую из цепочек (для каждого из базовых классов), а затем составить эти "поезда" друг за другом!

Идея хорошая, но давайте посмотрим, какие трудности нам придется преодолеть в процессе ее реализации.

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

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

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

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

Как это будет работать

Теперь мы приступим к описанию функции multipleInherit, которая сможет решить все вышеописанные проблемы. Эта функция будет принимать следующие аргументы.

1. Функцию, которая будет "прообразом" конструктора для создаваемого класса.
2. Массив базовых классов (причем массив двумерный, о чем речь пойдет далее).
3. Третий аргумент - необязательный. Он представляет собой массив, в котором хранится системный базовый класс (его нужно прикрепить к самой последней субцепочке - без копирования), а также функция вызова его конструктора, передающая туда необходимые аргументы.

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

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

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

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

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

По поводу третьего элемента маленького массива может возникнуть вопрос: где мы, собственно останавливаемся при копировании? То есть включаем в цепочку указанный класс, или же нет? Оказывается, полезными в разных случаях будут оба варианта. Поэтому четвертый элемент маленького массива и будет указывать, как нам поступать: если он равен true, то указанный класс в цепочку включаем, если false - нет.

Проблемы

По ходу дела нам придется преодолеть ряд специфических трудностей. Трудность первая: мы не можем вызывать конструкторы базовых классов напрямую, поскольку это не позволит оборвать цепочку вызовов super() в нужном месте. Поэтому, копируя цепочки __proto__, мы заменяем конструкторы, вызывая из них старые при помощи apply. (И если вам кажется, что это может не сработать, вы правы: с этим связана вторая проблема, более серьезная. Но пойдем по порядку). Так вот, нам нужно сообразить, где хранить ссылки на эти новые конструкторы. Конечно, для этого есть стандартное поле constructor; но если речь идет об "основных" базовых классах, из которых мы и делаем нашего "множественного наследника", то к их новым конструкторам необходимо иметь моментальный доступ из готового конструктора "множественного наследника" (поскольку именно оттуда мы будем их вызывать). Так что для них придется создать отдельный массив.

Трудность вторая, по сравнению с которой первая кажется пустячной: вызывая конструкторы базовых классов как функции, мы делаем это с помощью кода наподобие baseConstr.apply(this, baseArguments). С одной стороны, никакого выбора у нас нет: действительно, базовый конструктор должен подействовать на this и никак иначе. С другой стороны, при вызове super() в базовом конструкторе мы оказываемся в двусмысленной ситуации: ведь super вызывает функцию-конструктор, записанную в __constructor__ у прототипа текущего класса; а текущим классом мы сами указали this, а вовсе не тот базовый, конструктор которого вызывали. Поначалу возникает впечатление, будто бы трудность эта (вызванная тем, что мы пренебрегли системными средствами и вызываем конструкторы "вручную") непреодолима. Затем появляется слабая надежда: записать в this.__proto__. __constructor__ ссылку на ту функцию-конструктор, которая нам нужна, перед вызовом super(). Как ни удивительно, это срабатывает, и мы можем двигаться дальше.

Трудность третья: вызвать конструктор системного базового класса аналогично остальным конструкторам нам не удастся. Это связано именно с тем, что конструкторы большинства системных классов (вроде Array или String) работают немного по-другому, чем обычные функции-конструкторы. В частности, они одновременно являются и функциями-операторами для преобразования типа. Видимо, потому-то сии функции определяют, вызваны ли они через new или непосредственно (в принципе, определить это довольно просто: при вызове из new значение arguments.caller равно null). Так или иначе, вызов конструкторов системных классов через apply не срабатывает корректно. Трудность кажется непреодолимой, однако нас снова выручит искусственный прием. Нужно лишь вспомнить, что наследоваться от системного класса обыкновенным образом вполне возможно. А это значит, что вызов его конструктора через super должен работать (несмотря на то, что arguments.caller при вызове через super выдает уже не null; так что здесь вступают в игру какие-то дополнительные встроенные механизмы). Итак, каким бы образом ни работал вызов конструктора системного базового класса через super, нам нужно воспользоваться именно этим методом. Но ведь настраивать ссылку на "текущий базовый конструктор" мы уже умеем! Так что необходимо сделать следующее. Функция, формирующая аргументы для системного базового класса, должна не возвращать массив с ними, а выполнять вызов наподобие super(arg1, arg2). А перед вызовом этой функции мы установим ссылку this.__proto__.__constructor__ указывающей на системный базовый класс. Вот пример, который подтвердит, что такой пр ием сработает. Выполним следующий код:

Здесь "базовым классом" являются по очереди class1 и Array, а "производными" - class2 и class3. Мы пишем термины "базовый" и "производный" в кавычках, поскольку цепочку __proto__ мы здесь не создаем, а лишь проверяем, как работают разные нестандартные способы вызова базовых конструкторов. При этом конструктор "базового класса" в class2 вызывается при помощи apply, а в class3 - при помощи вспомогательной функции, внутри которой стоит вызов super(). К вспомогательной функции мы здесь прибегаем, чтобы создать "условия, приближенные к боевым", то есть сделать код максимально похожим на тот, что будет использоваться при реализации множественного наследования. Итак, запустив этот код на исполнение, а затем нажав Ctrl+Alt+V (вывод переменных), получим:

Отсюда видно, что при использовании в качестве базового класса созданного нами class1 работают оба способа (вызов и через apply, и через super). А вот для системного класса Array подходит только последний способ.

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

Код вспомогательных функций

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

Для того чтобы посмотреть, что получается в результате работы этой функции копирования, нам придется усовершенствовать функцию dumpObj, которой мы пользовались раньше. В новом варианте рядом с именем функции (поля) будет выводиться комментарий о том, что она является скрытой (если это действительно так). Если функция скрытой не является, комментария не будет никакого. Код новой функции dumpObj таков:

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

Запуск этого примера дает следующий результат:

Проверяем, что мы не испортили скрытие полей и методов.

А теперь раскроем все методы класса Array.

Давайте разберемся, что же мы получили. Во-первых, новая функция dumpObj работает и не портит изначально скрытые объекты. Во-вторых, функция копирования тоже работает аккуратно и копирует с учетом скрытия. В-третьих, поскольку ASSetPropFlags не действует на поля из базовых классов, скрытые функции базовых классов не копируются. Если же их раскрыть (как мы дальше поступили с классом Array), то копируется все. Эту особенность следует учитывать при пользовании функцией копирования. Впрочем, при реализации множественного наследования мы будем ею пользоваться, предварительно "отцепляя цепочку" базовых классов путем установки __proto__ в null. Так что данная тонкость для нас не будет важна.

Код основной функции

Переходим к основной функции множественного наследования multipleInherit. Ее аргументы мы описали ранее; еще раз напомним, что в нее передаются функция-заготовка для конструктора, массив базовых классов (состоящий из субмассивов, каждый из которых содержит всю нужную информацию о конкретном базовом классе) и, если надо, массив с информацией о некопируемом системном базовом классе. Вот код этой функции.

Тестируем основную функцию

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

Для удобства мы разместили тестовые функции в нескольких кадрах, что рекомендуем сделать и вам. Только не забудьте поставить stop(); в ключевом кадре, стоящем после всех тестовых. Итак, кадр с первой тестовой иерархией.

Посмотрим, что выводят в окно Output функции из этого кадра. (Здесь множественное наследование мы еще не использовали. Пока что выясним поподробнее, что представляют собой исходные классы.)

Что же мы видим? До первой двойной черты (напечатанной знаками равенства) - то, что выводят конструкторы в процессе наследования (при создании нового объекта для помещения в prototype). Далее (под чертой) то, что печатают конструкторы (видим, что все базовые конструкторы вызваны с правильными аргументами). Потом - результат работы двух функций "на пробу" (функции печатают то, что и ожидалось). Еще дальше - выводим с помощью trace сам вновь созданный объект (поскольку он унаследован от Array, то и в самом деле, через запятую выводятся значения, переданные в конструктор Array через цепочку вызовов super()). Наконец, еще ниже расположен результат работы функции dumpObj, из которого можно подробно узнать обо всех полях и методах получившегося объекта.

Теперь заведем еще одну иерархию классов. Она аналогична предыдущей, только происходит от класса String и короче. О ней мы уже не будем выводить столь подробные данные. Код, который ее создает, таков:

Конструкторы, вызываемые функции и тестовый trace дают на выходе

Так что все работает, как ожидалось.

А вот дальше начинается то, ради чего, собственно, и написана эта лекция. Дальше мы сделаем два класса, унаследованных от обеих иерархий, причем один совсем простой, а другой - уже с использованием стоп-классов и некопируемого (системного) базового класса. Вот этот код:

Основная часть этого кода (то есть вызовы multipleInherit), как мы уже говорили, создает два класса. Первый из них - совершенно "бесхитростный" наследник классов cn3 и cm2. Конструктор его будет выводить три переданных в него аргумента, разделенных знаком "|". В конструктор cn3 будут передаваться первые два аргумента, а в cm2 - третий аргумент.

Второй из создаваемых классов отличается от первого тремя вещами. Во-первых, порядком следования базовых классов (что влияет на порядок выполнения конструкторов - первыми выполняются конструкторы классов, указанных в самом конце, так как они стоят ближе всего к "корню" цепочки). Во-вторых, при наследовании от cm2 указан стоп-класс cm1 - это значит, что cm1 и его базовые классы не будут включены в цепочку (а сам cm2 - будет). В-третьих, класс Array указан в качестве системного некопируемого класса. При этом указано, что в его конструктор будут переданы все аргументы, с которыми будет вызван конструктор "множественного наследника".

Далее создаются объекты каждого из этих классов, у этих объектов вызывается несколько методов, а также для каждого из вновь созданных объектов вызывается функция dumpObj. В результате в консоль выводится следующая (довольно объемистая) информация.

Что же мы получили на этот раз? Под первой строчкой из звездочек выведен результат работы конструктора класса classDer1. (Напомним, что конструкторы всех его базовых классов устроены так, что прибавляют суффиксы с именем класса к аргументам, передаваемым в super()). Видно, что сначала сработала цепочка вызовов конструкторов базового класса cm2, а потом - цепочка cn3. Затем (после короткой черты) расположено то, что вывели методы объекта od1 (класса classDer1), унаследованные им от различных базовых классов. Результаты работы методов разных базовых классов мы нарочно разделили еще одной короткой чертой. Все методы отработали как положено.

Потом мы попробовали напечатать od1 с помощью trace и обнаружили, что наш "массив" (ведь этот класс был наследован от массива) пуст. (На самом деле, в числе базовых классов был также и класс String. Все дальнейшие рассуждения в этом абзаце относятся к нему в той же мере, что и к Array.) Массив пуст, а ведь при обычном наследовании класс cn3 вел себя не так и массив вовсе не был пустым. Все это связано с тем, что базовый класс Array был скопирован вместе с остальными и его конструктор, так же как и остальные, вызывается через apply (а не через super). А это, как мы ранее выяснили, для системных базовых классов неприемлемо. В принципе, можно было вызывать через super абсолютно все базовые конструкторы, но это было бы не так удобно. Мы не смогли бы передавать аргументы в базовые классы в массиве. Эта возможность особенно ценна, если в базовый класс передаются в точности те же аргументы, что и в производный (что бывает очень часто), и мы можем в качестве функции, формирующей аргументы, передать просто function(){return arguments;}. Итак, если правильный вызов конструктора Array был бы важен для нас, нам следовало бы указать Array в качестве системного базового класса (что и сделано в классе classDer2). А пока будем считать, что для работы класса classDer1 эти тонкости несущественны, потому-то мы о них и не позаботились.

Далее идет дамп полей и методов объекта od1. Из дампа также видно, что полей с именами 0, 1 и т.д., которые должны были бы присутствовать, если бы правильно сработал конструктор Array в созданном нами объекте, нет. Но давайте посмотрим, из чего состоит цепочка __proto__ объекта od1. Объект od1.__proto__ не содержит в себе ничего интересного - это прототип, лежащий в функции-конструкторе, созданной нами при помощи multipleInherit. В него можно было бы поместить специфичные для класса classDer1 методы, но в данном тестовом примере мы этого не делали. А вот далее в цепочке мы увидим плоды нашей работы (точнее, работы функции multipleInherit). Хотя мы и не снабдили классы отладочными полями, в которых были бы указаны их имена, разобраться, с каким именно классом мы имеем дело, можно, взглянув на имена функций - они снабжены соответствующими префиксами. Ит ак, сначала (при движении по направлению к корню цепочки) мы видим классы cn3, cn2 и cn1. Затем идет скопированный класс Array (его тоже можно определить по набору методов). Потом идут классы cm2, cm1 и скопированный класс String. Наконец, самым последним идет Object (он не скопирован, поскольку, если systemBase не указан, в качестве него подразумевается Object).

Дальше идет информация, относящаяся уже к классу classDer2. Мы видим, что, в отличие от classDer1, его содержимое как массива соответствует тому, что мы хотели. Это следует как из результата работы trace, так и из дампа. Подробнее изучая дамп, мы видим, что правильно сработало наследование от cm2 - мы скомандовали не включать классы, начиная с cm1, так и произошло. Далее в цепочке присутствуют cn3, cn2, cn1 и Array, причем Array, в отличие от всех остальных, не скопирован (и конструктор его вызывается через super, а не через apply).

А теперь давайте посмотрим, как с помощью multipleInherit можно реализовать виртуальные базовые классы. Собственно говоря, идея очень простая: класс, который мы хотим объявить виртуальным базовым, мы указываем в качестве стоп-класса для всех базовых классов, у которых в цепочке __proto__ он присутствует. То есть цепочки __proto__ этих классов будут оборваны именно на виртуальном базовом классе. Останется лишь указать этот класс в качестве базового (причем разместить его ближе к концу списка базовых классов - ближе, чем расположены оба его наследника). Вот код, который реализует эту идею:

Этот код должен выводить результаты работы конструктора и дамп объекта od3. Вот они:

До черты из звездочек идут результаты работы конструкторов при создании прототипа класса cx; на них мы не будем обращать внимание. А вот дальше начинаются интересные вещи. Во-первых, мы видим, что конструкторы отработали в правильном порядке. То есть - сначала cn1 и cn2, что соответствует тому, что cn2 является виртуальным базовым классом. Затем - cnx, а потом уже cn3, cm2 и конструктор созданного нами производного класса. Все это вполне соответствует заданному нами расположению классов в цепочке.

Наконец, рассмотрев дамп, мы убедимся, что правильный порядок базовых классов соблюдается и там: двигаясь по направлению к корню цепочки, мы обнаружим классы cm2, cn3, cnx, а затем и cn2, cn1 и Array (причем последний - не скопирован, поскольку указан в аргументах multipleInherit как системный базовый класс; по дампу это, правда, определить нельзя, но можно, например, добавить какой-нибудь метод в системный Array и убедиться, что он сработает и в od3. Разумеется, фокусы наподобие последнего - с модификацией системных классов - лучше делать только в тестовых целях).

Наследование от полученных классов

Давайте убедимся, что полученный в результате использования функции multipleInherit класс пригоден для наследования от него. Пишем следующий код:

Мы самым обычным образом наследовались от класса classDer3, созданного ранее с помощью multipleInherit. Запуск приведенного кода дает следующий результат:

Все, что выведено до первой длинной черты - это результат работы конструктора при наследовании (строчка cd4.prototype = new classDer3()). А вот после нее напечатано то, что выводит конструктор класса cd4 при создании объекта od4. При этом правильным образом отработали конструкторы всех базовых классов (так, как они и должны работать в classDer3). После еще одной черты помещен результат работы оператора trace("od4 = " + od4). Мы видим, что и наследник класса classDer3 ведет себя как наследник массива.

Теперь посмотрим на результаты повторного использования multipleInherit. Добавляем ко всему предыдущему коду еще один кусок:

Запустив все это, получим в консоли следующий новый кусок:

Глядя на все это, мы увидим как вполне ожидавшиеся нами вещи, так и неожиданные. Конечно, мы ожидали получить правильную цепочку __proto__ и мы ее получили. В частности, можно проконтролировать, что в ней присутствуют две копии класса cn1 - одна попала в цепочку из класса cy, а другая - из cd4 (где, в свою очередь она взялась из classDer3, а в нем - из cn2). Также мы видим, что в цепочке ровно один раз присутствует класс Array, причем сам, а не его копия. А вот то, что в массиве, которым является объект odd как наследник Array, имеется пять элементов, а не три - это некоторая неожиданность, хотя и легко объяснимая. Ведь у нас конструктор Array вызван дважды - один раз из конструктора класса classDer3, а второй раз - из самого конструктора classDerDer. Вообще-то это может быть неудобно: получается, что если мы наследуемся от classDer3, мы никак не можем избавиться от первого из вызовов. И, если уж на то пошло, нас может не устраивать наличие нескольких копий одного и того же класса (возможно, с разными аргументами, переданными в конструктор) в цепочке __proto__. Короче говоря, хотелось бы иметь полноценный механизм виртуальных базовых классов и при работе с классами, полученными с multipleInherit.

Однако, есть ли здесь вообще поле для деятельности? Казалось бы, виртуальные базовые классы уже реализованы нами. Тем не менее, есть одна сложность. А именно, в цепочке __proto__ у класса, сформированного при помощи multipleInherit лежат копии базовых классов. Поэтому мы не сможем применить механизм обрыва цепочки, при обнаружении, что текущий копируемый класс равен некоему заданному. Можно было бы, конечно, ссылку на исходный класс сохранить в поле копии, но такое решение повлекло бы за собой ряд проблем. Потребовалось бы сохранять эту ссылку при дальнейшем копировании, неясно, как следовало бы в таком случае поступать с конструкторами классов-"множественных наследников" (которые не рассчитаны на то, что в их цепочке __proto__ будут что-то менять), наконец, проблемы с многократным вызовом конструкторов системных базовых классов остались бы нерешенными. Поэтому мы изберем другой путь.

Многократное множественное наследование и виртуальные базовые классы

Вместо того чтобы сохранять (лишь слегка модифицируя) цепочку __proto__ класса-"множественного наследника", мы сформируем ее заново. Специально для этого мы сохранили массив исходных базовых классов в поле bases, которое завели у конструктора класса-"множественного наследника".

Чтобы воспользоваться этим массивом для нового вызова multipleInherit, нужно научиться добавлять в него (точнее, в его копию) данные о новых виртуальных базовых классах. Это и является основной задачей настоящего параграфа. Ведь добавить данные о невиртуальных базовых классах труда не составит: ничего не надо будет менять в данных остальных базовых классов, порядок следования классов также не важен. Поэтому можно просто собрать данные обо всех новых базовых классах в один массив и воспользоваться методом concat. Но подчеркнем еще раз, что это работает только в том случае, если новые базовые классы не являются виртуальными (или, являясь виртуальными, не встречаются в цепочках __proto__ прежних базовых классов).

Итак, хотелось бы сделать удобные утилиты, которые облегчат процедуру выделения новых виртуальных базовых классов. Что должны делать эти утилиты? Одна из них должна скопировать массив bases (причем, поскольку сам этот массив состоит из субмассивов, эти массивы тоже должны быть скопированы - размещением в скопированный массив ссылок на субмассивы ограничиться нельзя, иначе содержимое исходных субмассивов может быть модифицировано). Другая утилита будет добавлять в скопированный массив один виртуальный базовый класс (для добавления нескольких эту функцию надо будет вызвать повторно). Что конкретно должна делать эта функция? Во-первых, она должна вставить субмассив с данными о новом виртуальном базовом классе в указанное место скопированного массива bases. Во-вторых, в данных о некоторых базовых классах (которые в своей цепочке __protо__ содержат добавляемый класс, который мы хотим сделать виртуальным базовым) надо указать добавляемый класс в качестве стоп-класса. В принципе, эту часть работы можно было бы автоматизировать. Однако это представляется излишним - реальные иерархии классов крайне редко бывают настолько разветвленными, чтобы программисту было сложно указать классы, являющиеся наследниками данного. С другой стороны, явное указание стоп-классов позволяет программисту проконтролировать, что сам виртуальный базовый класс будет помещен ближе к корню результирующей цепочки __proto__, нежели оборванные указанием стоп-класса субцепочки.

Наконец, третья утилита будет получать в качестве аргумента класс-"множественный наследник". Она станет копировать его массив bases, а затем добавлять туда свой прототип (но только то, что добавлено в прототип непосредственно, а цепочка __proto__, прицепленная к нему, в данном случае не нужна, так как все ее содержимое, фактически, уже есть в массиве bases). На самом деле в массив bases кладется, конечно, не сам прототип, а конструктор, к которому прототип прицеплен. Но тут важно, что мы кладем именно исходный конструктор, который когда-то был передан первым аргументом в multipleInherit (и затем сохранен в поле constr нового сгенерированного конструктора). То есть надо достать этот самый constr и установить его prototype указывающим на прототип класса-"множественного наследника". А затем (чтобы цеп очка __proto__ не тянулась за прототипом) в качестве стоп-класса указать сам "множественный наследник" и поставить режим "обрыв цепочки после стоп-класса" (то есть установить четвертый элемент субмассива равным true).

Сейчас мы приведем код, реализующий все эти идеи и тестирующий их пока на строках, а не на классах. Ведь вышеописанным функциям практически все равно, что положить в массив - произвольный класс или строку. (Единственное место, где этот тест не проходит - то, где надо менять prototype у конструктора, записанного в constr. Это место на строках протестировано не будет, о чем есть соответствующие комментарии в коде.) Итак, вот код утилит, о которых мы говорили:

Имея код перед глазами, удобнее более подробно разобрать, какие аргументы передаются в функции. Функция addVirtualBase принимает пять аргументов:

1. sourceArray - исходный массив с информацией о базовых классах (состоящий из субмассивов по четыре элемента - класс, функция формирования аргументов, стоп-класс и режим обрыва цепочки).
2. virtualBaseParams - массив с данными о виртуальном базовом классе (содержит, как обычно, четыре элемента, имеющие тот же смысл, что и элементы субмассивов sourceArray).
3. chainsToStop - массив классов, в данные которых нужно внести добавляемый виртуальный базовый класс в качестве стоп-класса.
4. placeNearClass - класс, перед которым или после которого надо разместить добавляемый виртуальный базовый класс.
5. placeAfter - булевский аргумент, уточняющий смысл предыдущего аргумента. Если он установлен в false (или undefined), то виртуальный базовый класс надо размещать в массиве перед классом, указанным в четвертом аргументе. В результате в цепочке __proto__ "множественного наследника" виртуальный базовый класс расположится дальше от корня цепочки, чем четвертый аргумент. Если же placeAfter установлен в true, то виртуальный базовый класс будет в массиве дальше четвертого аргумента (и ближе к корню в цепочке __proto__).

Возвращает addVirtualBase модифицированную вышеописанным образом копию массива sourceArray.

Функция extractCompleteArrayOfBases принимает два аргумента: sourceClass - класс-"множественный наследник" и newArgFunction - функцию формирования аргументов для конструктора этого класса при вызове его из нового "множественного наследника". Возвращает extractCompleteArrayOfBases копию массива sourceClass.bases с добавленным в него классом sourceClass (на самом деле, для добавления взят исходный конструктор sourceClass.constr, к нему прицеплен правильный прототип sourceClass.prototype, и, кроме того, в качестве стоп-класса установлен также sourceClass.constr, причем обрыв цепочки будет происходить после стоп-класса).

Давайте посмотрим теперь, как все эти функции работают. Вот тестовый код:

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

Добавив этот тестовый код к вышеописанным утилитам и запустив получившуюся программу на выполнение, получим в консоли следующее:

На что нужно обратить внимание в этой распечатке? Во-первых, заметьте, что в исходном массиве четвертый элемент второго субмассива установлен в true. В дальнейшем он будет изменен (в копиях). Далее, смотрим на результаты работы функции addVirtualBase. В первом случае данные для virtualBase были добавлены перед классом thirdBaseClass, во втором (когда аргумент placeAfter был установлен в true) - после. В обоих случаях базовым классам firstBaseClass и secondBaseClass в качестве стоп-класса был установлен virtualBase, а режим обрыва цепочки был установлен в "обрыв перед стоп-классом" - четвертые элементы субмассивов равны false. Последнее можно заметить на примере данных для secondBaseClass, где ранее четвертый элемент субмассива был равен true.

Теперь посмотрим на newTestArray3. При его формировании аргумент placeNearClass был установлен в "aaa", а такого значения первых элементов субмассивов у нас нет. Это эквивалентно тому, что данный аргумент вовсе не был задан. В результате данные virtualBase попали в самый конец массива. Если virtualBase - самодостаточный класс, цепочка __proto__ которого не оборвана указанием стоп-классов (и который, соответственно, не нуждается в том, чтобы ближе к корню новой цепочки "множественного наследника" стояли необходимые для его работы базовые классы) - можно не указывать последние два аргумента при вызове addVirtualBase.

Временно оставив функцию addVirtualBase, посмотрим, как отработала функция extractCompleteArrayOfBases (создавшая в результате extractedArray). Она добавила в начало массива следующий субмассив:

Такой субмассив сообщает, что нужно взять класс, заданный функцией-конструктором TestClassOriginalConstr и оборвать его цепочку __proto__ сразу после него самого (точнее, после его непосредственного прототипа). А именно это нам и надо.

И, наконец, взглянем на то, как работает функция addVirtualBase на массиве, созданном при помощи extractCompleteArrayOfBases. В данном случае важно, что в качестве класса, около которого надо разместить виртуальный базовый, передан как бы "множественный наследник". А ведь функция extractCompleteArrayOfBases вместо "множественного наследника" помещает в возвращаемый массив его исходный конструктор (с подправленным прототипом). Чтобы учесть этот случай, мы поместили в addVirtualBase соответствующую проверку: сравнение идет не только с переданным классом, но и с полем constr, если оно у переданного конструктора найдется. По массиву newTestArray4 видно, что эта мера принесла свои плоды. Массив с данными виртуального базового класса вставлен туда, куда нужно. И стоп-класс для TestClassOriginalConstr заменен (вообще-то последнее имело смысл делать только в тестовых целях, ибо функция extractCompleteArrayOfBases нарочно устанавливает "множественному наследнику" в качестве стоп-класса его же самого - ранее мы обсуждали, зачем это делается).

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

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

Чтобы убедиться, что все в порядке, вспомним, какова последовательность базовых классов в цепочке __proto__ класса classDer3. Эта последовательность выглядит так: classDer3->cm2->cn3->cnx->cn2->cn1->Array->Object (порядок довольно странный, и мы в свое время немало потрудились, чтобы сделать его таким). Как видно из приведенной распечатки, последовательность базовых классов в цепочке класса classDerWithVirt такова: cy->cd4->classDer3->cm2->cn3->cnx->cn2->cn1->Array->Object, при этом класс cn1 мы сделали как бы виртуальным базовым, что проявляется в наличии у него специфических аргументов конструктора, полученных из аргументов, передаваемых в конструктор classDerWithVirt. Аргументы эти приготовлены функцией, специально для этого сделанной нами в последнем тестовом пр имере (и переданной в утилиту addVirtualBase). В самом начале данной распечатки виден результат работы конструктора класса cn1 с этими аргументами: это строка

В качестве базового класса в классах cy и classDer3 класс cn1 не имел подобной функции подготовки аргументов, удваивающей два последних аргумента, да еще и размещающей их в обратном порядке.

Осталось отметить, что нам замечательно удалось не только добавление виртуального базового класса, но и корректное использование класса Array в качестве системного, чего не получалось при простом повторном использовании multipleInherit. Таким образом, созданный с помощью новых утилит класс classDerWithVirt, который, фактически, унаследован от тех же классов, что и classDerDer, получился гораздо более аккуратным и корректным.

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