#model-view-controller #design-patterns
Вопрос:
Каковы, на ваш взгляд, некоторые наилучшие методы организации взаимодействия между сложными компонентами?
Я говорю не о простых виджетах, таких как поле со списком или элемент управления сеткой, а о компонентах, которые состоят из нескольких виджетов и которые могут заслуживать самостоятельного модульного тестирования.
Не могли бы вы:
- Определите абстрактные интерфейсы для каждого компонента,
позвольте контроллеруподключить их с помощью внедрения зависимостей, чтобы они могли напрямую общаться друг с другом с помощью вызовов методов? Таким образом, компоненты осведомлены об интерфейсах других компонентов. - Определите события, которые может запускать каждый компонент, и
позвольте контроллерунапрямую подключать их друг к другу через прослушиватели событий? Таким образом, компоненты имеют обработчики событий, подключенные к приемникам событий других компонентов. - Определите абстрактные интерфейсы для каждого компонента, определите события, которые они могут запускать, и
позвольте контроллерупрослушивать все события и выполнять вызовы методов на интерфейсах? Таким образом, компоненты полностью не зависят от других компонентов. - Классическое применение шаблона наблюдателя?
- Что-нибудь еще?
Обновление: Я вычеркнул «пусть контроллер …» из #1-3, потому что в этих случаях не обязательно контроллер должен выполнять маршрутизацию/оркестровку. Это может быть сам Вид.
Я принял метод № 3 в недавнем проекте, и я был доволен разделением и индивидуальной проверяемостью компонентов. Тем не менее, у меня есть ощущение, что я мог бы упростить подключение компонентов. В моем случае объект основного представления должен добавить несколько прослушивателей событий для каждого компонента, а затем вызывать методы для соответствующих компонентов, иногда выполняя некоторую локальную обработку (например, разговаривая с моделью). Код для добавления обработчиков событий выглядит немного запутанным, и я особенно ищу чистый способ сделать это.
Ответ №1:
Вариант № 3 звучит как шаблон посредника и часто является лучшим подходом, когда логика обновления и связь между объектами сложны. Это также имеет дополнительное преимущество в том, что логика управления и инициализация остаются централизованными, что облегчает отслеживание и отладку подобных случаев.
Ответ №2:
Похоже, у вас есть знания, чтобы ответить на свой собственный вопрос по этому вопросу, но, возможно, вам просто не хватает уверенности, чтобы погрузиться в него. Вы просто исследуете или застряли где-то?
Я бы добавил, что еще одна вещь, которую вы можете сделать, — это разместить менеджер компонентов между всеми объектами, чтобы облегчить взаимодействие. В прошлом, когда я делал что-то подобное, объект управления заканчивал тем, что просто брал данные из каждого компонента, объединял данные вместе и передавал их модели как один большой запрос. У каждого из моих компонентов был делегат, которого они вызывали и в который передавали данные, и, конечно, реализация этого делегата была в моем менеджере компонентов.
Я также позволил этому объекту менеджера выступать в качестве прокси-сервера в сети, я ждал, пока сложность возрастет, прежде чем я присоединился к SRP и сделал эту ответственность своим собственным классом.
В принципе, все, что ты сказал, звучит хорошо. Я бы рекомендовал просто погрузиться и исследовать.