Size: a a a

2020 October 27

А

Артём Курилко... in pro.jvm
кто то сталкивался с проблемой что в spring cloud gateway глобальный фильтр вызывается несколько раз при одном запросе?
источник

RS

Ruslan Sinkevich in pro.jvm
Denis Chikanov
А потом такие пользователи творят лапшу и заводят ишшуи в библиотеках, которые сводятся к "ой, мы что-то переопределили и всё сломалось, доку не читали"
Или экономят много времени при разработке
источник

VP

Vladimir Petrakovich in pro.jvm
Ruslan Sinkevich
Или экономят много времени при разработке
А потом рыдают после обновления, компенсируя эту экономию
источник

VP

Vladimir Petrakovich in pro.jvm
Не нравится как сделано - можно форкнуть. А иначе это сидение на пороховой бочке.
источник

MO

Max Olsson in pro.jvm
final методы да, а так ли нужен всегда final на самом классе?
Вот допустим есть у нас какой-нибудь класс Something, инстанцируемый, но не final. Еще и библиотечный, к тому же.
И допустим есть мой класс для работы с ним SomethingWrapper<T extends Something>.
Я могу сделать синглтон Thingy extends Something, и далее требовать где-нибудь SomethingProducedByWrapper<Thingy>.
Такой подход норм?
источник

DC

Denis Chikanov in pro.jvm
Vladimir Petrakovich
Не нравится как сделано - можно форкнуть. А иначе это сидение на пороховой бочке.
this
источник

R

Roman in pro.jvm
Ну за методы это понятно. А интересно за параметры узнать? Сановские чеки к примеру тапками бросают, если не юзать final параметры, но вот загонять в каждый параметр final как-то не очень, да и readability ухудшается. У вас на проектах среди разраб есть консенсус по этому поводу?
источник

TI

Tolegen Izbassar in pro.jvm
Щас бы на каждую хотелку в либе делать форки и потом поддерживать их
источник

VP

Vladimir Petrakovich in pro.jvm
Tolegen Izbassar
Щас бы на каждую хотелку в либе делать форки и потом поддерживать их
Щас бы скидывать это на автора либы
источник

T

Tagir in pro.jvm
А кто-нибудь из тех, кто не любит final, занимался поддержкой библиотечного кода? Вот прям по-честному, что есть клиенты, которых вы не контролируете, библиотека активно развивается, но нужна вменяемая обратная совместимость
источник

TI

Tolegen Izbassar in pro.jvm
Автор либы тоже должен думать о расширяемости и конфигурируемости. Предоставлять интерфейсы вместо конкретных классов и тп. чтобы не приходилось пользователям хачить
источник

VP

Vladimir Petrakovich in pro.jvm
Вообще у меня дежавю
https://t.me/jvmchat/375651
источник

VP

Vladimir Petrakovich in pro.jvm
Tolegen Izbassar
Автор либы тоже должен думать о расширяемости и конфигурируемости. Предоставлять интерфейсы вместо конкретных классов и тп. чтобы не приходилось пользователям хачить
Это да, несомненно
источник

T

Tagir in pro.jvm
Ну Олег любитель всё говном назвать. Это ни о чём не говорит
источник

AB

Alexei Barantsev 🗹... in pro.jvm
вроде бы не пятница сегодня, а с утра уже такие мощные набросы :)
источник

T

Tagir in pro.jvm
Вот сейчас sealed interfaces завезут, и авторы библиотечного кода вообще нормально заживут
источник

T

Tagir in pro.jvm
А то ишь, любители расширять!
источник

SP

Sam Panza in pro.jvm
Vladimir Petrakovich
Вообще у меня дежавю
https://t.me/jvmchat/375651
Пфф, Чирухин. Так себе авторитет
источник

RS

Ruslan Sinkevich in pro.jvm
Все правильно говорит. Хочешь налепить final - обеспечь возможность расширения или не препятствуй
источник

TI

Tolegen Izbassar in pro.jvm
Tagir
А кто-нибудь из тех, кто не любит final, занимался поддержкой библиотечного кода? Вот прям по-честному, что есть клиенты, которых вы не контролируете, библиотека активно развивается, но нужна вменяемая обратная совместимость
А кто-нибудь из тех, кто любит final, занимался случаями, когда библиотека чего-то не учла? Вот прям по честному, когда нужно определенное поведение, которые авторы либ сочли "неправильным". Тут палка о двух концах.
источник