Разработка программного обеспечения настолько близка к искусству, насколько я смог индивидуально подойти к вопросу о том, как можно структурировать приложение. Не существует единственного правильного способа что-то сделать, и в зависимости от потребностей вашего приложения вы можете смешивать и подбирать решения для разных проблем, как художник с кистью, любовно взмахивающей своим холстом.
Подобно тому, как художники имеют в своем распоряжении различные инструменты, чтобы вызвать тот эмоциональный отклик, который они хотят от своей аудитории, акриловые или масляные краски, возможно, даже цифровые, разработчики программного обеспечения также используют с точки зрения того, как они хотят управлять презентацией своих приложений и бизнесом. логика.
Я лично влюбился в функциональное реактивное программирование, и я предпочитаю RxJava. Сейчас я склонен визуализировать свои приложения как потоки состояния, данных или даже взаимодействий с пользовательским интерфейсом. В качестве дополнительного преимущества я могу легко сопоставить состояние своего приложения с состоянием пользовательского интерфейса, передать его своим реактивным представлениям, и они довольно легко трансформируются в новое состояние, которое они должны представлять. Я чувствую себя Мерлином, честно говоря, я подталкиваю новое состояние и альт, Вид знает, как на это реагировать. До RxJava мой механизм был более императивным. Если состояние this, то View должен выглядеть так, иначе, если состояние this, то ...
Для компьютера это не имеет большого значения. В любом случае он делает то же самое, но я считаю, что версию с реактивным потоком намного приятнее читать и переваривать. Вот где я нахожу сопрограммы немного «ага».
Мое понимание сопрограммы в Котлине можно резюмировать следующим образом:
«Упростите путаницу и логику асинхронного программирования, превратив обратные вызовы в блоки кода, которые читаются приятно и синхронно, но при этом работают асинхронно»
Это действительно хорошо, но мой код по-прежнему асинхронный, он просто выглядит синхронным. Это также скорее императивный наклон. Я снова работаю с блоками кода и телами методов, у меня нет любимой абстракции потока. Скажем, я вызываю метод в сопрограмме, которая возвращает некоторый тип A, соответствующий состоянию пользовательского интерфейса A. Если возникает исключение и это исключение соответствует состоянию пользовательского интерфейса B, которое требует дальнейшей асинхронной обработки, мне нужно вызвать другую сопрограмму с исключением, тогда получить состояние пользовательского интерфейса B. Если, однако, я получил тип A в реактивном потоке, я могу с помощью RxJava onError возобновить какой-либо другой реактивный поток, который сопоставит мое исключение с состоянием пользовательского интерфейса B. лаконичный. Мой код реактивный, как мне нравится.
Я программирую в основном на Java и Javascript. Для меня сопрограммы в Kotlin во многом похожи на async / await в Javascript, и я не особо забочусь о них в Javascript. Я предпочитаю обещания, так как если результат обещания требует дополнительной обработки, я могу просто вернуть другое обещание, которое в конечном итоге вернет конечное состояние, которое я хочу.
Вся потоковая парадигма и легкое преобразование объектов от одного типа к другому, будь то в Java с RxJava или в Javascript с обещаниями в node.js или RxJs для Angular, действительно хорошо подходят моему мастеру программного обеспечения. Сопрограммы хороши тем, что они хорошо работают с RxJava, и больший выбор - неплохая вещь, но я не обязательно хочу смешивать их, как если бы я рисовал, я бы не хотел смешивать акварель и масляную краску. . Ну, если этого не требовала моя картина.
Так что да, корутины Kotlin хороши, я просто не в восторге от них.
