Size: a a a

Programming Offtop

2021 March 30

KD

Konstantin Dovnar in Programming Offtop
Andrew Mikhaylov
Тож не понял пример. У меня сто лет лиснеры в коде — это функциональные типы, за редкими исключениями, где таки нужен интерфейс с несколькими методами, и я не помню, чтобы в нём надо было cancel заводить какой-то.
Окей.

class X(private val listener: Listener)

val l = Listener()
val x = X(l)
// ...
x.removeListener()
// x шлёт события вникуда
источник

KD

Konstantin Dovnar in Programming Offtop
Andrew Mikhaylov
Если мне нужна возможность заменять или убирать их — делаю var и наллабл при надобности. Не нужна — не делаю. А тут оказывается, лиснеры кому-то что-то обязаны!
И как ты их установишь, если передаются они в класс только через конструктор?
источник

VP

Vladimir Petrakovich in Programming Offtop
Konstantin Dovnar
Даже если отбросить замену — они должны уметь отписаться.

Значит, что всё-таки стоит иметь возможность подписаться и потом, чтобы избежать ситуаций, когда создали класс передав подписчика, отписались, а класс дальше шлёт события вникуда.
Погоди, а если это просто коллбек?
источник

KD

Konstantin Dovnar in Programming Offtop
Ради слушателя пересоздавать весь класс? Звучит как-то ебанатски, если можно просто сеттеры сделать.
источник

KD

Konstantin Dovnar in Programming Offtop
Vladimir Petrakovich
Погоди, а если это просто коллбек?
>Единственный нормальный кейс который я вижу — это передача лямбды как слушателя, чтобы она просто жила вместе с объектом.
источник

VP

Vladimir Petrakovich in Programming Offtop
Konstantin Dovnar
>Единственный нормальный кейс который я вижу — это передача лямбды как слушателя, чтобы она просто жила вместе с объектом.
А, ну ок
источник

AM

Andrew Mikhaylov in Programming Offtop
Konstantin Dovnar
Окей.

class X(private val listener: Listener)

val l = Listener()
val x = X(l)
// ...
x.removeListener()
// x шлёт события вникуда
Ну то есть в данном конкретном случае у X предполагается возможность прекратить посылать данные, окей. Зачем говорить, что это надо всем и всегда?
источник

VP

Vladimir Petrakovich in Programming Offtop
Но в общем случае это и есть какая-то лямбда
А что-то сложнее можно навертеть и поверх этого
источник

AM

Andrew Mikhaylov in Programming Offtop
Konstantin Dovnar
>Единственный нормальный кейс который я вижу — это передача лямбды как слушателя, чтобы она просто жила вместе с объектом.
Ок, я не видел эту оговорку. Хотя странно с этой оговоркой утверждать всё остальное про то, что лиснер кому-то что-то должен.
источник

KD

Konstantin Dovnar in Programming Offtop
Andrew Mikhaylov
Ну то есть в данном конкретном случае у X предполагается возможность прекратить посылать данные, окей. Зачем говорить, что это надо всем и всегда?
А где речь о всём и всегда?
Речь о том, что если нужна возможность менять слушателя — передача через конструктор лишняя, т.к. всё равно нужны методы для работы со слушателем в классе.
источник

AM

Andrew Mikhaylov in Programming Offtop
Konstantin Dovnar
Имхо, при передаче в конструкторе у тебя идёт негласная завязка на то, что слушатель будет слушать и работать всё время жизни объекта.

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

На этой ноте как-то не соответствуют подходы.
Вот тут:
"Но сам по себе подход слушателя подразумевает возможность отмены, переподписки, изменения слушателя."
источник

KD

Konstantin Dovnar in Programming Offtop
Andrew Mikhaylov
Ок, я не видел эту оговорку. Хотя странно с этой оговоркой утверждать всё остальное про то, что лиснер кому-то что-то должен.
Должен не лисенер, а наоборот класс который с ним будет работать. И должен именно в том случае, если слушатель будет меняться.
источник

VP

Vladimir Petrakovich in Programming Offtop
Konstantin Dovnar
А где речь о всём и всегда?
Речь о том, что если нужна возможность менять слушателя — передача через конструктор лишняя, т.к. всё равно нужны методы для работы со слушателем в классе.
Мне кажется, вот эту хитрую логику нахер не надо держать в самом классе, он же вообще не этим занимается
источник

VP

Vladimir Petrakovich in Programming Offtop
Если кому-то нужно - сделай список подписчиков
источник

AM

Andrew Mikhaylov in Programming Offtop
https://t.me/pofftop/321181 а вот тут лиснер должен.
Ладно, не суть.
источник

KD

Konstantin Dovnar in Programming Offtop
Andrew Mikhaylov
Вот тут:
"Но сам по себе подход слушателя подразумевает возможность отмены, переподписки, изменения слушателя."
Да, надо было выделить про живущие вместе с классом объекты заранее. Извиняюсь.

Там речь о кейсе, когда надо иметь возможность какого-то менеджмента слушателей.
источник

AM

Andrew Mikhaylov in Programming Offtop
Ну тут всё понятно, конечно)
источник

KD

Konstantin Dovnar in Programming Offtop
Vladimir Petrakovich
Мне кажется, вот эту хитрую логику нахер не надо держать в самом классе, он же вообще не этим занимается
Тогда тем более зачем ему принимать в конструктор слушателя
источник

VP

Vladimir Petrakovich in Programming Offtop
Konstantin Dovnar
Тогда тем более зачем ему принимать в конструктор слушателя
Чтобы в этом классе не ебать себе мозг вопросами "а установлен ли слушатель"
источник

VP

Vladimir Petrakovich in Programming Offtop
Минимальный API, не?
источник