Flash-класс и проблема с MovieClip - PullRequest
Новая
       3

Flash-класс и проблема с MovieClip

0 голосов
/ 17 декабря 2010

У меня странная проблема.В Flash CS3 IDE я связал MovieClip с классом SubSimba.Этот класс не расширяет MovieClip (его основой является пакет MovieClip), но вместо этого он расширяет SuperSimba (который расширяет MovieClip).Что просходит?Я создаю экземпляр SubSimba в своем проекте Flash, и он ведет себя как я, если я вызову super () внутри конструктора SubSimba: есть ли здесь кто-нибудь, кто понимает, почему?

Ответы [ 2 ]

2 голосов
/ 17 декабря 2010

Это поведение по умолчанию.

Относительно того, почему doThis вызывается как на подкласс, так и на супер.Это связано с тем, что у суперкласса нет виртуального ключевого слова в определении метода.

В классе SuperSimba определение метода doThis () должно быть: 

private virtual function doThis(evt:MouseEvent):void {

Таким образомподкласс будет вызываться только.

1 голос
/ 17 декабря 2010

Я не уверен, правильно ли я понял вопрос, но super () в конструкторах всегда вызывается по умолчанию, даже если вы не указали это явно. Таким образом, во время построения SubSimba (в начале или в конце, я не уверен) будет вызван конструктор SuperSimba.

EDIT:

Чтобы объяснить, о чем мы говорим, в комментарии к этому ответу.

Вы должны понимать, что частные функции нельзя переопределить, и их область действия ограничена только тем классом, в котором вы находитесь сейчас. Так что если у вас в SuperSimba doThis(), а в SubSimba doThis(), то каждый из этих doThis считается отдельной функцией в отдельной области видимости.

Так что если в SubSimba вы делаете addEventListener(SOME_EVENT, doThis);, это будет ссылаться на doThis () SubSimba. Он даже не подозревает, что SuperSimba также имеет функцию doThis, потому что она является приватной и выходит за рамки.

То же самое для SuperSimba. addEventListener(SOME_EVENT, doThis) в SuperSimba фактически ссылается на doThis, объявленный в SuperSimba, потому что он не имеет представления о том, который объявлен в SubSimba (потому что он является личным).

Другими словами, это выглядит так, как будто doThis SuperSimba был совершенно другой поименованной функцией, чем SubSimba. Частная функция доступна только для класса, в котором она проживает, и не для его родителей или детей. Читайте о модификаторах доступа, если вы не уверены.

Учебник: как приватность и наследование с помощью определенных конструкторов могут разозлить вас

У вас есть два класса: 

public class Super{
    public function Super(){ //THIS IS CONSTRUCTOR OF SUPER
        addEventListener(SOME_EVENT, doThis); 

        //This references doThis declared in Super
        //It cannot see doThis declared in Sub because it is both private
        //so it isn't overridden so even if you declare doThis in Sub it 
        //is completely different function
    }
    private function doThis(e:*):void{}
}

public class Sub extends Super{
    public function Super(){ //THIS IS CONSTRUCTOR OF SUB
        //There is this funky thing about flash constructors.
        //Event if you DON'T declare super() it will call it
        //without your knowledge. You can't avoid this really,
        //the only you could try is if (false) super() but I am not
        //sure this will work.

        //So, going further, Super's constructor is also called because
        //Sub extends this class. So by adding this event listener here
        //you end up with two listeners for the same event, like:
        //When SOME_EVENT happens call:
        //    doThis declared in Super,
        //    doThis declared in Sub

        addEventListener(SOME_EVENT, doThis)
    }
    private function doThis(e:*):void{}
}

Таким образом, вы можете попробовать переопределить автоматический супер-вызов, используя if (false) super() или, что более сложно, if (Math.random() > 100) super(), но вполне вероятно, что он не будет работать.

Если вы все еще не понимаете, в чем проблема, прочитайте: http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcd.html и http://www.emanueleferonato.com/2009/08/26/undserstanding-as3-access-modifiers-public-internal-protected-private/

...