объявление переменных и методов как static является ли как плохим стилем программировани?

вообще  я читал что лучше что бы не было таких.

хотел бы узнать тогда примеры, когда без static вообще никак, кроме слуая c main()

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



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

Про методы:
Иногда есть необходимость отделить алгоритм от данных. Вернее алгоритм не нуждается в запоминании данных. Такие методы неплохо объединить в классы-утилиты. Хороший пример, всем известный класс java.lang.Math со своими статическими методами cos(), sin() и т.д.

Как таковые, static-члены не являются ни плохими, ни хорошими. Другое дело, что в не всегда их применение является оправданным.

Думай об этом так: если значение поля будет различным для каждого из объектов данного класса, то они не должны являться статичными. Если же это свойство распространяет свое действие на все объекты класса, и его значение является одинаковым для всех них - это static-поле.
Аналогично, если метод нуждается для своей работы в данных из конкретного экземпляра - это обычный метод. Если же он имеет смысл и без создания экземпляра класса - это static-метод. Например, Calendar.getAvailableLocales(). Для получения списка возможных локализаций календаря нам нет необходимости создавать реальный объект - ведь для всех экземпляров календаря этот список будет одинаковым.

 Больше эту штуку не читай )

Добавлено @ 10:11 
Пример: паттерн singleton. Ну и как его без static сделать? )

Да можно обойтись и без статика, теоретически. Например, создавая некий ключевой файл, или вешаясь на определенный порт. Более того, это решит проблему одного экземпляра на нескольких JVM. Но это все экзотика 

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

Почитай Маленький тест, там это уже обсуждалось 



Это не зло, это просто средство. Другое дело что им можно пользоваться неправильно. Хороший пример привел powerOn, создавать экземпляр java.lang.Math для того чтобы посчитать синус это как минимум глупо.

Пока не появились классы наследники - да. Пока не пошли игры с сериализацией - да.
Поэтому никакого "хорошо" тут нет.

Естественное место для такого "счётчика" - это обычное поле в классе Class данного объекта.




"final static" - это синонимом "const", но только до тех пор, пока хранимый объект является immutable.

Пока "final static" является "const" - всё хорошо.
В противном случае получаем выставленный на всеобщее обозрение и изменение объект, что очень и очень плохо. Это требует доказательств?

Отличное место для хранения констант enum. 




1. Отделение алгоритма от данных != stateless алгоритмам.

а) Паттерн визитор на статик методах пробовали делать? Полиморфизм на статик методах не работает.

б) stateless чаще всего достигается за счёт передачи большого числа параметров в метод. Декомпозиция подобных методов приводит к появлению "кочующих" параметров и прочим антипаттернам структурного программирования.
Избавившись от stateless (связав данные и их обработку) легко избавиться от кочующих параметров.

2. Методы можно очень плохо объединить в классы, особенно stateless методы и особенно в классы-утилиты, содержащие кучу не связных друг с другом методов, порою дублирующих друг друга.  

