Clean Coder

Я такую задачу решал реактивностью. У меня не Spring, правда, но с Reactor'ом тоже решается элементарно.

Для начала стоит обратиться к какому-нибудь источнику информации об этом шаблоне. Например, к этому.

Представьте сложный объект, требующий кропотливой пошаговой инициализации множества полей и вложенных объектов. Код инициализации таких объектов обычно спрятан внутри монструозного конструктора с десятком параметров. Либо ещё хуже — распылён по всему клиентскому коду.

Иными словами, под монструозным конструктором понимается намеренное создание монолита. Монолит создается, как правило, один раз и потом тухнет до полного разложения его кода, когда пользоваться им уже невозможно в следствии объема его ошибок, но и отрефакторить тоже невозможно в следствии его монолитной организации.

А под ещё хуже понимается именно вот этот метод с интерфейсом полным сеттеров, которые призваны инициализировать объект до его правильного состояния. Только вот в чем проблема: в каком состоянии будет находиться объект до вызова всех нужных сеттеров и завершения его инициализации? В неправильном состоянии, но объект уже будет и воспользоваться им в таком состоянии кто-то обязательно захочет. А ведь еще кто-то должен знать эту самую последовательность(последовательности?) вызова сеттеров чтобы завершить инициализацию такого объекта. Не многовато ли избыточной ответственности на клиентский код возлагается?

Давай представим что нам надо выполнить рейс на МИ-8. Но чтобы автоматизированная система современного аэродрома дала нам разрешение на взлет, нам надо передать ей специальный хеш.


Иммутабильный объект можно получить через идиому RAII или фабричного метода. Но что если для создания иммутабильного объекта требуется очень много параметров? Например - 16 параметров. Или 23, как в одном случае. Или - 42 параметра.
Что если часть этих 42 параметров можно вычислить из остальных, но вот иногда их нужно указывать явно?
Что если всего параметров 42, но для конструирования требуется использовать лишь произвольное подмножество этих параметров? Припоминаются SQL-запросы, правда ведь?
RAII в этом случае захлебывается и становится непонятным, а фабричных методов требуется столько, что ими становится тяжело управлять. Идиома фабричного метода в этом случае начинает проявлять свои негативные качества и тормозить разработку.
А билдер со всеми такими случаями легко справляется. Напомню, что Immutable в принципе невозможно снабдить сеттерами, т.к. это нарушит иммутабильность. А если выйти из ситуации через преобразование одного Immutable в другой, то достичь таким способом получится лишь комбинаторного взрыва иммутабильных типов, похоронив тем самым дальнейшую разработку.

Но давай представим другой пример. Допустим, система диспетчеризации аэродрома принимает сигнал о готовности взлета со стороны борта. Разрешать взлет или нет? Кажется, сперва надо то-то проверить перед резолюцией.


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

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

Java 8+

import java.util.Arrays;
import java.util.Scanner;

public class Main {
    enum TestEnum {
        One(1), Two(2), Three(3);

        private int code;

        TestEnum(int code) {
            this.code = code;
        }
    }

    public static void main(String[] args) {
        int n = new Scanner(System.in).nextInt();
        boolean isPresent = Arrays.stream(TestEnum.values()).anyMatch(element -> element.code == n);
        System.out.println("n in TestEnum? " + isPresent);
    }
}

1. Integer - неизменяемый.
2. https://stackoverflow.com/a/40523

import java.util.Scanner;

public class Main {
    private static Integer invertDigits(Integer number) {
        Integer temp = 0;
        while (number != 0) {
            temp = temp * 10 + number % 10;
            number /= 10;
        }
        return temp;
    }

    public static void main(String[] args) throws Exception {
        Scanner scanner = new Scanner(System.in);
        Integer number;
        System.out.print("Enter number: ");
        number = scanner.nextInt();
        System.out.println("Reverse digit order: " + invertDigits(number));
    }
}

timedatectl set-timezone Etc/GMT+3

Timestamp ничего не прибавляет, Timestamp.toString() возвращает строку с учётом текущей зоны виртуальной машины.

Timestamp stamp = new Timestamp(1593864000000L); // 07.04.2020 12:00 UTC
System.out.println(stamp.toString()); // 2020-07-04 15:00:00 (Moscow UTC+3)
System.out.println(stamp.getTime() == 1593864000000L); // true

Oracle docs

stackoverflow (без спринга)

В спринг есть планировщик.
Вот тут гайд: https://spring-projects.ru/guides/scheduling-tasks/

Есть несколько вариантов для хранения неориентированных графов.
1. Хранить любую из дорог, а при доступе к ним проверять наличие какой-то из 2
2. Хранить всегда только дорогу из города с меньшим номером в город с большим.
3. Хранить 2 дороги всегда.

В зависимости от задачи бывает удобнее использовать один из этих способов.