umka_maxНа собеседовании задали такой вопрос.
Вот так вот просто, без контекста.
Именно методы? Вопрос "почему" не является корректным. Более точным вопросом было бы "Когда...", или "В каких случаях..."
Есть масса примеров, когда без статических методов не обойтись.
А на собеседовании, конечно же стоило рассказать и про полиморфизм и про состояние, а так же единение данных с поведением и прочее ООП.

umka_max2. Хотя бы пару из "массы примеров"?
Мне думается, что это, в принципе, мне известно. Просто хочется убедиться и систематизировать как-то. :)
Можно часто столкнуться с ситуацией, что какой-то новый метод не понятно куда бы запихать и тогда его от безысходности пихают в MyBusinessLogicHelper и используют из других методов. Такой метод принимает какие-то объекты, и оперирует их состоянием, нарушая всяческую инкапсуляцию. Так возникает Anemic Domain Model. При правильном дизайне логика находится как можно ближе к состоянию, которым она оперирует. И статические методы имеют право на жизнь лишь в некоторых ограниченных сценариях вроде фабрик.

questionerмне расскажешь? я никогда таких буквосочетаний не встречал
Not static, not final, not private методы являются виртуальными. Вызов нужного метода определяется в рантайме "динамически".
Статический же полиморфизм это, полиморфизм разруливающийся в compile-time - method overload, hiding для static методов и полей.

Usmanumka_max,
Сейчас модно инжектить (:
Так говорят те, кто не понимает зачем?

Alexey TominИнъекции- очень сложный инструмент.

Нет.

Alexey TominПри неправильном использовании сносит мозги напрочь.

В чем заключается неправильное использование?

Alexey TominПросто когда возникает вопрос "а что сюда будет вставлено", то ответить на него очень сложно.

Никогда не замечал.

Alexey TominС другой стороны- если этот вопрос возникает, значит где-то ошибка дизайна :)

Это с DI никак не связано.

Alexey TominВременами появляющаяся статьи "это DI только всех запутывает" говорит, что там есть обо что споткнуться.

Таких статей бывает два вида. Либо написаны нубами и не выдерживают никакой критики. Либо написаны экспертами с четким разделением достоинств и недостатков, в которых достоинства всегда более убедительные.

Alexey TominРеальная зависимость оказывается больше, чем указанный интерфейс. Если при обычном (вызов конструктора руками) использовании легко выяснить, кто тут будет, то DI затрудняет ответ на этот вопрос.
Но, по-хорошему, этого вопроса не должно возникать.
Loose coupling. Вопрос должен возникать и это резонно. Но я не могу понять откуда берется проблема определенние экземпляра.

Alexey TominПросто DI проявляет эту ошибку. Без него с ней живут годами, не замечая источника проблем.

Это тоже к DI отношения не имеет. Люди годами пишут говнокод не замечая проблем. Люди такие люди.