Правильно ли главный класс делать синглтоном?

[zzSpirit]

Ну, добавлять на сцену я буду все в главном классе, как положено.
Но к примеру у меня есть класс VK - синглтон, где используется конструкция stage.loaderInfo.parameters, в этот класс я передаю ссылку на Main, думал сделать так чтобы не передавать ссылку, а обращаться просто: main.stage.loaderInfo.parameters - но понял теперь что это нарушает ООП принципы, кароче самое правильное ссылкой как я понял.

Добавлено через 1 минуту

Сообщение от Wolsh

p.S. за stage.addChild() я бы расстреливал без компенсации.

Имеется ввиду, если написать так в главном классе вместо просто addChild()?

Добавлено через 3 минуты

Сообщение от caseyryan

У автора наверное была конструкция типа этой:

public static var MAIN:Main = this;

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

Да, именно так и было. Спасибо, помогло.

[Wolsh]

Имеется ввиду, если написать так в главном классе вместо просто addChild()?

На stage должен находиться только один объект — экземпляр Документ-класса. Он является Вашим приложением. И он контейнер (не может не быть контейнером). Все, что создается приложением, должно находиться в контейнере приложения, а не шляться где-то за его пределами.
Сама по себе запись stage.addChild() является командой от потомка родителю, что так же недопустимо. Потомок не должен вызывать методы родителя напрямую. Если родитель желает слышать голос ребенка, он подписывается на события от него и сам решает, что делать когда события приходят. Но ребенок никогда не должен принимать решения за родителя и делать что-то "от его имени". Приложение без иерархии превращается в бардак, а классы, желающие управлять своими родителями, непригодны для повторного использования в других проектах. Классы, выбрасывающие своих детей на Stage — тем более.
Многие используют этот трюк для добавления всплывающих окон и подсказок (а когда-то и курсоров), вместо того чтобы просто создать структуру глубины с помощью контейнеров-"слоев" в документ-классе. Это не более чем безалаберность и лень. Не делайте так. Не понимайте слова "добавить на стейдж" буквально. Это всегда подразумевает "добавить в список отображения". Stage — это плеер. И в плеере должен показываться только один объект — Ваше приложение. И все его дети должны находиться в ЕГО списке отображения.

[zzSpirit]

Огромное спасибо, Wolsh! Теперь все понятно!

[СлаваRa]

на самом деле, дела с этим обстоят очень плохо, огромное кол-во программистов использует этот подход в промышленных масштабах... а потом, долго-долго решают проблемы... другая доля программистов не понимает, что Stage один.
Открываешь проект и видишь StageHelper.instance.activeStage, что-то-там.removeFromParent() и т.д.,.. я до сих пор не могу понять, почему\зачем люди так хотят создать себе проблем.

[semenyakinVS]

Если родитель желает слышать голос ребенка, он подписывается на события от него и сам решает, что делать когда события приходят.

Wolsh, спасибо за инфу по поводу синглтона. Задумался и пошёл шерстить свой код на предмет подобных случаев.

Main.instance

А где здесь нарушение инкапсуляции? Или это не вызов property (геттера), а получение указателя на статическую структуру (тогда да, тогда нарушение) ?

[СлаваRa]

какого фига main кому в "дереве" своей программы должен быть доступен? или должен отдавать свое? ну правда, а?

если так, любой сможет расшатать логику программы.. отловить это будет крайне сложно(

[zzSpirit]

Сообщение от СлаваRa

какого фига main кому в "дереве" своей программы должен быть доступен? или должен отдавать свое? ну правда, а?

что ты имеешь ввиду под "отдавать свое"? то, что он передает ссылку на самого себя или что-то другое?

[Psycho Tiger]

Ни одни здравомыслящий программист , понимающий принципы ООП, знающий , что такое инкапсуляция и т.п. - не напишет даже так Main.variable .
Какое бы вы приложение не писали, простое или сложно, у вас всегда есть ОСНОВНОЙ вид и ГЛАВНЫЙ контроллер, который хранит ссылку на _host

Моих тем про MVC перечитал?
Да, действительно, так делать правильно в ряде случаев. Но главная мысль в любом приложении с отделенными частями логики – пусть данные не лезут в отображение напрямую.
К слову, интересен обмен опытом: чем для тебя фатальны статические ссылки?

По сабжу: запомните раз и навсегда. Синглтон – это только возможность создания одного экземпляра. В контексте флеша stage – это синглтон. Но к нему нету повсеместно глобального доступа.
Сколько раз создается Main (подразумеваю, что Main - base class). Один. Этот экземпляр создаёт флешплеер при запуске флешки. Если требуется вызвать где–то

new Main

явно – то это действительно плохо. Ну серьезно, приложение которое создаёт само себя внутри себя...

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

[caseyryan]

На stage должен находиться только один объект — экземпляр Документ-класса. Он является Вашим приложением. И он контейнер (не может не быть контейнером). Все, что создается приложением, должно находиться в контейнере приложения, а не шляться где-то за его пределами.

Можно конечно и документ класс использовать для этого (теоритически), но лично я не вижу ничего плохого в том, чтобы различные модальные окна добавлялись на stage.
У меня часто в приложениях присутствуют менеджеры модальных окон, которые инициализируются на stage. При вызове какого-то статического метода, типа addWarningWindow(title:String) на стейдж добавляется окно, а на фон сразу под ним добавляется спрайт с прозрачной заливкой со сторонаями равными stageWidth, stageHeight, чтобы перекрыть клики. Окна полностью автономны, и приложение не имеет каких либо других ссылок на них. Так вот, почему stage а не документ класс, опять же из-за размеров спрайта заливки. Не от документ класса же получать ширину и высоту этой заливки.

[Wolsh]

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