Актуально в случае, когда `username` и `hasUsername` не коррелируют друг с другом. Если значения самодостаточны, несомненно стоит использовать что-то из «Отряда булевых флажков».
Если эти вещи коррелируют друг с другом, надо сделать sealed class и выразить это через его состояния. В любом другом случае догодаться об их взаимосвязи невозможно
Не совсем понял Вашу идею. Могу ли попросить описать более подробно?
Есть публичный интерфейс, есть метод, в который его можно передать. По какой то неведомой логике автор этой поделки считает, что объявлять собственные экземпляры классов нельзя. Как об этом должны догодаться другие разрабы — фиг его знает.
Нормальные решения.
1) объявить интерфейс Sealed классом, закрыть таким образом возможность наследования
2) сделать абстрактный класс с таким же закрытым для переопределения конструктором
3) использовать новоязовский sealed interface как в п.1
4) убрать вообще конкретную реализацию, сделать enum ValidateType. Объявить в рамках него статический метод
Это тот случай, когда разработчик втыкает любимые паттерны проектироавния с пользой и без пользы. Разлепить состояние письма и состояние уведомления не позволила религия, поэтому будем есть кактус.
Одно состояние
На самом деле конструкция из примера обладает вполне конкретным смыслом
data class User(
val username: String?
val hasUsername: Boolean
)
если hasUserName выставлен, предлагать заполнить поле не нужно, независимо от того, есть там значение или нет.
Если флаг выставлен, то даже если имя хранится, предложить все равно стоит — допустим, это имя было сгенерировано по умолчанию.
Уменьшение области видимости
Костыль же.
Можно сделать более очевидные решения в виде абстрактного класса, sealed класса. А теперь еще и sealed интерфейсы будут. В конце концов, заменить передачу валидотара на передачу enum. А клиенту предоставьте статическую функцию, validate с дополнительным параметром type.
Я бы дополнил, что статья скорее про то, как заменить код RXJava на связку Coroutines + Flow.
Но на самом деле корутины позволяют писать код по другим парадигмам, и стараться придерживаться функционального подхода из RX вовсе не обязательно. Серия статей от Елизарова (не конкретная из статьи, а очень многие за последнций год) очень хорошо показывает, что не обязательно все так усложнять
Некорректное сравнение. RX, как и Flow, происходит от Observable шаблона + ФП программирования.
— RX пошел в сторону фп, получив сотни функций преобразования
— Coroutines Flow расширяет контроль состояния, продолжая идею самих корутин
Это два подхода, порожденных observable шаблоном, но ориентированных на разный результат.
П.С. Имхо, в реальных системах подход Flow более жизнеспособен, т.к. в конечном итоге все упирается именно в контроль состояния. Абстрактно чистое фп возможно чисто теоретически — на деле же мы просто отдаем контроль состояния на сторону. Flows дают более прозрачную картину
Можно конечно, но вопрос адресности. Я думаю всякие Spring разработчики даже не в курсе, чегой-то вам понадобилось (исходя из первого сообщения в этой ветке).
Надо, но это не проблема flow)
Сейчас разрабатывается lifecycle экстеншн для этого. но пока надо делать это вручную. В местах удаления с экрана, убивать и скоуп.
Жду продолжения, когда автор осознает, что полудохлыми копиями являются не только некоторые отечественные стартапы, но и все мировые. Определенно это открытие перевернет чей то хотя бы один внутренний мир.
я бы с вами согласился, но вот в комплекте к айфону идет адаптер на type-c. И вот их свободных, у меня только один (ноутбук не считается, медленная слишком зарядка выходит).
95 процентов упомянутых вами зарядок в мире бесполезны для этого провода. И тут только в магазин, или за проводом, или за зарядкой.
даже родных запядок эппла с type C на конце исчезающе мало.
Но унификация разъема, наверно, не приведет к уменьшению количества проводов и углеродного следа.
Без наушников смартфоном можно пользоваться, а вот без зарядного устройства — нельзя.
Еще можно посмотреть в сторону заявления их руководства о том, что в мире существует множество зарядок других производителей — а разрешается ли вообще по условиям гарантии заряжать айфоны от чего-то не эпплового.
Вообще уже пора уменьшить углеродный след еще больше, исключив из комплекта поставки аккумулятор, процессор, экран и все остальное — получается, что сама компания супер экологичная, и все выбросы на совести у юзеров — хочешь быть экологичным, но пользоваться эппл — просто купи пустую коробку.
Текс, ну давайте по пунктам
— Амазон ли, Билл Гейтс, Билли Айлиш — без разницы. По моим условиям груши бесплатны сами по себе.
— То что слоган лживый — вообще никак ко мне не относится. Их обман на их совести
— а вот приписывание меня в авторы это вопрос. Если по лицензии я просил нахваливать меня, поедая полосатые груши — тогда все верно. И я могу подать в суд за заведомо ложную информацию, но не за то, что мне не дали денег (я и не прошу по своим условиям).
— Если же меня не указывают — опять же, могу идти в суд, если докажу, что груши мои. А могу и не идти — это мое субьективное решение, и мнение бабушек с лавочки меня не волнует
— Мнение бабушек с лавочки: «смотри-ка, а нашего Guitariz обул не кто-то там, а сам Билли Гейтс! Ну не то чтобы обул, просто мы так называем свое субьективное восприятие действий, к нам не относящихся. Да что там, мы ж бабки, у нас все девки — проститутки, а парни — наркоманы. А раз так, значит иди и доказывай, что не наркоман».
Если эти вещи коррелируют друг с другом, надо сделать sealed class и выразить это через его состояния. В любом другом случае догодаться об их взаимосвязи невозможно
Есть публичный интерфейс, есть метод, в который его можно передать. По какой то неведомой логике автор этой поделки считает, что объявлять собственные экземпляры классов нельзя. Как об этом должны догодаться другие разрабы — фиг его знает.
Нормальные решения.
1) объявить интерфейс Sealed классом, закрыть таким образом возможность наследования
2) сделать абстрактный класс с таким же закрытым для переопределения конструктором
3) использовать новоязовский sealed interface как в п.1
4) убрать вообще конкретную реализацию, сделать enum ValidateType. Объявить в рамках него статический метод
И это все 4 регламентированых языком способа убрать наследование. В статье же один костыль меняется на другой, еще более извращенный.
Это тот случай, когда разработчик втыкает любимые паттерны проектироавния с пользой и без пользы. Разлепить состояние письма и состояние уведомления не позволила религия, поэтому будем есть кактус.
На самом деле конструкция из примера обладает вполне конкретным смыслом
если hasUserName выставлен, предлагать заполнить поле не нужно, независимо от того, есть там значение или нет.
Если флаг выставлен, то даже если имя хранится, предложить все равно стоит — допустим, это имя было сгенерировано по умолчанию.
Костыль же.
Можно сделать более очевидные решения в виде абстрактного класса, sealed класса. А теперь еще и sealed интерфейсы будут. В конце концов, заменить передачу валидотара на передачу enum. А клиенту предоставьте статическую функцию, validate с дополнительным параметром type.
Но на самом деле корутины позволяют писать код по другим парадигмам, и стараться придерживаться функционального подхода из RX вовсе не обязательно.
Серия статей от Елизарова (не конкретная из статьи, а очень многие за последнций год) очень хорошо показывает, что не обязательно все так усложнять
— RX пошел в сторону фп, получив сотни функций преобразования
— Coroutines Flow расширяет контроль состояния, продолжая идею самих корутин
Это два подхода, порожденных observable шаблоном, но ориентированных на разный результат.
П.С. Имхо, в реальных системах подход Flow более жизнеспособен, т.к. в конечном итоге все упирается именно в контроль состояния. Абстрактно чистое фп возможно чисто теоретически — на деле же мы просто отдаем контроль состояния на сторону. Flows дают более прозрачную картину
Сейчас разрабатывается lifecycle экстеншн для этого. но пока надо делать это вручную. В местах удаления с экрана, убивать и скоуп.
У вьюх в следующей версии lifecycle такая фича появится
95 процентов упомянутых вами зарядок в мире бесполезны для этого провода. И тут только в магазин, или за проводом, или за зарядкой.
Но унификация разъема, наверно, не приведет к уменьшению количества проводов и углеродного следа.
Еще можно посмотреть в сторону заявления их руководства о том, что в мире существует множество зарядок других производителей — а разрешается ли вообще по условиям гарантии заряжать айфоны от чего-то не эпплового.
Вообще уже пора уменьшить углеродный след еще больше, исключив из комплекта поставки аккумулятор, процессор, экран и все остальное — получается, что сама компания супер экологичная, и все выбросы на совести у юзеров — хочешь быть экологичным, но пользоваться эппл — просто купи пустую коробку.
— Амазон ли, Билл Гейтс, Билли Айлиш — без разницы. По моим условиям груши бесплатны сами по себе.
— То что слоган лживый — вообще никак ко мне не относится. Их обман на их совести
— а вот приписывание меня в авторы это вопрос. Если по лицензии я просил нахваливать меня, поедая полосатые груши — тогда все верно. И я могу подать в суд за заведомо ложную информацию, но не за то, что мне не дали денег (я и не прошу по своим условиям).
— Если же меня не указывают — опять же, могу идти в суд, если докажу, что груши мои. А могу и не идти — это мое субьективное решение, и мнение бабушек с лавочки меня не волнует
— Мнение бабушек с лавочки: «смотри-ка, а нашего Guitariz обул не кто-то там, а сам Билли Гейтс! Ну не то чтобы обул, просто мы так называем свое субьективное восприятие действий, к нам не относящихся. Да что там, мы ж бабки, у нас все девки — проститутки, а парни — наркоманы. А раз так, значит иди и доказывай, что не наркоман».