Глобальные переменные и ООП

[renych]

т.е. статика это плохо да?

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

[iNils]

Статика - это один для всех. Поэтому

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

это не понимание, что такое статика.

[anmelegov]

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

Добавлено через 18 минут
кстати по поводу менеджера клавиатуры, кто как это делает? у меня сейчас кейкоды нажатых кнопок хранятся в векторе<юинт>, но только что в голову пришла мысль что можно все хранить в одной переменной юинт и проверять побитово с помощью оператора &...

[renych]

это не понимание, что такое статика.

Что Вы имеете ввиду?

[Yahen]

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

т.е. это нормально, что если
в комнате есть шкаф, в шкафу есть книга, в книге есть закладка и закладка будет знать про комнату?

Приблизительно так и реализована иерархия объектов на сцене. В закладке есть ссылка на комнату. и книгу. книге на комнату и шкаф. И в шкафу на комнату.
Совершенно нормальная структура.

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

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

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

Разработчики самого AS c Вами не согласятся

[iNils]

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

Что Вы имеете ввиду?

Если "Статика - это один для всех", то не должно возникать понятия "один экземпляр".

[Wolsh]

И того имеем три переменные. Далее в классе создаётся куча других классов, которые так или иначе
работают с BitmapData. Рисуют в него, копируют и т.п. Им всем нужен доступ к width, height и bmp.
Более того, в каждом из этих классов могут быть созданы другие классы, которое тоже захотят работать
c этим битмапом.

Вообще говоря, споры на эту тему всегда переходят в холивар. У всех есть свои привычки, свой опыт, ошибки и их решения. Если делать ООП, то это должен быть изначально ООП. Это важно понимать. Невозможно сделать пикник на обочине, накидав мусора на стейдж, а потом зафигачить туда "ООП"-класс. Или два. Или шаблон))) Поэтому спрашивать о каком-то фрагменте программы, как это сделать по ООП, и при этом подразумевать что остальные системы будут спроектированы "как фишка ляжет" – бессмысленно.
Вот Вы приводите пример, и сразу хочется сказать – почему три, если передается битмапдата, то у нее уже есть ширина и высота, зачем передавать их отдельно. И так будет с каждым конкретным примером.
Далее – если классы работают с битмапдатой, то как блин Вы можете им ее не передавать?))) Спроектировать классы так, что они будут запрашивать битмапдату у какого-то "глобального" класса-хранилища? Это смерть ООП. Это значит, что такой класс-попрошайка не сможет быть использован больше ни в одном проекте. Вы можете сделать электромобиль и заряжать его в своем гараже. Но если поедете на нем в другой город, Вам надо построить там зарядную станцию. То есть в другом проекте для использования этого побочного классика Вам придется разворачивать глобальную структуру поддержки на верхнем уровне. Он не самодостаточен как исполнитель. Это такая секретарша заведующего отделом, которая по любому вопросу звонит главе компании. И это семечки – глава компании при этом должен еще и знать ответы на ее местячковые вопросы.
ООП без иерархии это свалка. Это когда "контроллер клавиатуры" почему-то управляет персонажем, получивший новые настройки стилей xml-лоадер рассылает события сотням детей-GUI, и те толпами ломятся к нему за своими каскадами стилей, вместо того чтобы просто спустить каскад вниз и каждому выдать конкретное указание... да мало ли каких странностей не бывает. Для того и придумано ООП, чтобы делать "по правилам", по единым и понятным правилам, не изобретая велосипедов и не создавая хитрых креативов, в которых придется разбираться потом самому, коллегам, компилятору и плееру. Но это уже каждый решает сам – воспользоваться чужим опытом и шаблонами, или положиться на свой гений и скреативить новое невиданное архитектурное решение.. Которое чаще всего оказывается решением на один раз и без возможности развернуться корпусом.

[renych]

Так вот и хочется всё сделать максимально универсально и масштабируемо. Чтоб модель не зависела от представления, а контроллер не оперировал данными.

Далее – если классы работают с битмапдатой, то как блин Вы можете им ее не передавать?

Я вот тут подумал, а что если подписать их на события и передавать данные в аргументах? Тогда исчезнет необходимость передавать параметры всем и каждому в конструкторах или ссылку на класс верхнего уровня.

Пример про битмапдату - просто пример.

