Стоп рефакторинг. Kotlin. Android

[Daddy_Cool]

Ох… У меня как-то один проект разросся настолько, что я с трудом понимал где у меня что… И думал, а не переписать ли всё нафиг? Благо теперь я знаю, что где и как должно быть. )
Есть подозрение, что каких либо методик здесь быть не может — кроме описанного у вас принципа, что надо по возможности заглядывать в будущее и предсказывать возможные изменения требований в разумных пределах. А чтобы это делать — надо просто быть умным.

[TranE91]

Если бы можно было бы все описать, у нас уже не было бы работы)

надо по возможности заглядывать в будущее и предсказывать возможные изменения требований в разумных пределах. А чтобы это делать — надо просто быть умным.

Старайтесь ставить под сомнение что-то неизвестное и до конца непонятное, ответ придет быстрее. Если ответа нет, зарезервируйте место на неизвестное.
И, как бы грубо это не звучало, воруйте) Воруйте идеи из других продуктов) «Вот почему у них это есть, а у нас нет?»

[Guitariz]

Отряд булевых флажков

Это тот случай, когда разработчик втыкает любимые паттерны проектироавния с пользой и без пользы. Разлепить состояние письма и состояние уведомления не позволила религия, поэтому будем есть кактус.

Одно состояние

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

data class User(
    val username: String?
    val hasUsername: Boolean
)

если hasUserName выставлен, предлагать заполнить поле не нужно, независимо от того, есть там значение или нет.
Если флаг выставлен, то даже если имя хранится, предложить все равно стоит — допустим, это имя было сгенерировано по умолчанию.

Уменьшение области видимости

Костыль же.
Можно сделать более очевидные решения в виде абстрактного класса, sealed класса. А теперь еще и sealed интерфейсы будут. В конце концов, заменить передачу валидотара на передачу enum. А клиенту предоставьте статическую функцию, validate с дополнительным параметром type.

[TranE91]

Это тот случай, когда разработчик втыкает любимые паттерны проектироавния с пользой и без пользы. Разлепить состояние письма и состояние уведомления не позволила религия, поэтому будем есть кактус.

Согласен, пример получился не совсем удачный(
Надеюсь, общий посыл возможных вариантов разруливания состояний удался.

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

Актуально в случае, когда `username` и `hasUsername` не коррелируют друг с другом. Если значения самодостаточны, несомненно стоит использовать что-то из «Отряда булевых флажков».

Костыль же.

Не совсем понял Вашу идею. Могу ли попросить описать более подробно?

[Guitariz]

Актуально в случае, когда `username` и `hasUsername` не коррелируют друг с другом. Если значения самодостаточны, несомненно стоит использовать что-то из «Отряда булевых флажков».

Если эти вещи коррелируют друг с другом, надо сделать sealed class и выразить это через его состояния. В любом другом случае догодаться об их взаимосвязи невозможно

Не совсем понял Вашу идею. Могу ли попросить описать более подробно?

Есть публичный интерфейс, есть метод, в который его можно передать. По какой то неведомой логике автор этой поделки считает, что объявлять собственные экземпляры классов нельзя. Как об этом должны догодаться другие разрабы — фиг его знает.
Нормальные решения.
1) объявить интерфейс Sealed классом, закрыть таким образом возможность наследования
2) сделать абстрактный класс с таким же закрытым для переопределения конструктором
3) использовать новоязовский sealed interface как в п.1
4) убрать вообще конкретную реализацию, сделать enum ValidateType. Объявить в рамках него статический метод

validate(type:ValidateType, str:CharSequence):ValidationResult

И это все 4 регламентированых языком способа убрать наследование. В статье же один костыль меняется на другой, еще более извращенный.

[Guitariz]

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