Изменение свойств одного объекта через методы другого объекта

[Wolsh]

Насчет mvc много раз встречал на форуме и читал в википедии его принципы пару раз. Как-то не дается пониманию. Начинающему легче видеть частные случаи, чем глобальные принципы ООП.

Как это делается грамотными разработчиками?..

Тогда, может быть, начать с чего-то попроще? Или, раз уж не терпится сделать Марио, перестаем называть себя начинающим и начинаем изучать MVC. Как-то сведите концы с концами. Какой смысл закреплять неверные подходы и генерировать отрицательные эмоции к разработке, на каждом шагу изобретая велосипед?
Так же удивляет Ваша позиция относительно централизации логики. Ну замкнете Вы золотые кубики на счетчик – тут нет особой проблемы, сделали у счетчика метод registerTrigger(trigger:ITrigger) и передавайте в него источники денег при их создании на карте, в методе подписываетесь на событие от этих кубиков, ну и unregisterTrigger(trigger:ITrigger) конечно не забыть) — все это будет прекрасно, пока Вам не взбредет в голову делать радостную улыбку на морде Марио при поступлении платежа на счет. Оказывается, еще кто-то должен знать. Делаем присоску к счетчику денег? Ах ты ж, совсем забыли — надо еще показывать, сколько бонусов всего на уровне и сколько уже оприходовано! И снова пиявки. А через пару недель эту окрошку уже не процедить, потому что каждая пиявка живет своей жизнью и чего-то делает, но никем не контролируется. Ничего не знает об остальных участниках программы, согласно директиве ООП(б), но — вот незадача — при этом самостоятельно действует, невзирая на планы партии (о которых просто ничего не знает).
Настоятельно рекомендую не тратить время на сбор шишек. Изучите MVC. Хотя бы концепцию поймите, сразу туман войны рассеется.

[expl]

МVC - он для сайтов и социалочек всяких работает. А вот для аркады - уверенности нет (делал раза 2 и очень давно).
Зайдите на gamedev.ru - там популярнее объяснят как конкретно делать игры.
Есть же и другие подходы, например entity-based system (сам не пробовал)
По сути:

У нас квадратики с вопросительными знаками, удар по которым прибавляет нам количество монеток в счетчике. Я правильно понимаю, что такой квадратик нужно вынести в отдельный класс? Да и счетчик тоже (пусть даже в комплексе с другими счечиками).

Вот. И как им взаимодействовать? После столкновения персонажа с объектом вопросительного знака последний диспатчит событие, которое прослушивается. Вопрос где?
1. В главном классе, родителе всех созданных объектов, тогда там будут слушаться и остальная сотня объектов мира марио (на мой взгляд, весь код игры будет там).
2. В самом себе, на слушателе будет вызываться метод, который должен уметь повлиять на объекты - экземпляры других классов (счетчика, персонажа и т.д.). Может быть это стоит делать через посреднический объект, который будет параметром при создании?

Как это делается грамотными разработчиками?..

Определить столкновение с кубиком и показать монетку затруднения не возинкло, а отобразить изменение счета - возникло?

Я бы в такой ситуации взял бы прямо объект "верхняя панель", добавил туда пару методов:

private var _money:int = 0;
public function get money():int
{
   return _money;
}
public function set money(value:int):void
{
   _money = value;
   _moneyTextField.text = value + "$";
}

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

_panel.money += brickKickBonusMoney;

А потом бы уже глядя на _рабочий_ код думал какими проблемами такой подход чреват. Надо ли выделить класс PanelModel или так и таскать вьюшку по контроллеру, т.к. пофиг. Где лучше хранить вычисление бонуса - на кирпиче или в глобальном контроллере и т.д.

[SvetozarPNZ]

в методе подписываетесь на событие от этих кубиков

Как я могу в методе счетчика подписаться на событие от кубиков?

Потом передал бы ее тому куску кода, который показывает монетки. Передал бы через конструктор