Добавлено через 4 минуты
допустим та история с комнатой, в которой шкаф, в котором книга.
книга может испортиться, если влажность воздуха в комнате повысится.
но я не хочу передавать в шкаф ссылку на комнату, а из шкафа в книгу ссылку на комнату, чтоб книга
знала, какая в комнате влажность. я могу сгенерить событие "Влажность изменилась" и передать в
аргументе события эту самую влажность. Книга на неё отреагирует и сгниёт

[Wolsh]

Это как раз самый характерный пример супермена.
"Книга отреагирует на влажность в комнате" означает, что область ответственности книги простирается далеко за ее пределы. И что книга САМА решает, как ей реагировать на внешние изменения. Это не только нарушает иерархию, это как раз тянет за собой строительство станций обслуживания книги, которые должны будут держать книгу в курсе того, что происходит вовне, а книга должна обладать достаточно развитой логикой, чтобы реагировать на разные внешние факторы. Нетрудно догадаться, что этих факторов почти столько же, сколько объектов в программе.
Вот аналогия.
Мама звонит дочке, которая в школе, и сообщает ей: "У нас кончилась колбаса".
FamilyEvent.HUNGER_BEGIN, data="sausage".
Это ваша ситуация с книгой, ваше решение отношений. Родитель посылает ребенку событие.
Теперь дочка должна как-то среагировать. У нее должно быть достаточно логики, чтобы пойти после школы в магазин, снять с карточки денег, выбрать сорт и количество колбасы, купить ее и доставить домой. (хотя в вашем варианте "сгнить" дочка скорее должна "съесть" колбасу, а не "доставить домой". Тут есть определенная разница)) но это лишь детали). Кроме того, устройство детского организма не гарантирует, что дочка вообще как-то будет реагировать на событие. Во всяком случае, посылающая сообщение мама всего лишь посылает сообщение. Это просто dispatchEvent, и он ни к чему не обязывает получателей.
Как эта ситуация должна была бы разыгрываться при иерархических отношениях?
Мама звонит дочке и говорит "после школы зайди в "Веселую Сардельку" и купи полкило Брауншвейгской".
gotoAndBuy("Веселая Сарделька", "Брауншвейгская", .5);
И может заодно подписаться на событие BuyErrorEvent.STOCK_OUT, на случай если дочка позвонит из магазина и скажет, что Брауншвейгская закончилась. Потому что решать, какую колбасу купить взамен, должна мама, а не дочка.
Итак, от старших вниз идут приказы – прямые вызовы конкретных гарантированных методов детей, а от детей вверх – события и ошибки, то есть информация "с мест". Когда Вы возьмете этот класс дочки и перенесете в другой проект, вы будете точно знать, что она не спустит все ваши денежки на пирожные и не будет пытаться вызывать методы ваших старших классов, а в самом худшем случае будет звонить в пустоту (ну технически на самом деле не будет, если не будет подписчиков, но мы сейчас о логике разговариваем)). Что класс будет делать ровно то, что ему прикажут более ответственные товарищи. В вашем случае комната прикажет шкафу "увлажнись(120)", а шкаф прикажет всем своим обитателям "увлажнись(120-10)". Здесь книга может проверить свой лимит и выбросить сообщение "я же так сгнию!?". А вот понизит ли Комната влажность из-за сообщения от младшего члена – это логика Комнаты, и эта логика вправе проигнорировать событие от Книги, но отреагировать на событие "я же так сгнию!" от Шкафа, как более ценной сущности, например))) Мало того, Книга не должна сама гнить. Её кто-то создал, и только создатель знает, зачем. Книга не должна сама себя разрушать, удалять и т.п. Она – инструмент в какой-то большой игре, знать которую ей не надо. Только создатель может распоряжаться ее судьбой. Книга же должна отвечать только за своих подчиненных – приказывать страницам листаться и т.п.

[iNils]

Пример с книгой очень плохой. Книга именно сама и гниет. Шкаф тут вообще не причем.
Если брать примеры из жизни, то ООП работать не будет. Именно потому, что все объекты сами по себе. Понятие родитель-ребенок весьма условны. Вот книга на полке и она подчиняется полке только пока действует сила тяжести и только в направлении полки и стенки. Но стоит ее поднять и связи уже не будет.

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