ООП и функциональное программирование вместе в Котлине (Дизайн)

Question

Я недавно начал с Kotlin для разработки под Android. Он является объектно-ориентированным, но также поддерживает функциональные конструкции, такие как лямды, монады и т. Д.

Я думаю об использовании преимуществ обоих миров. Я хотел бы спроектировать слои моего приложения следующим образом:

------ ООП ----------- || ----------------- Функциональный -------------------------- ---------------------------
Вид -> ViewModel -> Варианты использования -> Хранилища -> Уровень данных / Источники данных -> Сеть

Некоторые рекомендации, которым я собираюсь следовать:

1. Состояние моего приложения будет сохранено в слое viewmodel и отображено в слое view.

2. Функциональные слои будут без состояния, содержащие только чистые функции. Он переводит предоставленный ввод в требуемый вывод. Им не нужно беспокоиться о среде, в которой они работают, а также о том, что они должны запускать контекст меньше.

3. Ни один компонент Android не должен входить в функциональный слой. Он предназначен только для бизнес-логики

4. Слой Viewmodel содержит логику приложения и логику представления. Состояние отображается как Livedata в этом слое

5. Представления подписываются на liveata и обновляют представление при получении уведомления.

6. Варианты использования - это единицы бизнес-логики

7. Viewmodel передаст копию объекта неизменного состояния в слой usecase.

8. Связь между viewmodel и usecases будет выгружена в фоновый поток и обратная связь в потоке пользовательского интерфейса, так что мне не нужно беспокоиться о фоновых потоках, затрагивающих мои Views.

9. UsecaseExecutor следует использовать для выполнения любого варианта использования, поскольку он выполняет разгрузку с использованием сопрограмм

10. Все чистые функции должны быть проверены модулем

11. Хранилища абстрагируют источники данных

12. Сетевой уровень свяжется с остальными службами, а уровень данных получит ответ JSON / XML, проанализирует и предоставит обратно либо соответствующие модели, либо ошибку.

13. Все функции, которые могут выдавать ошибки, должны иметь тип возвращаемого значения: Монета

14. Отказ должен быть закрытым классом

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

Answer 1

Если вы хотите использовать функциональные возможности в kotlin, вам нужно добавить функциональную библиотеку, такую ​​как стрелка, потому что ядро ​​kotlin не предоставляет многих базовых функциональных функций, таких как, например, монада Either, как вы сказали в пункте 13, оптика и некоторые другие. , Кроме этого, я думаю, что дизайн хороший