не, не дружок, ты практики конкретно к языку не мешай

http://www.yegor256.com/2017/02/21/say-no-to-google-recruiters.html Хорошая статья от Егора.

почему бы и нет, раз это стало характерной чертой? я не видел в скала/груви/котлин коде фабрик фабрик, хотя стоит признать, что котлин кода я читал мало

короче, я понял тебя, Кирилл и твоё имхо, слишком предвзято, рад, что ты нашел себя в скале

но не стоит стереотипам давать волю над разумом

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

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

я надеюсь ты не о спринге

как пример джава кода который мне понравился, могу привести либу kafka-clients, там вот читаешь - и сходу понимаешь, что, откуда и как берется, и не надо заставлять идею лезть через 10 слоев иерархии классов и искать имплементацию на другом конце вселенной, где она неявно в рантайме тянется

то что ты описываешь это в энтерпрайзе часто такое

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

все же джава лет за 5 последних нормально шагнула вперед

и JVM подкрутили, и функциональщины добавили, вполне приятно стало

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

Так а почему это поощряется, почему пишут про эти паттерны, как про что-то хорошее, и это считается нормой? Почему бы разработчикам ведущих фреймворков тогда не прививать прикладным разрабам best practices?

т.е. ты считаешь паттерны проектирования плохой вещью?

я тебя правильно понял?

такие, как я описал выше - да, не все же паттерны плохие, само собой, не искажай мои слова

ну как ты написал

ну прокси паттерн это почти всегда необходимость

на прокси паттерне спринг работает на минуточку

да куча всего

и куча других жизненно важных либ

а тут Кирилл нам заявляет что это плохо

я не знаю, как к этому относиться

функциональщина - это когда я недавно хотел на джаве сделать mkstring у листа UUID, и вышло у меня list.stream().map(UUID::toString).collect(Collectors.joining(",")), ну серьезно блин, что это?

функциональщина - это когда я недавно хотел на джаве сделать mkstring у листа UUID, и вышло у меня list.stream().map(UUID::toString).collect(Collectors.joining(",")), ну серьезно блин, что это?

что тебя не устраивает тут и как бы ты хотел?

list.mkString(",")

либы есть

streamex

jdk дает голое api дальше сами пилите

вы поставьте себя на место JDK инженеров

мотивацию прикиньте

что будет, если все хотелки влепить

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

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

тебе Иван написал, где такое бывает и почему

повторюсь, новые проекты стараются использовать лучшие практики и подходы

насколько это возможно

тебе Иван написал, где такое бывает и почему

Да, и я снова задам вопрос, почему разработчиками спрингов и прочих ведущих библиотек это считается нормой -> прикладных разрабов подталкивают так писать?

подталкивают писать как?

ты пытаешь притянуть за уши проблему конкретных говнопроектов, на которых ты был

ну или поначитался где-то

но мир то огромный

о этот прекрасный мир.

Да, и я снова задам вопрос, почему разработчиками спрингов и прочих ведущих библиотек это считается нормой -> прикладных разрабов подталкивают так писать?

если че спрингу тоже лет 12 уже

т.е. это не самый лучший пример

хотя тот же спринг ща пилит stream api т.е. пытается быть в тренде

запиливает асинхронность в свой фреймворки

Почему, например, считается нормой писать геттеры/сеттеры, причем в любом случае, не только там, где нужна какая-то конкретная хитрая обработка в set или get? Инкапсуляция здесь ни при чем, сокрытие тоже

+

Почему, например, считается нормой писать геттеры/сеттеры, причем в любом случае, не только там, где нужна какая-то конкретная хитрая обработка в set или get? Инкапсуляция здесь ни при чем, сокрытие тоже

потому что java beans

да case classы просто не завезли. перекатывайся на скалу и будет счастье

в jdk 9

будут data классы вроде

да case classы просто не завезли. перекатывайся на скалу и будет счастье

я уже давно пишу на скале

>де нужна какая-то конкретная хитрая обработка в set или get а вот это боль

будут data классы вроде

нет

когда логика в геттерах и сеттарах

я уже давно пишу на скале

а что тогда бугуртишь?

