Тот факт, что в строку можно все что угодно сдампить - был известен задолго до Егора

Проблема с тем как потом вынуть что-то из этой строки

https://www.youtube.com/watch?v=ByagQCx7m04

Вот

Наконец мы добрались до сути

Это не нужно

я хз, мне кажется ты не понял о чем речь

А о чем речь?

О том что инкапсуляция крутая штука в теории, но на практике "не нужна"?

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

я понял

если мы вдруг решили, что температуру надо бы хранить в дабл, а не в инт - это плохое проектирование изначально. типы тут сбоку приплетены

все надо передавать через строки

это был ответ Ивану

Джаваскрипт сейчас переизобретем

вы не понимаете, речь о том что не нужно давать данные направо и налево только потому что кто-то хочет их использовать, объект должен самостоятельно решать как он эти данные будет выводить например в контексте этой задачи нам нужно вывести данные в строку в таком то формате, так вот объект сам может это сделать и для этого у него есть метод toString ни кто-то там сверху решает такс дай ка мне твое свойство я ща с ним что-то сделаю, а объект решает

в этом суть инкапсуляции

если нужно было бы вывести данные в байтах объект сам бы их вывел в байтах а не отдавал бы сырое поле наверх

так а что делать, если мы решим изменить формат? зависимый код все равно сломается

сверху могут только попросить а можешь вывести в таком виде и если объект может то выведет а если нет то идите нафиг

в таком случае можно расширить сам объект

и кому нужен объект который всех посылает нафиг?

и код сверху не сломается

а кому нужен объект который всем дает?

мне

пожалуйста

просто отдайте данные

и еще миллионам программистов

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

которые матом матерятся на эти ваши обертки над интами

давай

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

усложни, этим все занимаются постоянно

ну возьмем например матрицы. Внутри они юзают массивы, а массивы решают не отдавать данные… упс :)

если там будет List<> который отдадут наверх с помощью геттера и кто-нибудь сверху этот лист изменит

это уже из другой области

отдавай копию

почему?

не понимаю

почему из другой области

тоже самое

типы

List это же тип?

LocalDate в JodaTime тип?

ты путаешь инкапсуляцию и мутабельность

Отдавай копию листа

ээээ че? геттер это и есть нарушение инкапсуляции

и ничего не изменится

а я не хочу копию отдавать

я же открыт для всех

всем даю

ну

отдавай всем копии

иммутабельность

пожалуйста

это же ухудшит перформанс

делись данными

я не хочу ухудшения перформанса

я юзаю int и не делаю копий

о-о

вот это залет был

int копируется

о другом речь я юзаю int и list

ссылка на лист тоже копируется

а сам объект я не хочу копировать

вместо инта лист?

потому что это увеличит нагрузку на память

ERROR: S client not available

Ну shallow copy есть

еще раз говорю я не хочу отдавать копию листа наверх а хочу отдавтаь сам лист

как это делает JPA

отдавай сам лист

в чем проблема?

https://google.github.io/guava/releases/snapshot/api/docs/com/google/common/collect/ImmutableList.html

эх ща бы еще либу стороннюю тащить

когда есть Collections.unmodifiableList

эх ща бы еще либу стороннюю тащить

Ну еще в 9ке будут имутабельные фабрики для коллекций, но ловить в раниайме исключения отличная идея, спасибо блоху за дизайн коллекций

of(E e1, E e2, E e3, E e4, E e5, E e6, E e7, E e8, E e9, E e10, E e11) каеф

of(E e1, E e2, E e3, E e4, E e5, E e6, E e7, E e8, E e9, E e10, E e11) каеф

Нормально же

В тестах вообще отлично

Вместе с гуавой

Если вы еще не используете спок, конечно

Если вы еще не используете спок, конечно

Но там другая проблема - груви ?

Но там другая проблема - груви ?

Да разве это проблема? Это же не котлин какой-то

Груви - это радость

день сурка

день сурка

добро пожаловать, Сергей.

Снова

добро пожаловать, Сергей.

я этот день сурка уже 4й месяц наблюдаю

Решение неочевидных проблем в груви неплохо поднимает чсв

решение надуманных проблем?

я этот день сурка уже 4й месяц наблюдаю

Уходи из скала чата

решение надуманных проблем?

Надуманных? В груви только реальные

да не, в скала чате почище будет чем тут)

реальные которые язык создает?

В меньшей степени язык

В большей недопонимание между разрабом и языком/рантаймом

Проблемы создают пользователи языка, причем в больших количествах и с удовольствием. Java в этом плане чемпион.

Какие в джаве проблемы?

Например обмазать все ООП а потом лечить последствия паттернами