А надо ли вызывать этот флоу, или он на самом деле актуален только для первого логина, а релогин — это совсем другое?
Нет, не надо — это разные задачи. Которые можно описать единообразно.
С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.
И это правда. И тут имеет место tradeoff — консистентность против сиюминутной выгоды. На текущем проекте на данный момент первое выигрывает — но у меня нет оснований говорить что так будет всегда
Хм, можете показать пример чистого Rx, описывающий «последовательность» из стартового коммента — мне интересно, насколько это будет читабельно.
Вот кстати можно написать) Как раз завтра делаю доклад на тему того, как весь набор действий приложения инициируемых какой-нибудь кнопкой может быть завернут в единый реактивный пайплайн. Могу предложить Вам презентацию оного, вроде как он затрагивает более злые примеры, чем в статье, возможно это поможет ответить на вопрос
я легко и бегло это читаю, потому что я привык
Вот завтра как раз на докладе и узнаю :-) Простой ли это код, или просто привычный)
Ну вот здесь на самом деле вопрос — что такое одиночная операция.
Кнопка, скажем — не одиночная операция — а сигнал нажатий на нее
Логин — не одиночная операция — любой запрос тебе может вернуть 403, и ты зарелогинишься, вызвав при этом какой-то навешенный на это флоу.
И так далее.
Вообще с точки зрения реактивщины — почти все — стримы, сиречь множественные операции — а что одиночные — в общем-то и не стоит отдельного эффорта.
Пы-сы. Да, если ваш язык поддерживает async workflows… Ну мой язык, скажем, не поддерживает) и опять же с точки зрения реактивного программировния и прочих биндингов — все эти асинки-авэйты лишь частный случай преобразований control/data flow — и этим прекрасны.
Вообще из всех моих личных комплейнтов к реактивщине — она всегда читабельна. Но иногда несет избыточный бойлер с потерей производительности.
Да в общем-то низачем. RX он даже не про асинхронность, а про chaining — это способ консистентно и декларативно описать разнородную последовательность операций. Когда у тебя поток шлет лишь один value — это превращается в обычную future.
Иметь консистентный способ проводить преобразования этих самых фьюч и не заботиться о том, моментальная эта операция или растянутая во времени, синхронная или асинхронная.
Концепция биндинга экономит много времени на кофе и комментарии на хабре :-)
А достигнуть сходного качества организации кода можно и без RX.
В чем плюс RX в этом смысле — что когда появятся более настоящие RX задачи — они в строятся в остальной код таким образом, что никто этого и не заметит
чем больше используешь РАК, тем больше приходишь к тому, что его не просто сложно — а нельзя дебажить, отлаживать и т.п. и приходится продумывать другие паттерны повышения качества приложения. Например РАК — ооочень легко тестировать
Тогда вам, вероятно, следует ознакомиться еще лишний раз с тем, что такое косинус.
Есть наивное определение cos — отношения катета к гипотенузе, по сути функция (R+, R+) -> R[-1, 1] (из двух положительных действительных чисел в действительное на отрезке [-1, 1])
Оперировать двумя числами неудобно — поэтому (R+, R+) была заменена на R — угол. итого мы имеем функцию
cos® -> R[-1, 1]
Но ведь согласитесь, где вы видели прямоугольный треугольник с одним из углов равным -1345 градусам? Уже в этот момент мы отошли от наивного определения.
И вроде бы Success, но… фраза «А если завтра сменится поставщик БД»? Так почему бы завтра и не решить этот вопрос?
Гораздо неудобнее будет, если он никогда не сменится, а время потрачено.
Нарушаем. этот класс «Считает И делегирует» а не только считает и только делегирует. На мой взгляд, корректно этот вопрос решает FRP — добавить третий метод в интерфейс класса — который будет возвращать стрим простых чисел — на который на другом уровне мы можем уже навесить печать — ибо разные задачи.
А необходимость передавать управления внутри шага алгоритма вызвана лишь наложенными самостоятельно (не необходимыми) ограничениями о том, что мы должны вернуть массив И напечатать.
Учитывая то, что мне пока ни разу не довелось натыкаться на не то что одинаковые интерпретации MVVM в разных проектах, но даже и MVC — то вполне могут оказаться полезными знаниями (ну или на самом деле очередной интепретацией MVVM :-) ) )
В obj-c не сделаешь миксинов, как вы и описали — протоколов не привязанных к типу.
Зачем они могут быть нужны?
Самый явный пример — уточнение дженериков.
Если не вдаваться в библиотеки (мы, например, очень любим писать расширения к generic сущности SignalProducer из ReactiveCocoa) — то в коде встречались расширения на Optional на конкретные типы.
Пример — единообразный анврап Optional объекта (замена конструкции value = optional ?? fallbackValue на какую-то единообразную optional.unwrap, которая предпочтительнее, чем unwrap(optional)). Для того чтобы его написать — нужно уметь строить fallbackValue — что можно сделать только для какого-то набора типов.
Для этого неплохо подходит реактивщина и DI — в одном месте создается сервис, который содержит в себе ваши часто изменяющиеся данные — а дальше во все заинтересованные части приложения рассовываются стримы — иными словами неизменяемые «обсерверы», которые сработают в момент, когда эти данные обновились — и — отдельно — в заинтересованные сущности, которые могут менять эти данные — инжектятся «синки» — иными словами лямбды, в которые можно засунуть новое значение.
Таким образом у нас нет способа получить значение этих данных, кроме как среагировав на него и нет способа изменить его, кроме как через этот синк.
Хранить же эти данные можно и так как описали вы. Важно — как вы предоставляете доступ к этим данным.
Важно, что в синглтоне — потому что синглтон — это shared state протянутый через все приложение.
Если ты изменил этот стейт — то не факт что все потребители этого синглтона ожидают это изменение и правильно на него среагируют. И проверить, что ты ничего не сломал можно только либо «регрессионным тестированием» мануальных QA, либо верой, что «я же четкий, я ж не сломал»
В этом и фундаментальное отличие синглтона от несинглтона — область видимости обычного объекта позволяет локализовать потенциальные места для возникновения ошибки, а синглтона — нет.
Чтоб вам этот синглтон и классы его использующие покрыть регрессионными тестами, чтобы оценили, почему плохо.
Удобно — очень удобно, конечно. Но это код, который годится только на «написать и забыть» — потому что гарантировать, что
а. он работает
б. я что-то изменил, а что-то там где-то еще не отломалось — не просто сложно, а практически невозможно.
То есть код для фриланса, с которым, конечно, можно мириться, но гордиться и защищать — не стоит)
Не думаю, что прямо таки общие корни — большинство новейших языков неслабо между собой похожи. Скорее они пытаются решить одни и те же наболевшие вопросы.
P.S. я тоже жду, что (когда) откроют исходники — так как мне видится неплохое будущее у этого языка — и я бы хотел, чтобы он развивался шире
Вот, вы приводите как раз превосходные примеры атомарных моделей. В которых нам интересно изменение всего состояния авторизации, либо же сети, а не одного из 5 полей, что значительно упрощает работу по организации подписки — как через Notification Center, так и через KVO или же множественное делегирование, реализованное, как-нибудь иначе.
У меня вызывает вопросы как раз необходимость дробления модели до ее полей.
Вообще, стоит архитектурно очень качественно подумать — а правильно ли организованы потоки данных в приложении, если есть изменяемая модель с несколькими слушателями. Необходимость такого — это, скорее, исключение, чем правило.
Могу порекомендовать подробно поизучать ReactiveCocoa и прочие порты Rx — оно, конечно, оверкилл с точки зрения производительности — но при осознанном использовнии невероятно упрощает поддержку кода бизнес-слоя.
Нет, не надо — это разные задачи. Которые можно описать единообразно.
И это правда. И тут имеет место tradeoff — консистентность против сиюминутной выгоды. На текущем проекте на данный момент первое выигрывает — но у меня нет оснований говорить что так будет всегда
Вот кстати можно написать) Как раз завтра делаю доклад на тему того, как весь набор действий приложения инициируемых какой-нибудь кнопкой может быть завернут в единый реактивный пайплайн. Могу предложить Вам презентацию оного, вроде как он затрагивает более злые примеры, чем в статье, возможно это поможет ответить на вопрос
Вот завтра как раз на докладе и узнаю :-) Простой ли это код, или просто привычный)
Кнопка, скажем — не одиночная операция — а сигнал нажатий на нее
Логин — не одиночная операция — любой запрос тебе может вернуть 403, и ты зарелогинишься, вызвав при этом какой-то навешенный на это флоу.
И так далее.
Вообще с точки зрения реактивщины — почти все — стримы, сиречь множественные операции — а что одиночные — в общем-то и не стоит отдельного эффорта.
Пы-сы. Да, если ваш язык поддерживает async workflows… Ну мой язык, скажем, не поддерживает) и опять же с точки зрения реактивного программировния и прочих биндингов — все эти асинки-авэйты лишь частный случай преобразований control/data flow — и этим прекрасны.
Вообще из всех моих личных комплейнтов к реактивщине — она всегда читабельна. Но иногда несет избыточный бойлер с потерей производительности.
Иметь консистентный способ проводить преобразования этих самых фьюч и не заботиться о том, моментальная эта операция или растянутая во времени, синхронная или асинхронная.
Концепция биндинга экономит много времени на кофе и комментарии на хабре :-)
А достигнуть сходного качества организации кода можно и без RX.
В чем плюс RX в этом смысле — что когда появятся более настоящие RX задачи — они в строятся в остальной код таким образом, что никто этого и не заметит
Есть наивное определение cos — отношения катета к гипотенузе, по сути функция (R+, R+) -> R[-1, 1] (из двух положительных действительных чисел в действительное на отрезке [-1, 1])
Оперировать двумя числами неудобно — поэтому (R+, R+) была заменена на R — угол. итого мы имеем функцию
cos® -> R[-1, 1]
Но ведь согласитесь, где вы видели прямоугольный треугольник с одним из углов равным -1345 градусам? Уже в этот момент мы отошли от наивного определения.
После того, как в математике появились комплексные числа — все стандартные функции были расширены на комплексную плоскость. В том числе и тригонометрические — и оказалось, что cos© уже не попадает в R[-1, 1] и может принимать сколь угодно большие значения — в том числе и -2.
Гораздо неудобнее будет, если он никогда не сменится, а время потрачено.
А необходимость передавать управления внутри шага алгоритма вызвана лишь наложенными самостоятельно (не необходимыми) ограничениями о том, что мы должны вернуть массив И напечатать.
Зачем они могут быть нужны?
Самый явный пример — уточнение дженериков.
Если не вдаваться в библиотеки (мы, например, очень любим писать расширения к generic сущности SignalProducer из ReactiveCocoa) — то в коде встречались расширения на Optional на конкретные типы.
Пример — единообразный анврап Optional объекта (замена конструкции value = optional ?? fallbackValue на какую-то единообразную optional.unwrap, которая предпочтительнее, чем unwrap(optional)). Для того чтобы его написать — нужно уметь строить fallbackValue — что можно сделать только для какого-то набора типов.
Таким образом у нас нет способа получить значение этих данных, кроме как среагировав на него и нет способа изменить его, кроме как через этот синк.
Хранить же эти данные можно и так как описали вы. Важно — как вы предоставляете доступ к этим данным.
Если ты изменил этот стейт — то не факт что все потребители этого синглтона ожидают это изменение и правильно на него среагируют. И проверить, что ты ничего не сломал можно только либо «регрессионным тестированием» мануальных QA, либо верой, что «я же четкий, я ж не сломал»
В этом и фундаментальное отличие синглтона от несинглтона — область видимости обычного объекта позволяет локализовать потенциальные места для возникновения ошибки, а синглтона — нет.
Удобно — очень удобно, конечно. Но это код, который годится только на «написать и забыть» — потому что гарантировать, что
а. он работает
б. я что-то изменил, а что-то там где-то еще не отломалось — не просто сложно, а практически невозможно.
То есть код для фриланса, с которым, конечно, можно мириться, но гордиться и защищать — не стоит)
P.S. я тоже жду, что (когда) откроют исходники — так как мне видится неплохое будущее у этого языка — и я бы хотел, чтобы он развивался шире
А все «ядро компании» в заметной доле? Или кто-то таки за зарплату работает по столько времени с гордостью?
У меня вызывает вопросы как раз необходимость дробления модели до ее полей.
Могу порекомендовать подробно поизучать ReactiveCocoa и прочие порты Rx — оно, конечно, оверкилл с точки зрения производительности — но при осознанном использовнии невероятно упрощает поддержку кода бизнес-слоя.