нет

?

когда логика в геттерах и сеттарах

ну никто тебе не мешает в скале их переопределить

list.mkString(",")

функциональщина будет так: mkString(list, ",")

когда логика в геттерах и сеттарах

тем более! я стараюсь писать на джаве с public final полями и давать их в конструкторе, и код сразу становится короче в 10 раз и чище, что в этом плохого? почему везде геттеры и сеттеры?

функциональщина будет так: mkString(list, ",")

да, формально я вкурсе, ты понял, что я говорил о скале

тем более! я стараюсь писать на джаве с public final полями и давать их в конструкторе, и код сразу становится короче в 10 раз и чище, что в этом плохого? почему везде геттеры и сеттеры?

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

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

public final, вот и иммутабельность, зачем геттеры?

тем более! я стараюсь писать на джаве с public final полями и давать их в конструкторе, и код сразу становится короче в 10 раз и чище, что в этом плохого? почему везде геттеры и сеттеры?

многолетняя практика

ERROR: S client not available

да, формально я вкурсе, ты понял, что я говорил о скале

так котлин тоже тебе экстеншен сделает

тем более! я стараюсь писать на джаве с public final полями и давать их в конструкторе, и код сразу становится короче в 10 раз и чище, что в этом плохого? почему везде геттеры и сеттеры?

Уоу, паблик поля. Мазохисты в чате

public final, вот и иммутабельность, зачем геттеры?

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

так котлин тоже тебе экстеншен сделает

я говорил про то, как я сделал это на джаве, и как мне хотелось бы это видеть, слова котлин там нигде не было

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

ага, а потом кто-то особо умный рефлексией начнет баловаться

тем более! я стараюсь писать на джаве с public final полями и давать их в конструкторе, и код сразу становится короче в 10 раз и чище, что в этом плохого? почему везде геттеры и сеттеры?

слушай, даже скала так не делает

астанавись

плюс с помощью сеттеров удобно сделать билдер паттерн

ага, а потом кто-то особо умный рефлексией начнет баловаться

рефлексии бояться - на спринге не писать

а с просто полями как?

зачем билдер паттерн, если нужны иммутабельные структуры?

зачем билдер паттерн, если нужны иммутабельные структуры?

а мне нужны изменяемые

даже в джсе пишут щас Object.assign({}, old, new)

бизнес требует

слушай, даже скала так не делает

я не понял того, что ты сказал))) case class A(a: Int), и ты пишешь val a = A(1); println(a.a)

даже в джсе пишут щас Object.assign({}, old, new)

я такое видел на жсе

охренеешь

а мне нужны изменяемые

пока бизнес требуеет, джс обогнал тебя в эволюции :)

пока бизнес требуеет, джс обогнал тебя в эволюции :)

так обогнал, что его ненавидят просто

я не понял того, что ты сказал))) case class A(a: Int), и ты пишешь val a = A(1); println(a.a)

ну там же все равно есть методы, т.е. там не public final там вместе с пропертей создаются сеттер и геттер

а мне нужны изменяемые

Ну так и делаешь копию объекта с измененным конкретным полем, или у тебя сириус бузинесс на 1кк rps где нельзя лишний int аллоцировать?

бизнес требует

Бизнес требует чтобы работало, а не чтобы сеттеры и билдеры писали

бизнес требует

Ну ты загнул

ну там же все равно есть методы, т.е. там не public final там вместе с пропертей создаются сеттер и геттер

Да какая разница, я говорю про то, как это выглядит с точки зрения кода и разработчика, с точки зрения developer API

мне нужно поменять поле у объекта из базы

ваши предложения, господа

Да какая разница, я говорю про то, как это выглядит с точки зрения кода и разработчика, с точки зрения developer API

давай говорить правду, геттер и сеттер это хоть какая нибудь попытка сохранить контроль над приватностью свойства

ауууу, фп боги, вы где

ясно

мне нужно поменять поле у объекта из базы

Меняешь значение в базе

На выходе из метода даешь новый объект

давай говорить правду, геттер и сеттер это хоть какая нибудь попытка сохранить контроль над приватностью свойства

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