для чего я так запарился. У меня есть data который обращается в другие модули(remote, cahce) и data не знает про то какие исключения могут быть в remote. Для этого создаю свои исключения в дате, через интерцептор конвертирую в нужные. Но вытекает следующая проблема как ошибку конвертировать в ошибку понятную для domain.  Кажется так можно, только что понял,

.onErrorReturn { throw it.toDomain() }

. А в Domain уже проще все, там хоть в  sealed class со своими success, failure  или во что угодно.

спасибо

Реализую сейчас кастомный View компонент - диаграммму Ганта
В ней есть 4 вьюхи - верхний левый статичный угол, закрепленные строки, хакрепленный столбцы и сама таблицы
Я реализовал API аналогичный RecyclerView, чтобы сохранить расширяемость
Для каждого из 4-х компонентов у меня есть свой ViewHolder и соответственно весь необходимый набор методов: onCreateViewHolder(), onBindViewHolder(), getItemViewType() и так далее
Получается, что в едином адаптере у меня 8 абстрактных методов и много open методов
Стоит ли это всё оставить в одном адаптере или лучше разделить на 4 раздельных адаптера? Как можно упростить API, оставив расширяемость, но при этом не плодя адаптеры и ViewHolder’ы?

Разбить на 4 разных делегат адаптера, и потом собрать их в 1 месте для дефолт,  delegateAdapter можно написать свой или использовать либу от Дорфмана http://hannesdorfmann.com/android/adapter-delegates

А с точки зрения API для пользователя будет 1 адаптер, верно?

Да

Стоит ли так делать, если в адаптере нет никакой логики?

Ну по мне не удобно. Я бы просто хотел в адаптер кинуть лист с sealed классом, и адаптер сам бы все разрулил.

Наследования тут лишние, если тебе ещё 2-3 viewType и ты начнёшь путаться, а измения могут быть всегда

ты делаешь все “абстрактно”, но при этом все прибито гвоздями)

Могу свой пет скинуть с делегат адаптером , если надо пиши в личку

зачем тут дженерики, если у тебя есть отдельный метод для каждого типа? Да и сами дженерики тут не используеются

В плане, они-то тут неужны

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

Ну это не весь код

T: MyClass

fun myFunction(holder: T)

Это что-то типо адаптера у Recycler

довольно бесполезная конструкция в твоем случае

fun myFunction(holder: MyClass)

так же примет наследников, как аргумент