В Java есть специальная аннотация @Deprecated для маркировки уставшего кода. С определенной периодичностью такой код из JDK удаляется. Обычно о конкретных сроках удаления анонс делается заранее и в теории можно успеть подготовиться, но на практике не все так просто.

В больших проектах найти куски устаревшего кода в куче зависимостей задача не тривиальная и требующая хорошей автоматизации. В этой ситуации к нам приходит на помощь новый тип события в JFR. Он был добавлен в JDK 22.

Давайте посмотрим на простом примере как это работает.

Одним из наиболее распространенных «лучших практик» в программировании является принцип DRY: не повторяйся. Для реализации этого принципа можно использовать множество методов: инкапсуляция, параметризация, инверсия управления и многое другое. Одним из этих методов является абстракция, и одно из основных различий между функциональным программированием (FP) и объектно-ориентированным программированием (ООП) заключается в способе применения абстракции. Обычной практикой в ООП является ограничение абстракции до строгого полезного минимума для рассматриваемой проблемы. В ООП преждевременное абстрагирование часто считается ошибкой, как и преждевременная оптимизация.

В FP, с другой стороны, абстракция, как правило, продвигается настолько далеко, насколько это возможно. Каждая проблема разбита на серию простейших возможных функций, которые затем комбинируются для построения решения проблемы. Выявление этих абстракций обычно является наиболее важной частью решения проблемы. Фактически, программисты FP часто тратят больше времени на то, чтобы найти, какую проблему им следует решить, чем на их решение. И, конечно же, обычно кажется, что эти функции одинаковы от одной проблемы к другой. Только способ их комбинирования отличается. Это причина, по которой абстракция является одним из наиболее ценных методов, используемых программистами FP.

В этой статье мы сравним, как ООП и ФП будут обрабатывать абстракцию в конкретной простой задаче: вычислении суммы целых чисел от 1 до произвольного значения n. Проблема настолько проста для решения с помощью императивного программирования, что кажется, что в этом нет ничего интересного. Вот как это можно сделать в Java:

Перевод статьи Роберта Мартина

Недавно я получил письмо:

В течение многих лет проверка понимания принципов SOLID было стандартной частью нашей процедуры приема на работу. Предполагалось, что кандидаты хорошо знакомы с этими принципами. Однако в последнее время один из наших менеджеров, который больше не занимается программированием, усомнился в том, что это разумно. Его аргументы заключались в том, что принцип открытости-закрытости (open–closed principle) больше не очень важен, потому что большая часть кода, который мы пишем, не содержится в больших монолитах, а внесение изменений в небольшие микросервисы безопасно и легко. Принцип подстановки Лисков (Liskov substitution principle) давно устарел, потому что мы не уделяем столько внимания наследованию, как 20 лет назад. Я думаю, нам следует рассмотреть позицию Дэна Норта по SOLID: «Просто напишите простой код».

В ответ я написал следующее письмо:

Принципы SOLID остаются актуальными и сегодня, как и в 90-е годы (и даже до этого). Это потому, что программное обеспечение не сильно изменилось за все эти годы. Оно не сильно изменилось даже с 1945 года, когда Тьюринг написал первые строчки кода для электронного компьютера. Программное обеспечение по-прежнему представляет собой операторы if, циклы while и операторы присваивания - последовательность, выбор и итерацию.

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