Организация слушателей в приложении

[zaidite]

Всех с новым годом!
У меня такой вопрос...
Делаю свою первую серьёзную игрушку-стратегию. У меня на экране пять различных блоков пользовательского меню. В каждом из блоков от 4-х до 12 кнопок. Всего 34 кнопки. Вот я и думаю, по поводу организации слушателей к этим кнопкам. Если к каждой сразу прикрепить слушателей на наведение, на уход с кнопки и на нажатие, то это будет больше ста слушателей которые будут слушать события. Тормозить это наверное будет жутко...
Возникла идея их всех разделить и сделать следующую архитектуру. Кнопки каждого блока меню находятся в своём контейнере, каждый контейнер с кнопками помещается в свою очередь в один общий спрайт-контейнер для кнопок меню. За этим спрайтом следит один слушатель. Он отслеживает событие MOUSE_MOVE. Как только возникает событие в области кнопок меню, запускается функция, которая вычисляет координаты мышки и сравнивает их с координатами клипов-контейнеров блоков меню. Если координаты мышки находятся над блоком меню, к примеру № 3, то запускаются слушатели для кнопок этого блока меню. По событию MOUSE_OUT с кнопок этого блока меню все слушатели для этого блока удаляются.
Вот такая идея. Но мне она кажется тоже довольно громоздкой. Вот хочу спросить, может быть существует более элегантное решение для подобных случаев и не нужно изобретать велосипед?...

[Gaen]

Не заморачивайтесь. Пусть каждая кнопка слушает мышь, чтобы менять свои визуальные состояния, и пусть контейнер с кнопками слушает мышь, чтобы отловить нажатие и по target узнать, которая кнопка была нажата.
80% тормозов идут из 20% кода, и вряд ли ваше меню туда входит

[Himerets]

Мне кажется, сто слушателей MOUSE_OVER/MOUSE_OUT не будут тормозить работу.
А, кстати, один слушатель MOUSE_MOVE может давать существенные тормоза в твоем случае. Ведь при каждом шорохе будет происходить анализ, на какой кнопке курсор и на кнопке ли он вообще. Так что лучше оставь старый вариант, только по возможности вынеси кнопку в отдельный класс, чтоб прописать там реакцию на наведение/уход. Я так подозреваю, что для всех кнопок она будет одинаковой.

[zaidite]

GAIKER, Честно говоря, хотелось бы что-бы код был по-компактнее и оптимизированнее. И если не заморачиваться, то в моём случае это больше сотни слушателей только для событий кнопок. А если реализовывать ту конструкцию, что я описал, это получается громоздкая хреновина, которая тоже будет отъедать память и увеличивать объём кода в приложении... Есть подозрения, что это всё можно сделать немного красивее и изящнее.

[Gaen]

Проще - вместо мувиклипов использовать для кнопок SimpleButton, тогда от них надо будет слушать только клики.

[zaidite]

Всё получилось. Организовал следующим образом...

Есть общий для меню класс - Menu, он создаёт и размещает на сцене блоки меню. И есть классы которые создают блоки меню. left_menu, right_menu, top_menu, down_menu.

В этих классах создаются группированные блоки с кнопками меню и определяются функции, что какая кнопка делает. При создании кнопок назначаю уникальный номер для каждой кнопки id = 0... И создаю для кнопки массив в который сохраняю ссылку на функцию, которая назначена кнопке и другую полезную информацию. Этот массив помещаю в общий массив с функциями actionsArr который находится в классе Menu. Получается такой себе двумерный массив.

В классе кнопки сделал слушатель MOUSE_OVER, который, в случае события запускает функцию подсветки кнопки и создаёт слушатели MOUSE_OUT и MOUSE_CLICK. В случае MOUSE_OUT снимается подсветка с кнопки и удаляются MOUSE_OUT и MOUSE_CLICK.

А в случае MOUSE_CLICK вызывается функция create_action() в Menu, которой передаётся id-номер кнопки на которой кликнули. Функция create_action() ищет в массиве actionsArr элемент, порядковый номер которого совпадает с переданным id кнопки и по ссылке выполняет функцию, которая определена для этой кнопки.

И всё работает.