pro.jvm

02 Dec 2024 15:42

Ну тут от онтико зависит, думаю выложат через n недель

pro.jvm

02 Dec 2024 14:30

@ivandasch успехов

pro.jvm

02 Dec 2024 11:57

Visitor, если я не ошибаюсь.

pro.jvm

02 Dec 2024 11:30

все паттерны на лямбдах можно

pro.jvm

02 Dec 2024 11:28

Было бы странно, если новые языки не исправлял косяки старых людей, не думаешь 🌚?

pro.jvm

02 Dec 2024 11:25

А у тебя всегда выходит аргумент в стиле

А вот в котлине и в скале лучше 🌚🌚🌚

pro.jvm

02 Dec 2024 11:23

Тоже кстати про паттерны хотел сказать. А как тогда без наследование реализовывать. Хз, ну странно, что это живёт 50 лет, и потом все такие. Это ужас, это плохо 🤯

pro.jvm

02 Dec 2024 11:20

это первый вариант по сути

pro.jvm

02 Dec 2024 11:19

и первые и второй варианты уродливы

pro.jvm

02 Dec 2024 11:18

а зачем это все, когда у нас теперь есть sealed interfaces&classes с первоклассной поддержкой паттерн матчинга?

pro.jvm

02 Dec 2024 11:16

После нескольких лет общения в ФП сообществе, где ООП в принципе считается злом, я наоборот привык доказывать, что наследование и в JVM и как фича отдельных его языков в общем-то имеет несколько приятных паттернов применения, поэтому странно избегать его вовсе

pro.jvm

02 Dec 2024 11:15

Ну Алексей Шипелев правильно сказал, что после такого дизайна деду только и книги и писать 🌚

pro.jvm

02 Dec 2024 11:15

после UncheckedIOException я не могу сказать, что жаба не ужасно сделана

pro.jvm

02 Dec 2024 11:14

Ваще не понял, что ты хотел сказать этим

pro.jvm

02 Dec 2024 11:13

Ну и выходит жаба апи сделано ужасно, ведь везде наследование или это другое 🤯

pro.jvm

02 Dec 2024 15:38

Спасибо, отстрелялся :) вроде норм прошло

pro.jvm

02 Dec 2024 13:40

Привет, всем. Подскажите, есть ли кто-то кто использовал flowable, и реализовывал процесс в котором нужно совершить действие, если "просрочилась" user task (due date)?
(например, зарегистрировать слушатель и послать сигнал). Бегло посмотрел апи, ощущение, что due date это просто свой-сво таски, которое нужно использовать на свое усмотрение. Есть слушатели вокруг апи таски, но они больше про измение состояния.
В проекте используем quartz, думал еще как вариант опрашивать таски процессов с каким-то интервалом времени. Буду признателен, если поделитесь опытом и свои варианты подскажите.
P.S. Надеюсь в этом чате не покусают, что вопрос больше касается bpm 🙂

pro.jvm

02 Dec 2024 11:41

Правда в некоторых паттернах их изначальная цель теряется, но это дело десятое)

pro.jvm

02 Dec 2024 11:29

Все паттерны из refactoring guru можно переписать с наследования конкретных или абстрактных классов с реализованым поведением внутри на 0 боилерплетные композицию + делегацию + реализацию интерфейсов https://kotlinlang.org/docs/delegation.html. Получить гибкость без боилерплейта. Что может быть лучше? То что язык определенный криво позволяет делать делегацию боилерплейтную так что теперь?
Если посмотреть издалека, оба подхода об одном и том же, но второй подход просто не имеет недостатков первого если взять норм язык

pro.jvm

02 Dec 2024 11:25

я стараюсь писать факты. что поделаешь

pro.jvm

02 Dec 2024 11:24

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

pro.jvm

02 Dec 2024 11:20

pattern matching поможет для обработки обоих сценариев

pro.jvm

02 Dec 2024 11:19

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

pro.jvm

02 Dec 2024 11:19

вот тут по кайфу наследоваться

pro.jvm

02 Dec 2024 11:17

а мы про наследование или про полиморфизм?
просто полиморфизм в данных можно заменить на специфическую композицию

условно у вас есть сценарий

@JsonSubTypes...
interface SomeData { 
  String type();
}

record DataType1 implements SomeData {
  public String type() {
    return "type1";
  }
}

record DataType2 implements SomeData {
  public String type() {
    return "type2";
  }
}

record Data(
  DataType1 dataType1,
  DataType2 dataType2
) {}

pro.jvm

02 Dec 2024 11:16

Наверное, сделали на наследовании классов вынуждено потому, что если бы на композиции было все, то было например такое:

var set = new HashSet(new ValuesTheSameHashMap());

pro.jvm

02 Dec 2024 11:15

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

pro.jvm

02 Dec 2024 11:15

Дмитрий, выше правильно сказал, как и любой инструмент его можно использовать неправильно. И стрельнуть наследованием, просто легче, чем композицией имо

pro.jvm

02 Dec 2024 11:13

Я вот только-только искал как засунуть в дискуссию "почему вы тогда просто не пишете functions.php со всем необходимым и не копируете в каждый новый проект"

pro.jvm

02 Dec 2024 11:12

Так литералли на работе ласт кейс. Написано 1 раз и не меняется, причём забавно, что именно эта часть не падала 8 лет. В целом, странный кейс, мне кажется композиция это не убийца наследование. Это скорее про разные подходы, и что иногда наследование подходит. Как я и сказал, Машина всегда Vehicle, но вот двигатель в машине может меняться