"Wizard", где каждый экран содержит только релевантные поля, и не более 5-7.
Например, на одном экране данные отправителя, на другом - адрес отправителя, на третьем - данные получателя, на четвертом - адрес получателя и т.д. + продумает очередность их появления и др. (Поэтому я и отметил, что вероятнее всего у вас проблемы с UI/UX)
Если вас интересует как подвести ваш строитель (и собственно сам процесс его постройки) под юнит тесты - это переместить его в презентер.
Данные с полей передавать на выбор: одним сеттером с набором нужных аргументов, либо каждое значение отдельным сеттером - зависит от того, что вам ближе.
10-20 полей = сеттер с 10-20-ю аргументами или 10-20 сеттеров.
1. Не нравится? Отличный повод зарефакторить как UI/UX, так и код соответственно.
2. Не хочется? Ну тогда собирайте как сейчас, в ui слое.
3. Хотите чистоту да под тесты? передавайте в презентер через сеттеры. Ну и далее рекурсивно к п. 1
Дилемма как она есть, и никакой магии.
Еще не плохо бы посмотреть, может у вас где-то среди валидации ввода зашиты условия бизнес-логики? Если так, то "по чистоте" их нужно выносить из ui слоя в слой интерактора, и валидировать там. А это уже само по-себе подразумевает отдельные текствотчеры на поля с передачей ввода на валидацию в интерактор через презентер...
Я, например, так и делаю в таких случаях.
А если на экране много всего, и дизайну нужно именно так, то иногда логически разбиваю его на несколько независимых частей в стремлении к SRP.
То есть на одном экране работают одновременно несколько презентеров - каждый со своей частью экрана. Вводимые данные публикуются на общий интерактор, который упаковывает их в нужный объект и передает гейтвею для отправки на сервер по нажатию кнопки "Далее" в своем презентере.
В некоторых случаях такая разбивка значительно упрощает код и тесты этих презентеров - они вместе оказываются намного проще и легче, чем если бы были слиты в один монструозный презентер.
Ну в общем, как-то так.
Большое спасибо за развернутый ответ.
Обсуждают сегодня