Т.е. при создании кубика нужно передать в него "верхнюю панель"?

[Wolsh]

Как я могу в методе счетчика подписаться на событие от кубиков?

А в чем проблема, если ссылка на кубик передается этому методу registerTrigger()?

[SvetozarPNZ]

Т.е. счетчику передается в качестве параметра ссылка на кубик?

[expl]

Цитата: Как я могу в методе счетчика подписаться на событие от кубиков?

А в чем проблема, если ссылка на кубик передается этому методу registerTrigger()?

Т.е.:
- заводим в панели (наверное, Wolsh имел ввиду не панель, а какой-то контроллер, но будем мыслить предметно) метод registerTrigger
- заводим там список этих кубиков
- при появлении кубика кто-то регистрирует его c помощью registerTrigger
- при вызове registerTrigger - заносим кубик в список и подписываемся на события кубика
- при unregisterTrigger - отписываемся
Ради чего всё это? Не, оно понятно, что в какой-то ситуации такой подход оправдан, только не понятно в какой (да оно и вообще обсуждать архитектуру "на словах" тяжеловато)

Т.е. при создании кубика нужно передать в него "верхнюю панель"?

Угу, именно так.
А если/потом/когда станет страшно передавать всем панель с кучей методов, относящихся только к отображению:
- выносим PanelModel
- подписываемя в Panel на PanelModel - чтобы панелька отображала изменения PanelModel
- таскаем везде PanelModel

[SvetozarPNZ]

Спасибо, ребят. Кое-что в голове стало просветляться.
Я напишу своими словами, а вы мне скажите: да, так и есть, или поправьте

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

var kubik:Kubik = new Kubik (panel);

Раз у меня есть ссылка на панель, то я в коде этого класса Kubik могу использовать методы верхней панели:

public function Kubik (panel) {
 panel.registerTrigger(this); 
}

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

public function registerTrigger(currentKubik) {
 this.massOfKubik.push(currentKubik);
 addEventListener(currentKubik.hitKubik, getMoney);
}

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

[expl]

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

До меня тоже.

А листенеры предполагается удалять при убирании кубика со цены, когда он вызывает метод unregister(currentKubik)

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

public function Kubik (panel) {
 this.panel = panel;
}
...
panel.money += 10;

[Wolsh]

Ладно. Теперь я расскажу, что имел в виду))

// место где создаются кубики
var cube:MoneyCube = new MoneyCube();
_moneyCountBar.registerTrigger(cube);
 
// код в MoneyCountBar (панельке)
public function registerTrigger(trigger:IMoneyTrigger):void
{
	trigger.addEventListener(GameEvent.MONEY_BONUS, increaseCount);
}
 
public function unregisterTrigger(trigger:IMoneyTrigger):void
{
	trigger.removeEventListener(GameEvent.MONEY_BONUS, increaseCount);
}

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

Не морочте себе голову, подход с registerTrigger в данной ситуации ничего не дает

Демократия для политики. В программировании — иерархия. Кубики не обладают логикой, их много. "Много" не имеет права принимать решение. Панель одна, значит может хоть о чем-то думать. Поэтому кубики сообщают в штаб, а штаб решает что с этим делать, на основании указаний сверху в том числе.
У каждой задачи есть простое, очевидное и быстрое неправильное решение.
Потом разработчик говорит: "Вот посмотрите, я тут пару игр написал... Что? ООП? Нее... не слышал!"

[SvetozarPNZ]

Что за странная идея хранить ссылки на кубики в панельке? Их же потом не удалить.

Да, я уже понял. Изначально я хотел хоть где-то их запомнить. Похоже учет кубиков будет происходить в родителе.

Добавлено через 3 минуты
Резюмирую. Управлять объектами буду в главном классе, но чтобы сократить код, все методы будут выполняться в других классах (каждому свою задачу), а для этого буду передавать методам ссылку на объект, которым в данный момент управляю.