3. java.lang.Math хороший пример того, как не нужно делать.  Классы с полностью статическими методами не поддаются настройке, и их использование приводит к тому, что более общие классы оказываются в зависимости от деталей реализации (читать про osp, н-р, в книге http://www.ozon.ru/context/detail/id/1573723/  и про ioc).



вот она истина 


Синглтон тоже не бог весть какой полезный паттерн. Он уместен в случаях, когда нужно вынести конфигурацию некоторых связей в приложении из compile в runtime time. Остальные случаи использования синглтонов либо неуместны, либо могут быть заменены апектами, фокусами с атрибутами и прочей кодогенерацией без образования не контролируемых связей в приложении.

Совсем без static-ов не обойтись (в java), но прежде чем их использовать нужно кучу раз подумать над тем, как обойтись без них.

1. Чем мешают наследники?
2. private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException; пока никто не отменял.


Пример как это сделать.

Прямо таки спор что лучше - стул или отбойный молоток....

Если молотком неудобно кушать - это не значит что его надо выбросить.

Это лишь инструмент и как его использовать - решать разработчику. 
Естественно, опираясь на здравый смысл

Наследник обязан увеличивать счётчик при своём создании или нет?
А кто гарантирует, что какой-то наследник не решит воспользоваться этим полем по своему усмотрению, а в итоге перестанет работать класс родитель?
И т.д.




По дефолту статик поля не сериализуются. 
Нужно делать это вручную.
Нужно проверять в той ли jvm был восстановлен объект, чтобы корректно изменять счётчик.
Является акт десериализации созданием объекта? 
И т.д.


Я привёл пример, как сделать счётчик "правильно".
То, что Class класс идущий в составе jdk нельзя модифицировать (без игр с рантаймом) не значит, что мой пример не корректен.

Добавлю свои 5 копеек.
Игры с синглтонами могут очень быстро привести к OutOfMemory PermGen space'а. Это я говорю про рестарт веб-приложений. Так что в j2ee лучше даже и не думать пользоваться паттерном синглтон.

Если криво программить, то и сингелтона для этого необязательно  

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

думаю, что  не всегда при уменьшении кода улучшается его читабельность. 

Все зависит от конкретных условий, но и то и другое поведение можно реализовать.


1. Кто мешает сделать его приватным?
2. Где гарантия, что некий злоумышленник не воспользуется рефлексией и не развалит вообще все?


А зачем нужно сериализовать счетсчик объектов?


Зачем это все нужно? Объект был создан? Был. Увеличиваем счетчик. Тем более что при сериализации конструктор все равно вызывается, можно сделать так, что достаточно будет существующих методов.
Там еще есть clone(), но там проблемы тоже решаются.



Он некорректен для Java.
Кстати, а в каком ЯП он корректен?

полностью согласен, пользуюсь не часто(как в последнее время и на яве попрограммисть не умного бывает времени), однако бывает иногда удобно приписать статик ничего сверхтакого не придумывая

Вот как раз тот момент, конечно можно прибегнуть и к экзотике, но есть принцип KISS - "Keep it simple, stupid"  

А кто сказал, что "ВСЕГДА"? В данном случае читабельность однозначно улучшится из за того, что строчек создания и инициализации обьекта, не влияющих на логику программы станет меньше.

В итоге мы говорим об одном и том же, все дело в ровности рук
Но где к примеру учат правильно освобождать класс, чтобы он был собран GC?

Рекомендую этот небольшой материал к прочтению дабы избежать в будущем
http://readlist.com/lists/tomcat.apache.or...rs/3/19056.html

http://wiki.apache.org/tomcat/OutOfMemory

и вообще почитать о проблеме
http://www.google.ru/search?hl=ru&q=pe...ngleton&lr=

А между прочим этой "кривостью" грешат и разработчики cglib и (по слухам) Spring.
Ни разу не сталкивались? 

Так что лучше имхо подальше держаться, тем более на начальной стадии программирования.

Это сообщение отредактировал(а) kkorsakoff - 4.12.2006, 18:02

Если сделать его приватным, то можно будет реализовать только одно поведение, а не то и другое.


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


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



Даже у синглтона? А как же чудесный метод, название которого было выделено болдом?




Ещё раз:
Я не предлагаю никому разработать тз на счётчик объектов,  я просто говорю, что у решения с статиком воз и маленькая тележка ньюансов, игнорирование которых приводит к неочевидным ошибкам, а не игнорирование делает решение со статиком отнюдь не "хорошим", как было заявлено изначально.





Ещё раз:
Если бы класс Сlass можно было бы модифицировать - это было бы отличное решение.

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

kkorsakoff, интересные материалы.

Почему же:



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


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


А причем тут синглтон? В данном контексте речь шла о счетчике объектов.


1. Он не для этого создавался, это скорее служебны класс, чем класс общего назначения.
2. Ну поместишь ты статик поля в java.lang.Class и что это тебе даст?




ОК, давай рассмотрим конкретный пример. Есть класс java.util.logging.LogRecord, и у каждого объекта есть уникальный sequenceNumber (например на тот случай если точности таймера недостаточно). Сейчас там все реализовано через static поля. Как ты предлагаешь это все реализовывать без них?

В принципе согласен. Статические переменные вещь не только неудобная, но и опасная (и не только в синглтоне). Их я кстати ввиду не имел, когда про читабельность говорил. 
Но удобство и целесообразность статических функций и констант, я надеюсь, Вы под сомнение ставить не будете?

Я и не спорил, а приводил факты иллюстрирующие недостатки решения со счётчиком на статиках. 






где статик?



Это что такое?

Где находится этот метод?
Кто такой starter?
Откуда будет вызываться inc?
Как наследники класса Starter могут поменять значение countDescendant, настроив его под себя?

 


Как это ни банально звучит, но всё зависит от того, для чего они применяются.


Константы обозначаются парой "final static", что равно в некоторых случаях "const" (об этом я уже писал). Против "const" трудно что-то иметь  Однако const - это не тоже самое, что static. 

Предложи решение лучше.


Об этом я и говорил, ну перенес ты поле count из класса в java.lang.Class, плюс сделал его из статика не статиком, и где тут кардинальное улучшение ситуации? Плюс ты предлагаешь ради одного класса со счетчиком добавить переменную count ко всем классам загруженным в JVM?





Как хочешь, хочешь даш возможность менять этот параметр, не хочешь не даш. Счетчий твой, и ты решаешь как и кто может его использовать.

Уже предложил 

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




Тогда на пальцах.

Counter <- Class A  <- Class B 

В counter хочу считать только экземпляры класса counter.
В A хочу считать экземпляры А + всех наследников.
В В - только количество экземпляров В.

Как мне менять этот параметр? 

Ясное дело, что тут несколько счётчиков надо 



Не для чего применяются, а к чему относятся. Тот же sin к примеру. Если мемберы класса не используются (т.е функция самодостаточна), то можно делать static.

Сам придумал? 

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


Пусть у нас объектов типа Counter - 3, A - 7, B - 13. Значит счетчик в Counter = 3, в A = 20, B = 13. Разве не очевидно, что одним счетчиком тут не обойтись? Или ты сомневаешься в реализуемости таких счетчиков?

"Можно" != "Нужно" (ещё одна народная мудрость).

Н-р, сделав метод статическим мы уже не сможем его перекрыть в классе наследнике. 



Ну так продемонстрируй.  Люблю очевидные вещи.

Очень хочется посмотреть на копи-паст кода из класса counter в A и В, или на новый класс "Counter", который теперь точно будет считать не сам себя, а другие классы.

И больше всего, хочется увидить "простоту" с какой static'и позволяют всё это сделать 

Добавлено @ 14:21 


Следим за логикой:



Статики - это плохо. Классический пример плохого кода, который получается с их использованием: подсчёт количества экземпляров класса.

То, что другого решения для вас не существует, вовсе не значит, что плохой код сразу должен стать хорошим.

Вопрос:
Где я предлагаю отказаться от выполнения задачи?  Если такого места нет, то зачем пытаться мне это приписать?

Естесственно нет. Естесственно любой инструмент надо применять по делу, а не просто так. Зачем например sin  в наследниках переписывать???

Ты имеешь в виду, научить тебя пользоваться Ctrl+C, Ctrl+V? 



А где я приписывал тебе, что ты предлагаешь отказаться от выполнения задачи? Там все безлично 

NotGonnaGetUs, ты пока что не привел ни одного конкретного примера, а только критикуешь и сыпешь народными мудростями.
Раз уж ты ратуешь за возможность изменения java.lang.Class, то приведи конкретный пример, как это должно быть реализовано по твоему, а мы покритикуем 

Ты имеешь в виду, что копи-паст это "хорошее" решение?!



Т.е. ты просто о чём-то своём решил поговорить и к цитате из моего сообщения реплика не имеет отношения? ) 




