Builder паттерн делаете вручную или утилитой?

Idea сама умеет, емнип пкм по конструктору класса - convert to builder.

А тесты, покрывающие собой нужную функциональность, есть? Если нет, советую начинать с них. Потом удалить хлам, дублирование, «хитрую логику». Потом спрятать код, работа которого завысит от фаз Луны (функции с временем, файлами и third party кодом) под простенькие классы и покрыть их интеграционными тестами. А потом, наверняка, будет не лень и руками доделать.

Если коротко - руками, с тестами. Утилитам для автоматического рэфакторинга таких сложных задач не даю.

https://github.com/google/auto

org.projectlombok:lombok
Annotation post-processor-ы никто вроде бы не отменял.

Kotlin, data class и default arguments — очень удобно, рекомендую

Типичный хипстерский подход - менять ЯП, среду разработки и все наработки из-за пары ложек сахарка...

немного не по теме. Чот я не догнал. Чем этот паттерн от фабрики отличается?

Проблема всех этих билдеров в невозможности добавить логику на сеттеры. Например, мне при добавлении элемента в список (#addFoo метод на билдере) нужно проверить элемент на условие и инкрементить другое поле этого же объекта. Понятно, что можно было бы на #build прогнать этот список в цикле, но как-то это криво - лишние операции...

https://stackoverflow.com/questions/757743/what-is-the-difference-between-bui...

Фабрики бывают разные, есть factory method, есть abstract factory, из jdk ничего в голову не пришло, зато вспомнил пример из hibernate где сразу оба паттерна используются:

EntityManagerFactory emf = Persistence.createEntityManagerFactory("manager1") // Factory Method в сущности замена конструктора
EntityManager em = emf.createEntityManager(); // Абстрактная фабрика
...
em.close();
emf.close();

RemoteService service = new RemoteService.Build(username, password) // обязательные параметры
  .keepAlive(true) // опциональный
  .timeoutSec(100) // опциональный
  .build();

Решил себя проверить, таки я перепутал Factory Method со static factory method описанный у Блоха. По этому поправка, это не пример Factory Method паттерна:

Persistence.createEntityManagerFactory(«manager1»)

эта лалка (data class) не умеет наследовать, мне хохотно

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

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

Думал может я что пропустил, пока кидают не то что нужно.

ЯП всё тот же, только удобней.
Среда — всё та же (если IDEA, а если нет то передайте мне там в 2010-м чтоб с IT не связывался...)
Наработки всё те же, просто пишем на Kotlin рядом с ними.
А о Вашем подходе мне тоже есть что сказать...

Наследование в data классах — плохая практика, предлагаю композицию

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

в нормальных языках есть подмешивание (микшены) для хипсетров не умеющих нормально проектировать иерархию наследования

Чем этот паттерн от фабрики отличается?

Фабрика - для создания объекта. Билдер - для последующей инициализации/настройки. Т.е. задачи абсолютно разные.

По этому поправка, это не пример Factory Method паттерна

Это пример абстрактной фабрики. А следующая строчка как раз фабричный метод.

множество объектов с пересекающимся набором свойств

Общий интерфейс —> делегация

interface Common { 
    val a: Int 
    val b: Int 
}
data class Example(
        override val a: Int, 
        override val b: Int
) : Common
data class ExampleExtended(
        val common: Common, 
        val c: Int
) : Common by common

инструмент не подходит

:(

нормально проектировать иерархию наследования

А расширять?

Наследование в data классах — плохая практика

И чем это плохо, кто тебя завербовал? И чем это отличается от композиции? Как по мне одно и тоже только способ записи иерархии разный.

ЯП всё тот же

Нет

если IDEA, а если нет то передайте мне там в 2010-м чтоб с IT не связывался...

С лёгкой руки послал огромную аудиторию еклипс.

просто пишем на Kotlin рядом с ними

Непросто, как минимум почитай джоула про дырявые абстракции. И делать компот из кучи ЯП плохая идея.

Общий интерфейс —> делегация

Ну вот, тоже самое наследование записанное по другому (при этом замудренное). А выше говорил, что наследование это плохо.

Общий интерфейс —> делегация

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