У CompletableFuture есть ещё интересные функции. Например, надо построить цепочку из асинхронных вызовов. Т.е. после завершения первой асинхронной функции запустить вторую, после второй третью и т.д. В JavaScript для этого применяются promise. В Java можно использовать CompletableFuture.

Время от времени появляется необходимость выполнить асинхронно (т.е. одновременно с основным действием программы выполняется другая задача) какой-нибудь код. Например, отправить письмо по e-mail или что-нибудь из базы данных прочитать. В Java для подобных операций можно создать поток и выполнить в нём нужное действие.

Приходилось ли вам реализовывать поиск объекта в БД по условиям в виде: ищем объект по Условию А; если Объект не найден по Условию А, то ищем его по Условию Б; если и теперь не найден, то ищем по Условию В?

Тоже впечатлены элегантностью работы с Retrofit и Spring Data JPA? Когда вы просто добавляете в интерфейс сигнатуру метода, а при вызове этого метода оказывается, что он реально работает!

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

Согласно тесту Тьюринга, если что-то плавает как утка, крякает как утка и летает как утка, то это что-то — утка. Но что делать, если при этом она не работает без батареек?

Если в вашем приложении объект пришёл к вам по референсу на базовый класс, но ведёт себя не так, как вы ждёте от базового класса, то у вас в приложении нарушен один из принципов SOLID — Liskov Substitution. Ошибка частая и не сразу заметная.

Странный вопрос для программиста. С одной стороны, мы только и работаем что с числами. Все наши программы с их несчётными фабриками, хэлперами, интерфейсами и менеджерами для процессора – набор чисел: прочитай, увеличь, сдвинь, сохрани.

Решил рассказать немного про аннотацию @Autowired. Принцип её работы очень прост.

Допустим у нас есть bean-зависимости:

@Configuration
public class Config {
    // тип бина - ServiceDependency, имя - dependency
    public ServiceDependency dependency() {
        return new ServiceDependencyImpl()
    }
}

Под словом «Spring» обычно подразумевают просто IoC-контейнер, помогающий структурировать Java-приложения. В действительности под словом «Spring» скрывается целый мир.

IoC-контейнер, это замечательный способ собрать приложение «по кусочкам» из разных компонентов. Spring же предоставляет удобные способы как написания данных «кусочков», так и объединения их в единое приложение. Например, у нас есть два класса.

Часто случается, что в unit-тестировании выполняется серия тестов, которые отличаются только входными значениями и ожидаемыми результатами. Обычный @Test метод позволяет проверить поведение в одном конкретном сценарии. Что делать, если хочется протестировать некоторую функциональность на некотором множестве входных данных?