А что мне остаётся делать в ответ на утверждение, что плохой код является хорошим, потому что другого нет?!

Согласись, что static'и приводят к плохому коду и всё станет на свои места 



Нутро jvm знает о количестве объктов и классах всё.
В Class добавляем native методы "получитьКоличествоОбъектов()/получитьКоличествоВключаяНаследников()", которые из jvm выбирают всю необходимую информацию.
Если в каком-то из пользовательских классов потребуется считать подобные величины, нужно будет просто дёрнуть соответсвующий метод у this.getClass().

Никакого мозготраха. Остальные требования легко реализуются на этом базисе.


Это сообщение отредактировал(а) NotGonnaGetUs - 8.12.2006, 18:10

Я не вижу в этом коде, ничего плохого (ну кроме того, что он тебе не нравиться  ). Он работает и работает нормально. Что еще требуется?



Действительно! Что может быть легче для прикладного программиста, чем написать native функцию которая будет лезть в нутро JVM и доставать отуда информацию о количестве объектов (особенно легко это будет делать если надо еще всех наследников считать).
Вот тут уж точно не будет никакого мозготраха, потому как кроме парочки маньяков, никто так делать не будет.

Кстати, исходники JVM открыты, так что в подтверждение своей теории можешь попробовать реализовать такую функциональность у java.lang.Class 

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

Это значит "ничего плохого"?  Хорошо, что я работаю не в одной команде с вами 6)




Это шутка юмора такая или ты, действительно, не понимаешь что хорошие и плохие решения существуют не зависимо от того можешь ты их реализовать или нет?

Возьми любую прикладную библиотеку. Наверняка, там надётся что-то, что тебе захочется поменять/переделать. Н-р, добавить поле или метод в недостаточно хорошо спроектированный  библиотечный класс. То, что никто тебе это не даст этого сделать, не сделает требующий изменений класс автоматически "хорошим". 
И тем не менее, именно такое заявление ты делаешь сейчас относительно счётчика на статиках.

Это сообщение отредактировал(а) NotGonnaGetUs - 11.12.2006, 12:27

!  powerOn

NotGonnaGetUs, давайте на личности не будем переходить. ;-)

Что-то я не припомню среди них, ни одно не решаемой. В основно они сводятся к: "а вот если мне понадобится ...".



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



Прикладная библиотека вещь заменяемая намного легче, чем основы ЯП. Так что пример не корректен.
Насчет счетчика я заявляю что:

• это работает
• работает так как мне надо
• легко реализуется
• кому не нравится, пусть не использует 

Взаимно 

Все проблемы решаемы. Даже если все поля всех классов сделать статическими можно будет решить любую задачу...

О копи-пасте, как одном из способов решения всех проблем, я уже услышал...


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

Программирование без философии - это просто кодоклепание.


Пример более, чем корректен. Класс Class - это всего лишь часть java api такая же как класс ArrayList.




Ага, и т.к. решение со статиком создаёт кучу проблем, то оно всё-таки не хорошее? 

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

Ну так чем он плох? Я до сих пор не услышал ни одной конкретной претензии, только обвинения, в том что я не понимаю "что такое хорошо, и что такое плохо".


Ну, да конечно 
Как по твоему должен работать ClassLoader без Class? Или ClassLoader тоже опциональная вещь, от которой можно тоже легко отказаться? 


1. Мне оно не создает проблем
2. Логическую цепочку решение со статиком создаёт кучу проблем => оно всё-таки не хорошее ты сам придумал, я такого не писал.