В C/С++ мы используем статические локальные переменные для поддержания состояния метода. Но почему он не поддерживается в Java?
Да, для этой цели я могу использовать статическое поле. Но разве не странно создавать поле для сохранения только одного состояния метода?
Вы нашли единственное решение.
Java отбросила ряд сложностей из С++, и это было одно из них.
Статические переменные, привязанные к функции, делают неприятные вещи для вас в concurrency (например, strtok - классный противник, который можно использовать с pthreads именно по этой причине).
В общем, вам нужен объект с состоянием. Затем соответствующая функция должна иметь переменную уровня объекта. Затем вы можете создавать экземпляры, каждый из которых поддерживает состояние.
Намного легче понять/поддерживать/etc.
Если вам действительно нужно поддерживать состояние как одноэлементное, тогда это статические поля.
Спецификация языка Java, похоже, не защищает пропуск переменных, соответствующих переменным C static.
Скрытие состояния в методах класса имеет несколько недостатков, если смотреть с точки зрения Java. Как правило, существование статической переменной уровня функции не является видом детализации реализации, который вы хотите выставить вне этой функции.
Но состояние метода фактически является частью состояния класса, и статические переменные уровня метода должны быть сериализованы/десериализованы в любое время, когда объект сохраняется. Это может показаться неслучайным, исходя из фона C, поэтому я остановлюсь на нескольких распространенных примерах.
Если значение переменной стоит сохранить, когда объект сохраняется, тогда есть хорошая вероятность, что код за пределами этого класса должен будет ссылаться на это значение. И вдруг это означает определение уровней доступа - статическая переменная в публичном методе автоматически публикуется? Или программист должен объявить это так?
Мы также должны думать о расширяемости. Должны ли производные классы выполнять одну и ту же статическую переменную? Или будет ли ссылка на переменную из функции базового класса?
Скорее всего, что метод C, который использовал бы статическую локальную переменную, был бы хорошим кандидатом для класса в Java. У этого есть состояние и, надеюсь, существует для одной цели. Небольшой недостаток заключается в том, чтобы инкапсулировать функциональность в объект и сделать более четкое разделение между временными значениями (такими как локальные переменные) и более долгосрочным состоянием.
Некоторые из других ответов показывают, почему вы, возможно, не захотите этого. Но вы также можете спросить, почему с исторической точки зрения.
Чтобы ответить на это, вы должны начать понимать, почему C имеет статические локальные переменные. C имеет гораздо меньше средств, чем Java и С++, чтобы ограничить область действия переменной, единственными параметрами для статических данных являются "внутри файла" и "везде". Таким образом, это обеспечивает дополнительный уровень, чтобы ограничить область.
Важным аспектом С++ является совместимость с, поэтому он также разрешен на С++. Но он больше не нуждается в локальной статической области, потому что существует множество других способов ограничить область статических данных. Использование не пользуется популярностью в (современном) С++.
Java просто сильно вдохновляет C/С++, ему не нужно беспокоиться о обратной совместимости, поэтому ее можно было бы оставить без внимания.
Возможно, потому, что методы не являются объектами в Java; поэтому поддержание их состояния, как вы сказали, не имеет большого смысла, и я думаю, вам нужно было бы создать для него новую концепцию в байтовом коде; используйте объект, как сказал Тони К.