Организация работы событий
 

Здравствуйте.

Интересует следующий вопрос, скорее даже нюанс проектирования приложений:

1) Допустим, у нас есть какой-то объект, который генерирует большое количество событий (больше 10).
2) Большинство из этих событий однотипные и через эти события не должны передаваться параметры.
3) Через некоторые события должны передаваться параметры, которые неотрывно привязаны к событию. Под параметрами, в данном контексте, я понимаю public переменные, которые можно считывать наподобие свойств target и/или delta у MouseEvent.

Возникает вопрос: что делать, создавать 10 классов для каждого типа событий, каждое событие которого бы обладало только теми параметрами (читай открытыми свойствами), которые принадлежат к данному типу события, или целесообразней, в целях «не плодить большого количества классов и сэкономить время» сделать 1 класс события, указать в нём все свойства, которые могут быть необходимы для событий и устанавливать значения только для тех событий, которые будут нужны в каждом конкретно случае?

Я, пока, склоняюсь ко 2-му способу, ведь, на сколько я понимаю, даже в MouseEvent сделано таким образом, что свойство delta доступно и при событиях CLICK, MOUSE_DOWN и т.п., хотя фактически оно необходимо только у события MOUSE_WHEEL.

Но с другой стороны, все нюансы по работе событий будут известны мне, но другие люди, которым, возможно, придётся столкнуться с моими событиями, будут недоумевать, почему в одном случае есть информация об одних переменных, а в другом её нет.

Вот такие вот дела.

Только не public переменные, а геттеры

Сомнительно.


А я дурак, я делаю одно событие с var info:Object={} куда пишу всё что сдумается. :D

На самом деле просто посмотри, что ты там передаешь с событием. Например, количество игроков онлайн, открытые двери и год после рождества Христова. По сути, 3 разных переменных - totalOnline, openDoors, year, но ведь можно передать просто intValue, а в комментариях написать мол "а тут нам приходит..."

2 PsyhoTiger:
Мне кажется ваш подход в корне не правилен.

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

Плюс непонятные названия переменных будут усиливать неразбериху.

2 fljot:
Это кому-как удобнее, я не люблю тру геттер/сеттер методы (аля get myProp), да и писать в коде события гетеры сеттеры я пока не вижу смысла, мне кажется это только увеличит количество кода и усложнит класс события. Не вижу пока смысла «защищать» возможность изменения переменных у события, так как это событие будет использоваться только в 1 месте (приемник события).

Да.
Какие плюсы я вижу: типизация и использование одного события для многих задач.
В коде:
Конечно, если значений переменных много - а ля intValue1,intValue2...etc, или вообще приходит вектор - там просто запутаться. Но тогда можно сразу в хендлере вынести в локальные переменные, а ещё лучше для таких событий сделать отдельное событие.

Я не говорю, что мой вариант лучший - но он вполне имеет право на жизнь. Но, как я уже сказал, я всё равно пользуюсь одним Object`ом )

Каждому — своё, но мне кажется, что вариант с object, в этом случае, не имеет права на жизнь (я понимаю, что это звучит категорично, но мне кажется, что хорошо когда нам компилятор будет сам подсказывать, к каким переменным можно обратиться, а к каким — нет + хорошие названия переменных улучшают читабельность кода).

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

Досточно public-ов. От геттеров проку нет, событие всё равно клонируется постоянно.

Клонируется то клонируется, но это при бабблинге или в разных обработчиках. Но ведь можно изменить данные, если кто-то его передиспатчит, или внутри одного обработчика, или при передаче ("по ссылке") куда-то.

И что? Если вы хотите наступить на грабли, вы на них наступите. Причем самостоятельно.

Да, etc прав. Вся инкапсуляция и тому подобное было сделано ради защиты от дураков. Защиты от идиотов же не существует. Я найду способ сломать событие и с геттерами. Например, остановлю его.