это не эталон - никто не заставляет так делать

просто это правило хорошего тона

Вам же написали, что навигация это бизнес логика и ее как раз нужно будет тестировать.Так же иногда нужно сделать какой-то запрос, потом на основании результата выполнить навигацию, вы же не будете всю эту логику держать в адаптере?

да не - и так можно, если сильно хочется ) просто это очень сильно больно будет потом

Как уже написали, можно то и в активити все делать, но зачем?)

Там просто по нажатии на кнопку делается навигация, никакой другой логики туда естественно добавлять не нужно. Если логика сложнее то надо вытащить в Активность

ну ... иногда так хочется или проще

например если делают MVP (не путать с архитектурой)...

Адаптер перестаёт быть переиспользуемым, если встраивать в него навигацию.

Как писал выше, в таком случае я естественно в адаптере не буду делать, а вынесу в активность.
Просто для чистоты кода я так сделал. Но в итоге получил фидбек мол "нарушение Clean", прямо катастрофа))

Это ударит по маштабируемости и переиспользовании

это катастрофа - если вы работаете не один, и если потом кто то за вами будет дописывать код. Ну или у вас просто демо проект (типа на коленке)

про переиспользование адаптеров уже выше написали...

Почему то я вижу во всем обсуждении следующий вопрос. "Зачем мне придерживаться архитектуры и писать лишний код, если задача простая и ее можно решить быстрее, написав на прямую меньше кода?" Если есть такой вопрос, давай попробуем ответить на него. Что скажешь?

Можно приводить много пустых доводов типа, что если потом будут переписывать другие, что если придется переделывать, ну давай тогда все писать в Активити.
Во первых не стоит забывать что существуют эгоисты и нам пофиг, что от этого будут плеваться другие, зато я напишу быстрее.
Во-вторых переделки это проблемы завтрашних нас. Не забываем что есть эгоисты и нам важен я только здесь и сейчас, а не другой завтрашний я.
Ну и я же не все пишу в Активити, а только этот момент не по архитектуре, чтобы написать быстрее.
Это все слабые доводы и сколько вижу этих споров еще ни разу не видел, чтобы человек не ушел с миной "просто так надо, потому что кто-то так сказал. Ну Окай".

Давай возьмем главный аргумент против архитектуры. Это скорость написания функционала. Думать и писать больше кода, значит замедлить разработку.
Вся прелесть архитектуры в том, что при получении четкого понимания о том как и что писать, ты перестаешь задумываться над этим. Соответственно из расходов времени убираем пункт с думками и копанием правильного ответа на stackoverflow.

Остается пункт с написанием кода. Со временем, каждый начинает печатать быстрее, изучает различные горячие клавиши. А еще есть такая вещь как шаблоны. А с учетом, что мы уже заранее нарыли и поняли что такое архитектура, мы можем насоздавать для нее своих шаблонов, которые еще больше нас ускорят.

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

Но этим могут похвастаться опытные разработчики. А что делать новичкам? Тратить время на поиск, осмысление и написание архитектуры, чтобы вырасти до уровня опытных. Иначе как еще можно понять архитектуру, если не писать ее снова и снова и снова. Ни кто не сможет никакими словами вложить в тебя понимание. Только сухая информация, осознать которую необходимо самому.

Большинство  компаний имеют свой кодстайл и требования, если же это тестовое задания, то наверное от тебя хотели просто понимания основ clean и Solid, если подумать то навигация в адаптер нарушает принцип  Solid (адаптер не должен отвечать за переходы), погуглил какие проблемы решаются если придерживаться этих принципов

@devStep
Вы наверное хотели сделать проще и короче.
В таких моментах, очень важно правильно ответить на вопрос, если он был канеш)

Этот тот момент, когда  знание принципа помогло бы, не вникать в подробности.
Поэтому в чате не тратят время и просто обращают внимание на правило, потому что у них есть опыт, а  убеждать вас в том что нарушение сего не есть хорошо для них скорее всего очевидность. И это тоже ускоряет разработку верно? как вы и писал выше.
Вам надо дать какой-нить пример.

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

