Ссылка на экземляр класса

[Wazzabi]

Доброе время суток!

AS3,0 начал изучать не так давно поэтому сильно прошу не ругать.
Вопрос стоит в следующем..
В классе Main создается экземпляры классов Scene и Interface. Каждый класс (Scene и Interface) находятся в разных пакетах. В классе Interface создается кнопка. При нажатии кнопочки Scene Должен сдвигаться на -50 пикселей. Для этого создал в классе Scene публичный метод moveScene. Но из класса Interface не могу вызвать этот метод (moveScene).
Как в классе Interface получить ссылку на уже созданный экземляр класса Scene?

[ЗлОй ПрОграММер]

Когда создаёте класс Interface в конструкторе передавайте ссылку на нужный экземпляр

public var instance: Object;
public function Interface(instance: Object): void //конструктор
{
  this.instance = instance;
}

хотя не факт, что данная архитектура самая верная, просто вам как вариант для рассмотрения

[RhPlus]

Создайте экземпляр класса. Затем обратитесь к экземпляру с помощью оператора "точка" и выберите нужный метод. Если метод статический, то не нужно создавать экземпляр класса, так как метод будет методом класса, а не экземпляра. Обратитесь к классу с помощью оператора "точка" и выберите нужный метод. Статические методы не наследуются.

[Wolsh]

Сам подход плох и лучше сразу не прививать себе таких привычек.
Классы одного уровня иерархии не должны управлять друг другом.
Объекты не должны сами менять свое положение во внешнем мире.
Положением своих "детей" должен управлять контейнер. Если объект сам, своими "мозгами" рещает, в каких координатах ему находиться, он неизбежно будет конфликтовать с задумкой, если его поместить в другой контейнер, или создать два экземпляра в одном контейнере (они будут стремиться попасть на одно место, то есть перекрывать друг друга)). Координаты объекта в системе координат контейнера – это не "личное" свойство объекта, это его "общественное" свойство, и задаваться должно тем, кто владеет информацией об остальных членах общества, то есть контейнером или каким-то менеджером, лейаутом.

[Wazzabi]

ЗлОй ПрОграММер, ваш вариант помог. Большое спасибо.


Wolsh, хм.... не совсем понял, можно примерчик или ссылочку?
Всем большое спасибо за быстрый ответ!

[Wolsh]

Примерчик?)) Да не, речь об общем подходе, о проектировании или архитектуре.
У Вас сейчас так: есть папа, который создает два ребенка. И в какой-то момент один из ребенков начинает приказывать другому ребенку. В программировании надо стараться не допускать такого. Приказывать что-то должен родитель, дети могут только слушаться родителей и сообщать им о каких-то изменениях своего состояния или своих "желаниях".
На вашем примере класс Interface (как Вы догадались назвать класс базовым термином языка, к тому же означающим нечто совсем другое, нежели класс?))) должен послать папе-Mainу событие "у меня тут такую-то кнопку нажали", а Main (если ничто в его видении происходящего не противоречит этому) совершить действие по изменению координат Scene. Потому что экземпляр Scene - его ребенок, и находится в его системе координат, и только папа-Main вправе решать, где ему в этой системе находиться. Кроме того, становится странным и непонятным метод у Scene для его перемещения. Ну, разве что он перемещается каким-то хитроумным способом, но и это не отмазка. Не может рыбка в аквариуме двигаться, как ей придет в голову. Она будет врезаться в водоросли, других рыбок и пластиковые домики. ее движением должен управлять тот, кто знает положение этих объектов одной с рыбкой иерархии. Их положение знает контейнер. Это, естественно, общий принцип, который может не учитываться в каких-то простейших случаях; но на практике простейшее всегда вырастает в более сложное, и начинается перекраивание проекта. В Вашем случае перекраивание коснется сразу всех классов, поэтому я и рекомендую учиться сразу делать хорошо. Не засовывать в объекты ненужную функциональность и избыточную ответственность. Рыбка не должна знать все об аквариуме и его обитателях. Это очень избыточно. Достаточно того, что аквариум знает все о рыбке, других рыбках, и водорослях.

[Wazzabi]

Wolsh, спасибо за разъяснения.
Класс Interface был переименован.
Теперь я все никак не могу добиться такой иерархии, о которой вы говорите. Мне все хочется чтоб кнопки для управления находились в отдельном классе. В таком варианте у меня все равно получается так, что Ребенок управляет Ребенком....
Может мне все кнопки управления создать в Классе Scene и в нем же уже создать объект класса, например ImаgesLayot. И уже методами класса Scene управлять прорисовкой в классе ImagesLayot?

