Swiz требует слабой инкапсуляции

Как я уже упоминал в списке рассылки, к сожалению, другого пути нет. Поскольку нет способа получить доступ к частным членам классов, единственный способ B использовать частные обработчики событий для событий из A - это вызов addEventListener () изнутри B. Поскольку Swiz, очевидно, не работает в ваших классах, у него нет возможности для доступа к этим участникам.

Swiz стремится максимально освободить код вашего приложения от ссылок (включая наследование) на классы Swiz. Таким образом, вы можете думать об этом как о настройке вашего приложения «извне». В отличие от JVM, Flash Player просто не разрешает доступ частным участникам, поэтому для взаимодействия Swiz с вашим кодом он должен быть общедоступным.

Вы также можете создать собственное пространство имен, которое сделает их не обязательно общедоступными, но и не частными. Я использую то, что изначально делал Openflux:

[Mediate(event="UserEvent.LOGIN")]
metadata function loginHandler(user:User):void
{
    ... with namespace
}

[Mediate(event="UserEvent.LOGOUT")]
public function logoutHandler(user:User):void
{
    ... without namespace
}

Затем вам нужно добавить use namespace metadata в Процессоры Swiz и, возможно, их метаданные MediateQueue. Пока пространство имен импортируется в правильные классы, то, что динамически ссылается на метод, будет работать:

поэтому в методе setUpMetadataTag в MediateProcessor (или в верхней части класса):

use namespace metadata;
// bean.source[mediateTag.host.name]
// service["loginHandler"] and service["logoutHandler"] both work
addMediatorByEventType( mediateTag, bean.source[ mediateTag.host.name ], eventType );

Делает код чистым и предохраняет его от публикации. Но некоторые думают, что это слишком много работы :).

С уважением, Лэнс

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

«Swiz требует, чтобы все обработчики событий были общедоступными, чтобы управлять событиями».

Это правда, но сила Swiz в том, что он не навязывает вам какой-либо (более или менее) выбор дизайна, он просто предоставляет мощные инструменты (внедрение зависимостей, посредничество событий и т. Д.), Которые вы можете применить там, где считаете нужным.

Использование Swiz вообще не требует использования тега [Mediate] - вы все равно можете использовать addEventListener () и прослушивать частные методы, как обычно (я уверен, что вы это хорошо знаете). Насколько я могу судить, посредничество событий Swiz предназначено в первую очередь для использования с событиями уровня системы / приложения. Если вы вызываете прослушиватели событий в рамках одного компонента или компонентов близкого семейства, вы обычно используете стандартные прослушиватели событий. Чтобы общаться между отдельными, иначе не связанными друг с другом компонентами, вы можете обработать сообщение с помощью посредника Swiz.

Короче говоря, в любом случае, когда у вас есть доступ к частным прослушивателям событий (то есть внутри близких компонентов), вы, вероятно, не будете использовать [Mediate] для захвата события, чтобы этот прослушиватель мог оставаться частным. Когда вы используете тег [Mediate], обработчик событий обычно находится в совершенно отдельном месте в приложении (например, презентатор -> контроллер), где он практически не может быть частным в любом случае.

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