летатель космосаСоздаем класс Base, c полями и методами. Затем создаем экземпляры этого класса. Каждый экземпляр - объект в памяти со своей копией полей. Копий методов не создается же, они всегда в одном экземпляре, как и static поля. В чем тогда смысл static методов? Только в том, что их можно вызывать не создавая экземпляр класса, в котором они определены?
В до-ООП-шную эпоху кодеры писали код без объектов. Вызывая процедуры и функции
в контексте.

Например




где контекст мог определять некое глобальное состояние приложения или просто
некое состояние вычислений. Косвенно, такой способ и сейчас используется
ассемблером для иммитации ООП и JVM примерно работает так-же.

Во времена развития Java 1.1-1.4 вызвать функцию синуса можно было только указав
имя объекта Math:




У математиков подобная форма юзкейса вызывает приступы смеха. Представьте себе
как будет выглядеть формула где очень много таких обращений. Здесь удобство
было принесено в жертву ООП идеалам.

Чуть позже был добавлен статический импорт.



Однако JVM все равно ссылается на полное название статик-функции как java.lang.Math.sin.
Впрочем нас это не волнует. Бинарный код обещает быть производительным. А длинное
имя остается способом решения конфликта имен.

По поводу смыслов.

Я думаю смысл static методов понятен. Это функции без состояний. Кстати некоторые
IDE детектируют класс утилит (Utils) и предлагают вам добавить приватный конструктор




Это явный запрет на инстанциирование утилит. Если вы уже кодили мультипоточные приложения
то попадали на "гонки" и "голодания" ресурсов. Это когда есть некая горячая точка в коде
которая является разделяемым объектом и она постоянно всем нужна. И избавление
от гонок - это задача для более высокого уровня seniority. Просто надо больше всего
знать по Java и программно-аппаратной архитетуре.
Здесь многие йуные кодеры пассуют и ищут способов писать надежно и безопасно.
Один из самых простых и надежных вариантов избавления от голодания - это внедрять
как можно больше чистых функций (pure functions) которые с гарантией можно реализовать
как static-методы. При этом еще желательно проанализировать их тело чтоб внутри не было
зависимостей от других разделяемых статических переменных. Есть еще альтернативные
варианты где все таки можно создавать экземпляр утилит и использовать их с ThreadLocal
переменной но он более сложен и требует больше манипуляций.

Спасибо. Есть разные взгляды на ООП. И скажем те технологии которые использует java
- это злостный хак ООП. Например рефлексией и установкой атрибута можно открыть private
поля. Инструментированием можно переопределить поведение методов. И это не пререгрузка
виртуального мать его метода. Это именнно хак.

И поэтому когда говорят о Java-OOP - надо говорить именно о реализации ООП в Java.
А общую философию можно кинуть в мусорное ведро. Она не состоялась. Туда же лесом
идет Бьярне со своими шаблонами.

boobyШаблоны ему от Степанова, вместе с переносом generic-кода STL в наследство от ADA достались.
Ого... вот это поток сознания...