И исходников для FlashDevelop я не нашел, чтоб разобраться в этом вопросе

[Wolsh]

Ну например. Делаете Вы простенький слайдер типа такого:

Сам класс компонента назовем Slider. У него будет два ребенка – HUD (head-up display) с кнопочками и Screen – контейнер картинок.
При создании экземпляра компонента мы даем ему в конструктор желаемую ширину и набор картинок (допустим массив уже загруженных картинок). Slider создает детишек – интерфейс требуемой ширины и контейнер для картинок требуемой ширины. Класс Screen получает также набор картинок и пакует их, подгоняя под свою высоту и расставляя в ленту под маской. Это его ответственность – составить ленту из картинок и уметь ее плавно двигать. Ответственность класса HUD – нарисовать интерфейс требуемой ширины, в данном случае создать две кнопочки и расположить их на заданном расстоянии; а также – ловить действия пользователя и сообщать папе-Слайдеру об этих действиях. В реальности, конечно, в таком простом примере кнопочки можно было бы создать в самом Слайдере. Но допустим, что наш компонент в будущем хочет поддерживать плагинские интерфейсы, загружаемые извне, с другими кнопочками или не кнопочками вовсе.
Тогда нам надо абстрагироваться от кнопочек и положиться на некий абстрактный интерфейс пользователя, который сообщает не о действиях с какими-то своими элементами (о которых его папе лучше не знать)), а о намерениях пользователя. То есть, что "пользователь хочет сместить ленту картинок вправо следующую/предыдущую картинку".
Как именно пользователь изъявил свое желание – этим занимается сам интерфейс. Это могут быть нажатия на кнопочки, а в другом плагине – вращение колесика мышки или наведение курсора на области "пролистывания". Это все личные отношения пользователя и интерфейса, который "переводит" действия пользователя на язык возможностей Слайдера. Слайдер может только листать коллекцию картинок. Поэтому интерфейс (класс HUD) может посылать два вида Событий – HUD.NEXT и HUD.PREV. Папа-Slider на эти события (сообщения от своего ребенка) и подписывается, а в обработчиках этих событий вызывает методы класса Screen – next() и prev(). Точно также – как именно будет осуществлен в Screen переход к следующей картинке это личное дело самого Screen: если это лента, то она смещается, а если колода, то следующая/предыдущая картинка кладется наверх, если карусель – осуществляется поворот карусельки. Ни HUD, ни Slider не обязаны знать ничего об устройстве Screen. Его можно заменять на другие разновидности совершенно свободно, лишь бы они реализовывали нужные абстрактные методы prev() и next() и умели подстраиваться под размер.
Таким образом HUD не управляет Screen напрямую. Ему не надо вообще знать о каком-то Screen и его методах. Его ответственность – общение с пользователем и информирование любого подписчика о желании пользователя. Он вообще никому ничего не приказывает, кроме своих собственных детишек-кнопочек. Он ничего не знает о внешнем мире и о том что происходит в контейнере-папе. А это означает, что такой модуль-интерфейс можно легко взять в другой проект – он независим и нетребователен.
Точно также класс Screen можно легко взять в другой проект. Он также независим и нетребователен – показывает коллекцию картинок и имеет два метода для управления этим показом. Все его "мозги" сосредоточены только на этих ответственностях – правильно масштабировать и размещать изображения и следить за границами ленты, чтобы она не уезжала куда не следует или порядком картинок, чтобы они не "кончились")). Ну и эффектами, разумеется. И само собой, Screen не должен получать команды в стиле "сместить ленту на 10 пикселей вправо". У него может вообще не быть никакой ленты.У него точно есть предыдущая и следующая картинки, это всё что нужно знать папе.
И тогда получаем компонент, который всегда можно легко модифицировать – заменить интерфейс на другой подкласс HUD или заменить экранчик на другой подкласс Screen. Либо – на совсем другой класс, но слегка исправив только сам класс Slider, a HUD при этом изменять совершенно не нужно – он независим от экранчика, ему не надо знать ни его класс, ни его методы, он вообще не знает о его существовании.

[Wazzabi]

Wolsh, Большое спасибо за исчерпывающий ответ и терпение!!! теперь все стало ясно =)