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

Вот как раз тот момент, конечно можно прибегнуть и к экзотике, но есть принцип 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, то приведи конкретный пример, как это должно быть реализовано по твоему, а мы покритикуем