Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   Композиция: обращение вверх по иерархии (http://www.flasher.ru/forum/showthread.php?t=204193)

Dukobpa3 14.11.2013 22:20

Свалка ведь не всё-в-одном. Свалка по срезам тоже делится.
А если у вас 200 разных событий то, как по мне, следует задуматься всё ли у вас ок с архитектурой.

По большому счету таких вот кастомных ивентов достаточно 1-3 на весь проект.
В то время как константных классов штук 5-6 для разных срезов логики.

Akopalipsis 14.11.2013 22:26

я тоже не могу понять, чем это десять классов с константами, хуже, чем ДЕСЯТЬ КЛАССОВ С СОБЫТИЯМИ?)

Добавлено через 1 минуту
Мне способ с типом Event больше почему то нравится.

Добавлено через 4 минуты
И хорошо бы было, если бы кто нибудь тему создал о - переопределении класса ED, вот это было бы интересно. Мне почему то кажется, что ГУРУ так вот и делаю. Переопределяют, пулы там всякие, передача с верху в низ... Делаете Вы так?)

Dukobpa3 14.11.2013 22:31

Не лучше и не хуже. Просто разные подходы которые в разных ситуациях предпочтительнее.

Akopalipsis 14.11.2013 22:34

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

spirit2 14.11.2013 22:36

Цитата:

Сообщение от Dukobpa3 (Сообщение 1152429)
По большому счету таких вот кастомных ивентов достаточно 1-3 на весь проект.
В то время как константных классов штук 5-6 для разных срезов логики.

Я за 5-6 "срезов логики" имеющий свой тип и хранящих свои константы. По-моему это деление на "кастомные эвенты" и "константные классы" как раз и есть лишние сущности.

Dukobpa3 14.11.2013 22:39

Модель пользователя, модель боя, модель города.
В каждой из них есть событие стартового апдейта INIT, событие апдейта в процессе UPDATE, и еще пачка своих собственных, напрмиер в бою - начало/пауза/конец боя. В городе - смена текущего активного здания, состав квестов нпц. В юзере - получение опыта, получение бабла.

Как это организовать в вашем варианте?

dimarik 14.11.2013 22:51

Оба плохо.

Dukobpa3 14.11.2013 23:00

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

spirit2 14.11.2013 23:02

Цитата:

Сообщение от Dukobpa3 (Сообщение 1152442)
Модель пользователя, модель боя, модель города.
В каждой из них есть событие стартового апдейта INIT, событие апдейта в процессе UPDATE, и еще пачка своих собственных, напрмиер в бою - начало/пауза/конец боя. В городе - смена текущего активного здания, состав квестов нпц. В юзере - получение опыта, получение бабла.

Как это организовать в вашем варианте?

Ну вот 3 есть. Предположу ещё, что гуи не 2 кнопки, и ему можно выделить свою нишу. Город и бой появляются не из воздуха, а значит фабрикам/билдерам работать с данными, будь то парсинг моделей, графики или сборка юнита/башенки из этих деталей. Думаю, что бой не крестики-нолики, и юниты вполне достойны общатся с моделью боя на своем языке. Ну и сервер, где-то там есть сервер. Вот получилось аж 7 для нашего сферического коня в вакууме.
Критикуйте :)

Цитата:

Оба плохо.
Научите хорошо. :)

Dukobpa3 14.11.2013 23:06

Цитата:

Вот получилось аж 7 для нашего сферического коня в вакууме.
Критикуйте
Да че критиковать. Хотите - колбасьте. Вцелом с какой-то стороны может и правильно. Но я бы так не делал ни разу))
Может вы еще и под каждый домик на карте изометрии свой ивент добавите?


Часовой пояс GMT +4, время: 10:36.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.