Пример: Список контактов, ContactsAdapter.
Есть навконтроллер внутри. По клику переходит например на ContactInfoScreen и показывает инфу о контакте, вся информация есть уже или передаем id - все ок.
Потом другому человеку пришла задача, написать звонки CallScreen например. Он смотрит на мокапы (дизайн) и там такой же список контактов. Супер! Ведь паттерн адаптер идеален здесь.
Ну максимум type другой подкину и покажу. Оценю я задачу на 12, по факту 30 мин делов. И идет чилить.
Пришло время делать, смотрит, на click по элементу надо делать переход на другой экран -> CallScreen ну лан пропишу логику в адаптере думает он. Type ж нет, пофиг context instance of погнали. И всё бы хорошо, ток потом оказалось надо чекнуть статус сети предварительно, чтоб не делать лишний переход на экран звонка.  Такс...
Прокину в адаптер какой-нить InternetConnectionHelper? Ок, есть какой-то синглтон(object), фух спасение.
А потом смена бизнесса, по клику на контакт нам ненадо делать переход сразу, мы вначале покажем диалог с выбором, а в диалоге будут все дейсвтия позвонить, удалить контакт и на разных экранах будут разные кнопки действия.  И уже от их нажатий будем чекать InternetConnectionHelper , но ток для CallScreen. Конец 😀.
Это все выдумано но вполне себе мб реальным кейсом. Более чем. И это ток 2 роута.
И кто бы что не говорил, какой бы Agile не был в тимах. 1 фиг все любят менять задачи, даже если у вас супер планирование!
Уже не говоря о стартапчиках и тд.

В мессах список контаков, переиспользуется в большом кол-ве мест. Выбор пользоватлея, создания группы, канала, групповые звонки, фильтры, поиск, редактирование, посты, истории и тд. Возможно в каких-то моментах лучше сделать разные адаптеры. А мб и во всех, мб у вас уже в команде есть либа со списками и это очень быстро.
Но это простой пример и даже здесь видно, что абстракция на клики чище.

Бонусом.
Адаптер без доп зависимостей будет проще тестировать. Ваще возможно нормально тестировать др от друга. Иначе в тестах тоже будет творится ад.
Расширение адаптера будет меньше задевать другой код, и вероятность, чтот сломать. Ну это очевидный + абстракий, уменшить связность.

Вы в архитектурном чатике. Вы сделали ошибку, нарушили Solid и Clean.
Ну пускай меня закидают тапками тут, но лично для меня важнее писать простой и читаемый код без лишних абстракций.
и потом уже расширять. Со временем одно другому не мешает, но люди разные. Проекты тоже.

Может быть это и была ваша ситуация и вы все сделали верно ))

Интересно работает ли комплимент сендвич

я 5+ ) Могу сказать, что в адаптере плохо использовать всё, что угодно, что не имеет отношения к построению ресайклера. Т.е. плохо использовать 1) логику (любую, даже логику построения ресайклера) 2) навигацию 3) синглтоны 4) иннер классы

В идеале адаптер это отдельный класс, который использует отдельные классы холдеров, которые максимум могут оперировать каллбэками. И вся эта совокупность просто наполняет ресайклер элементами и максимум (каллбэки) добавляет ему немного поведения

На прошлом проекте я адаптеры вообще сам не писал, я написал себе логику, которая клепала адаптеры под капотом ) Я просто скармливал ресайклеру элементы и он сам подсовывал все нужные лейауты итд

Обосную так - когда приходит пора рефакторинга - а она придёт, бизнес тупо может попросить поменять логику (но обычно бывает значительно более обширные задачи) - тебе придётся выскребать эту логику из десятка классов, каллбэков и так далее. Навигацию - роутеру (им может быть вью модел), бизнес логику - медиатору. Адаптеру - только отрисовку. Тогда это будет гибкая система, которую значительно легче адаптировать под последующие нужды