caseyryan, зато поугарать можно, а то порой тишина зависает, днями никто ничего не постит :D
P.S. Недавно когда кому-то хотел ответить, не помню кому уже, чуть не написал "Akopalipsis, это не вы, случаем?)"... Больно напоминал)

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

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

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

В студии мелкософта нечто подобное имеет место быть, кстати.

А наследование и проч. тут вообще не при чем.

У меня было следующее соглашение с самим собой:

• Если константа находится в классе, который заканчивается на "s", значит в слушатель придет экземпляр класса Event.
  
• Если же "s" на конце нет, значит придет экземпляр класса, в котором лежит константа.

То есть когда я пишу
то не заглядывая в код "blabla", я могу сразу написать

а если я пишу
то не заглядывая в код "blabla", я могу сразу написать

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

Зачем это? Это же не логично... TimerEvent.TIMER смотрится уж куда лучше, чем TimerEvents.TIMER.

Добавлено через 23 минуты
К тому же подобный код обещает быть неоднородным.

Добавлено через 26 минут
Вдруг вы в одном месте напишете TimerEvents, а в другом без s, выйдет каша из "новых" и "старых" подходов.

Чтобы класс состоял только из констант. Иначе ему придется наследовать Event, не привнося ничего нового.

Тогда исправлю. Редакторы кода с возможностями рефакторинга делают это быстро.

Такой подход не предусматривает пуш-события.
Что, если вы захотите передать вместе с событием новые/обновлённые данные?
Как вы их в Event засунете?

Или вы всё таки превратить код в кашу и там использовать одно, а там другое.
Отсылайте тогда уж DataEvent.

Если мне нужно передать какие-то данные в событии, то я создаю кастомное событие в названии которого нет "s" на конце.

Для меня большей кашей кажется

ZackMercury, не надо представлять везде DataEvent как панацею. Обнаружьте уже с удивлением, что data у него всего-лишь String, и никакие ссылки на объекты это событие таскать не может.
callme, создать список констант или создать кастомное событие, отличающееся от Event только расширенным списком констант и говорящим названием — технически разницы почти никакой, а в плане организации кода однозначный профит — подписываться на тип из ManEvent и получать в обработчике event:ManEvent — это идеально. Есть еще третий вариант — хранить константы в классе отправителя, но это уже компромисс (Man.I_EAT_MY_DOG). Списки констант (то есть классы в которых ТОЛЬКО списки) хороши, как легкое связующее между системами, которые не должны иметь жесткой связности (например, в MVC Вью не должна импортировать класс Модели, но должна как-то подписаться на ее события. Интерфейс Модели предоставляет Вью геттеры данных, но никак не может описать События. И их (Вью и Модель) приходится связывать либо классами кастомных Событий — то есть и Вью и Модель импортируют в себя одни и те же классы Событий — либо легким списочком строковых констант, используя при этом стандартный Event). Городить списки, которые наоборот только создают неразбериху нет никакого смысла.

Wolsh, спасибо. Смирюсь с этим глупым наследованием, все равно класс порождать для констант.

Вопрос по MVC. Мы же во вью все равно завяжемся на классы, в которых константы лежат?

Не совсем. У Вью может быть свой класс-список, а у Модели свой. Просто значения констант должны совпадать, кроме того у Вью список может быть меньше (скажем, если это маленькое конкретное вью например кол-ва Маны и никакие события кроме изменения Маны его не интересуют). Вью и Модель связаны только строками, а не физически едиными файлами Событий. Еще раз: при использовании кастомного события они должны импортировать один и тот же файл (класс). А строки могут быть записаны где угодно, не обязательно в едином классе-списке. Это просто строки.