Есть ли в Java какой-либо недостаток статических методов в классе?

Question

Предположим, что в моей среде программирования было наложено правило (или практическое правило), что любой метод в классе, который не использует, не изменяет или иным образом нуждается в каких-либо переменных экземпляра для своей работы сделано статичным. Есть ли присущие этому время компиляции, время выполнения или любой другой недостаток?

(отредактировано для уточнения)

Я знаю, что вопрос был несколько открытым и расплывчатым, поэтому я прошу прощения за это. Мое намерение спрашивать было в контексте в основном "вспомогательных" методов. Служебные классы (с частными CTOR, чтобы их нельзя было создавать) в качестве держателей для статических методов, которые мы уже делаем. Мой вопрос здесь был скорее в соответствии с этими маленькими методами, которые ПОМОГАЮТ ВЫБРАТЬ API основного класса.

У меня может быть 4 или 5 основных методов API / экземпляра в классе, которые выполняют реальную работу, но в ходе этого они разделяют некоторые общие функции, которые могут работать только с входными параметрами для метода API, и не внутреннее состояние. Это разделы кода, которые я обычно извлекаю в свои собственные вспомогательные методы, и если им не требуется доступ к состоянию класса, сделайте их статическими.

Мой вопрос был таким: является ли это плохой идеей, и если да, то почему? (Или почему нет?)

Answer 1

Нет, на самом деле причина этого совета в том, что он дает преимущество в производительности. Статические методы можно вызывать с меньшими издержками, поэтому любой метод, для которого не требуется ссылка на this, должен быть статическим.

Answer 2

Не должно быть никаких недостатков - может даже быть небольшое преимущество в производительности (хотя это не поддается измерению), поскольку можно избежать динамического поиска.

Хорошо помечать функции как функции, вместо того, чтобы они выглядели как Методы - (и статические функции «Методы» являются АРЕ, а не методами - это на самом деле по определению).

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

Если статический метод просто принимает собственные значения, то, возможно, вам не хватает нескольких классов; Вы также должны продолжать передавать собственные переменные или библиотечные объекты (например, коллекции) - вместо этого они должны содержаться в классах с бизнес-логикой.

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

Answer 3

В общем:

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

ArrayList badList = new ArrayList();  //bad
List goodList = new ArrayList();  //good

Вам следует разрешить поменять местами реализации, особенно для проверки и тестирования.Внедрение Spring-зависимостей в этом отношении довольно приятно.Просто внедрите реализацию из Spring и bingo, у вас есть почти «статический» (ну, singleton) метод ...

Теперь, те типы API, которые являются чисто «полезными» по назначению (то есть Apache Commons)Lang) являются здесь исключением, потому что я считаю, что большинство (если не все) реализаций являются статическими.В этой ситуации, какова вероятность того, что вы захотите поменять Apache Commons на другой API?

В частности:

Как бы вы элегантно справились с «статичностью»"вашей реализации, когда вы нацелены, скажем, на развертывание Websphere vs. Tomcat?Я уверен, что будет случай (не каламбур), когда ваша реализация будет отличаться между двумя ... и полагаться на статический метод в одной из этих конкретных реализаций может быть опасно ...

Answer 4

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