Я думаю, что хорошо создавать статические классы утилит, особенно когда вы не совсем уверены (пока), каким должен быть дизайн, потому что вы все еще изучаете проблемную область.
Статичность - это маркер "еще не разработан должным образом". Часто статическое решение совершенно адекватно; но иногда, по мере развития проекта, вы обнаруживаете, что вам действительно нужно переписать эту «целую часть», но у вас (на этом более позднем этапе) гораздо более полное понимание предметной области, и, следовательно, вы в состоянии реально разработать «правильное решение» этих проблем.
Я думаю, что мы, программисты, несправедливо забиваемся о «переделках». Вы должны выполнить работу, чтобы понять работу достаточно хорошо, чтобы выполнить работу должным образом. Я не вижу выхода из этого улова 22;
Я могу привести множество примеров статики из основного API. java.lang.Math, java.util. Массивы, java.util. Коллекции. НО, пожалуйста, обратите внимание, что эти классы являются «утилитарными классами», которые существуют только для предоставления нескольких статических методов. ИМХО, наличие статических методов в «объекте с состоянием» просто требует рефакторинга.
Готов поспорить, что сегодняшним разработчикам API хотелось бы иметь возможность разбивать Integer (и другие классы-обертки) ... НО они хорошо и действительно привязаны к тому, что у них есть. Что само по себе является предупреждением ... что static подразумевает final, и есть чертовски веская причина, по которой (в отличие от C ++) java-методы могут быть переопределены по умолчанию . Статика по своей природе является более «связывающей», чем нестатическая ... в том, что вы НЕ МОЖЕТЕ адаптировать реализации к различным ситуациям, контекстам и т. Д. И т. Д. И т. Д.
Приветствия. Кит.