Всем привет. Такой вопрос
1)
есть классы они же модули хочется реализовать слабую связанность и поэтому решил использовать паттерн "медиатор" на события в классах модулях подписаны все остальные модули. Допустимо ли медиатор делать синглтоном ?
При событии в модуле 1 информация передается в медиатор, он передает инфу о ее событии в модуль 2 и наоборот.
Допустимо ли логику поведения при получении сигнала размещать в самом классе модуля (подписанном на событие модуле) или ее вызовы(функции модуля получателя) лучше поместить в Медиатор, как полностью управляющий класс?
2)
Модуль 1 собрал инфу и переработал ее, информирует Медиатор , Медиатор информирует модуль 2, модуль 2 получает информацию и приступает к ее обработке
Как лучше передать информацию между модулями через медиатор или создать репозиторий и класс для него для сохранения и передачи инфы?
Полная Версия: Паттерн медиатор
"Допустимо ли медиатор делать синглтоном ?"
если ты хочешь предотвратить любыми путями создание нескольких медиаторов, то делай сингельтон. Если тебя это не особо волнует, то и зингелтон не нужен.
"Допустимо ли логику поведения при получении сигнала размещать в самом классе модуля (подписанном на событие модуле) или ее вызовы(функции модуля получателя) лучше поместить в Медиатор, как полностью управляющий класс?"
Задача медиатора всего лишь быть посредником в коммуникации между объектами. Если засунуть туда кроме вызовов дополнительную логику, то это с моей точки зрения взорвёт рамки предназначенной для мидиатора задачи. Наверно всё же логика должна быть с самих модулях и модули через инъецированный медиатор работают с другими классами, которые вызывет инъецированный медиатор.
По крайней мере я так понял этот патерн (это не означает, что я понял правильно
)
"Как лучше передать информацию между модулями через медиатор или создать репозиторий и класс для него для сохранения и передачи инфы? "
Если требуется репозитория для хранения и переработки информации между модулями, то возможно для этого надо делать специально модель, которая тоже в конечном итоге будет инициализирована или использована медиаотором, так как я и говорил, что медиатора как посредника тоже нельзя перегружать вопросами, которые не касаются примитивного посредничества.
_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
если ты хочешь предотвратить любыми путями создание нескольких медиаторов, то делай сингельтон. Если тебя это не особо волнует, то и зингелтон не нужен.
"Допустимо ли логику поведения при получении сигнала размещать в самом классе модуля (подписанном на событие модуле) или ее вызовы(функции модуля получателя) лучше поместить в Медиатор, как полностью управляющий класс?"
Задача медиатора всего лишь быть посредником в коммуникации между объектами. Если засунуть туда кроме вызовов дополнительную логику, то это с моей точки зрения взорвёт рамки предназначенной для мидиатора задачи. Наверно всё же логика должна быть с самих модулях и модули через инъецированный медиатор работают с другими классами, которые вызывет инъецированный медиатор.
По крайней мере я так понял этот патерн (это не означает, что я понял правильно
)"Как лучше передать информацию между модулями через медиатор или создать репозиторий и класс для него для сохранения и передачи инфы? "
Если требуется репозитория для хранения и переработки информации между модулями, то возможно для этого надо делать специально модель, которая тоже в конечном итоге будет инициализирована или использована медиаотором, так как я и говорил, что медиатора как посредника тоже нельзя перегружать вопросами, которые не касаются примитивного посредничества.
_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
спасибо
Здесь расположена полная версия этой страницы.