@DevStep Вы наверное хотели сделать проще и короче. В таких моментах,

очень важно правильно ответить на вопрос, если он был канеш)

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

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

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

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

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

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

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

Блин спасибо, ваш ответ просто нечно)). Да согласен, но ведь можно сказать мол так лучше не делай, ну я юы объяснил, а тип просто всяз фидбек написал и гуляй вася. пзц Обидно