А нет случаем замеров насколько это медленнее?

У меня получилось в 6-7 раз

Мокать у тебя вообще нормально не выйдет ;) Но стабы писать можно.

А если объект обработки один раз создавать?

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

Мне кажется тут больше концептуальная проблема. Если реально пытаться это хорошо применять - придется всяких общих модулей и обработок тысячи плодить

Я скорее всего не достаточно прогрессивен для этого чата, но выскажусь.
у любой доработки даже самой малюсенькой есть 2 цены: цена разработки и цена владения, и за любую хотелку есть кошелек из которого идет транш в виде ЗП или платы за усугу.
В том мире, котором я живу есть 3 подхода из того что я видел:
1) Набросать костылей в кучу и потрясти. Цена разработки минимальна, Цена владения - как повезет, часто высокая.
2) Разработать ориентируясь на текущие стандарты подсмотрев на вендора и впитав текущую политику подкоркой. Стоимость разработки как правило высока. Стоимость владения - умеренная.
3) Разработать используя какие либо инновационные разработки ну по типу той реализации ООП. Стоимость разработки высокая. Стоимость владения Высокая.
Объясню по стоимости владения:
п 1) метатели костылей и те кто понимает код метателей костылей - оцень ценный ресурс, и эта кадровая дырка может висеть долго.
п 2) Средней руки разработчика найти можно всегда.
п 3) После ухода новатора найти нового возможно и не получится. Я имел удовольствие работать с таким кодом, так себе.
В том мире, котором я живу - люди с 5-10-15 летним опытом разыменовывают поля типа "любая ссылка", в цикле делают 50-100 тысяч раз НайтиПоНаименованию и так далее, продолжать могу очень долго.
Одно радует, что общий уровень по тихоньку но растет. Когда нибудь п3 будет стандартом, я на это надеюсь...
К чему все это: когда я оцениваю задачу - я всегда клиенту предлагаю на выбор 3 варианта. И работаю только с теми кто выберет вариант - 2.
Я несу ответственность не только за сам код, но и за то что бы его было легко поддерживать. Не в моих интересах посадить клиента на "бабки".

Даже если скажем полседним параметром протаскивать Менеджер/обработку?

Есть же протаскивание структуры с миллионом парамеров =(

Но ведь в этом ничего плохого нет по идее
Не хватает наборов, чтобы набрать охапку общих модулей, а все остальные скрыть

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

Блин, криво сформулировал

Тема щепетильная да. Я тоже стараюсь всегда показывать как будет владеть дешевле. Но и как разрабатыыать дешевле. Факт в том, что не все инженерные практики нужны. А что нудно команда решать должна для себя.

Жеваные кролики, увлекся спорами и в итоге на изучение андроида только утро и обед потратил. А мне еще дофига изучать. Пойду я пожалуй)

Я больше про серверный код, интеграции, к примеру

андроид для проф 3 редакции тебе в помощь, даже на русском)

?

Поработаешь год-два в мобилках и Android превратится в запрос к серверу + вывести пользователю =))

Значит пойду в фуллстек бек + андроид (а лучше флаттер, к тому времени взлетит надеюсь)

+ когда устраиваешься на работу собеседование не только для тебя, но и для работодателя. И за тобой будет выбор, либо прогрессировать и расти в цене, либо деградировать с костыльщиками.