объявление переменных и методов как 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.
Кстати, а в каком ЯП он корректен?