ООП раздувает массу информации из ничего ?

[Wolsh]

Пора переименовывать тему в "ошибки детализации"

Артем, у меня такое ощущение, что здесь главный класс как мусорка)) Детализация до уровня "назначить каждой кнопочке в приложении параметры типа маусЧилдрен и слушателей в Главном классе"? Разве нельзя сделать архитектуру иначе? Объединить кнопки в "панели", меню отдельно, HUD отдельно, топПанель, сайдПанель, я не знаю.. Сделать это блоками, и детализация Главного класса будет на уровне меню-панелей, а уже классов этих панелей - на уровне "кнопка.х = 10".

[Gaen]

Psycho Tiger, в вашем коде я вижу монструозный интерфейс, состоящий из логически разделяемых блоков. Есть несколько менюшек, которые можно распихать по контейнерам или вообще превратить в отдельные контролы, что даст возможность перенести в них часть функционала, ну и просто добавить один общий слушатель, вместо того чтобы вешать его персонально на каждую кнопку.
Плюс в самом методе и инициализация ссылок, и добавление слушателей, и включение музыки - в общем саму инициализацию можно разбить на независимые куски, что повысит структурированность и читабельность.

[Psycho Tiger]

Артем, у меня такое ощущение, что здесь главный класс как мусорка))

Помилуй, какой ж это главный класс? Это просто одна из вьюх начинает синхронизироваться с графикой.

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

А потом по switch (target.name) смотреть куда тыкнули? Как-то это небезопасно "привязываться" не к ссылкам, а какому-то полю name. А когда мне нужно чтобы 2 кнопки вызывали один обработчик (onGoClick у меня вроде есть) - что делать? =)
Или речь об одном обработчике с привязкой просто по target? Идея, наверно, хорошая.

Блок-панели, конечно, здорово. Но, наверное, не в конкретном случае - весь дизайн собран в swc`шке, как можно заметить, а тяну я оттуда элементы, добавляя им поведение. Разницы не будет.
Мне что писать

clip.addEventListener(click, handler);

что

panel.addEventLisener(clipClick, hanlder);

Те же яйца, только в профиль.

[Gaen]

А потом по switch (target.name) смотреть куда тыкнули?

Боже упаси
Пачку кнопок собрать в меню, которое само будет следить, куда там нажали и какая галочка в этот момент стояла, и посылать наверх пользовательское событие. В итоге вместо сообщения "юзер кликнул по mc1" будем получать сообщение "юзер хочет перейти к инвентарю".

[Хомяк]

Получается, вроде как, разделение ради разделения, что ли?
У меня есть подобный класс. Он обеспечивает работу интерфейса пользователя. На панели интерфейса около 30 элементов управления приложением (разделенными на группы лишь визуально, для облегчения ориентации пользователя). Есть список-массив состояний этих элементов, их более 30-ти (учитывая состояния активен/неактивен). Задача класса: предоставить начальное, текущее состояние эл-тов управления, анализировать изменения, по результатам анализа предоставлять либо возможность изменить состояние приложения которое управляется с помощью этого интерфейса, либо получить код приложения.
Механизм реализации: В начале работы класс получает список-массив состояний элементов, тупо (а потому быстро) перебрав элементы, на панели элементов, он изменяет их состояние просто последовательно перебирая список-массив. В результате возникновений событий клик или change на элементах класс вновь перебирает все элементы считывая их текущее состояние формирует массив текущих состояний, сравнивает массивы (начальный и текущий) и если их равенство false, предоставляет возможность пользователю утвердить сделанные изменения. Так же есть кнопка "Cancel" по клику на которой вновь перебираются все элементы (как в начале работы) и назначаются исходные состояния элементов управления.
Что в данном случае даст разделение элементов на группы кроме усложнения и точно замедления реакции приложения? Или в этом случае можно как то по другому разделить?

[mikhailk]

Из описания не совсем понятно, какая задача решалась, но, на мой скромный взгляд, ООП начинается тогда, когда мы переходим от работы с данными о которых МЫ знаем все (напр. массивов с числами и булевыми переменными), к работе с объектами, которые САМИ о себе знают все. Соответственно, по тому же клику по какой-либо кнопке нам не надо перебирать массив кнопок, чтобы выяснить кого там нажали. Кнопка сама продиспатчит наверх событие MySuperButton.I_WAS_PRESSED или кому как нравится, в которой сообщит о своем изменении статуса и о том, как ее зовут. А в самом классе панели останется только массив непосредственно кнопок MySuperButton, функция инициализации кнопок, пара-тройка обработчиков слушателей и еще кое-что по мелочи.

А по размеру - как ни крути, но когда класс до 200-250 строк, это просто удобно.

[Хомяк]

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

...

Вы правильно всё поняли. Но интерфейс управления, в данном случае, состоит не только из кнопок, но из самых различных компонентов. Кроме того, задача усложнятся еще и тем, что одни эл-ты управления могут влиять на состояние других эл. управления. И обход значений эл-тов применяется не для того, чтобы выяснить, что и где случилось, а для того чтобы собрать текущие значения и сравнить их с начальными. Поэтому, в принципе, не имеет значение - что и где нажато, а имеет значение то, как изменился, и изменился ли, массив значений (простите за тавтологию ).

[Wolsh]

Помилуй, какой ж это главный класс? Это просто одна из вьюх...

Абсолютно без разницы. Я точно вижу из имен, что все эти кнопки принадлежат разным группам, а собраны в одном месте. Ты приводишь это как пример, что ничего нельзя сделать, нечего делить, а я не соглашаюсь.

Те же яйца, только в профиль.

Нет, если

_menu = new Menu();
_menu.x = 10, _menu.y = 5;
_screen.addChild(_menu);
_menu.addEventListener(Menu.SELECT, onMenuAction);

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

Получается, вроде как, разделение ради разделения, что ли?

Ради улучшения детализации, специализации, инкапсуляции и прочих аций делением отряда на звездочки с назначением старших))

[Psycho Tiger]

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

Боже упаси
Пачку кнопок собрать в меню, которое само будет следить, куда там нажали и какая галочка в этот момент стояла, и посылать наверх пользовательское событие. В итоге вместо сообщения "юзер кликнул по mc1" будем получать сообщение "юзер хочет перейти к инвентарю".

А я о чем?
Если клик по кнопке переходит к инвентарю, то разницы почти нету.

clip.addEventListener(Event.CLICK, gotoInventory);

или

container.addEventListener(GameEvent.INVENTORY_GO, gotoInventory);