Pola i metody statyczne

Witam,
piszę ostatnio większy projekt w JAVIE i zacząłęm dosyć często korzystać z metod i pól statycznych. Do tej pory nie używałem ich zbyt często, nie wiem czy teraz nie nadużywam. Proszę kogoś, żeby wyjaśnił po krótce zasady używania pól statycznych. Czy takie programowanie jest w dobrym stylu?

Najlepiej brać przykład ze Scali :)

Zamiast pól i metod statycznych zrobić osobną klasę jako singleton.

Zaleta jest taka, że singleton może dziedziczyć po czymś (dzięki czemu nie trzeba kopiować metod), implementować interfejsy (czyli zewnętrzne klasy mogą wiedzieć że implementuje jakieś funkcjonalności, np Comparable) oraz w przypadku singletonów można korzystać z wstrzykiwania zależności (wstrzykiwanie zależności jest niezbędne przy większych projektach).

@down:
Stałe należy grupować w enumach.

@up: tak, to też należy do dobrych praktyk, ale w niektórych przypadkach bardziej byłbym skłonny do zwykłych intów (jeśli chodzi o wartości liczbowe).
Statyczne pola i metody w języku obiektowym to w ogóle jakiś dziwny pomysł. Jeśli już musisz, korzystaj z singletonów, a co do statycznych pól, powinny być to wyłącznie stałe (static final; albo pola finalne umieszczone również w singletonie).
// Wyprzedzony.

Koledzy oczywiście przesadzają w drugą stronę. Pola i metody statyczne są przydatne gdy mają odniesienie do całej rodziny obiektów tej samej klasy. Pola nadają się nieźle jako liczniki obiektów, a metody na przykład jako dostawców przygotowanego wcześniej obiektu lub serii obiektów. Nie sposób skorzystać nawet z singletona nie posiadając metody statycznej, która go przekaże.

Pola i metody statyczne umożliwiają też pisanie w Javie paradygmatem czysto proceduralnym - bez użycia obiektów (za wyjątkiem jednej klasy obejmującej cały kod). Szczególnie używając wyłącznie typów prostych. Tak napisany program nie różni się zbytnio od interpretowanego języka C.

Pola statyczne rulez. A metody to magia. Wszystko co działa asynchronicznie w kilku wątkach w pewnym momencie musi korzystać a pól statycznych. I żadne metody synchronized tego nie darzą rady zastąpić.
Ja bardzo często ich używam do flagowania eventów...bez statycznych pół to jest praktycznie nie do wykonania w wielowątkowej aplikacji jeszcze z jakimś natywnym kodem gdzie ciagle się coś zakleszcza.

Fakt jest jeden-nie należy przesadzać z nimi bo po to pisze się w Javie - OO żeby to wykorzystąć.

Ok, rozumiem też myśałem o tych singletonach. Ale co zrobić w sytuacji kiedy mam np klasę, w której przechowuję jakieś parametry sesji np w hashMapie i muszę mieć do tej mapy dostęp z kilku klas, bez tworzenia nowego obiektu w każdej klasie się nie da, prawda? Poproszę o jakieś wskazówki...

Wskazówka ... pola statyczne :-) lub jedna klasa parametrów systemu/aplikacji

karol.k:
No to zrób z tej klasy singleton. Jeśli ta klasa ma być w kilku egzemplarzach, to wyciągnij mapę do osobnego singletona. Ew może być tak, że będzie możliwość przekazania tej HashMapy jako parametr każdej klasie która jej potrzebuje (ale do tego lepiej użyć wstrzykiwania zależności).

Wtedy zamiast:
KlasaZeStatycznymDziadostwem.getLicznik()

Mamy:
Singleton.getInstance().getLicznik()

Tyle, że to i tak jakoś dużo nie daje (oprócz możliwości dziedziczenia). Singletony dobrze się sprawują przy wstrzykiwaniu zależności, np (z użyciem Google Guice) - klasa Konfiguracja jest singletonem (poprzez ustawienie Scope.SINGLETON):
Konfiguracja konfiguracja = injector.getInstance(Konfiguracja.class)

W klasie konfiguracja może być np pole zawierające konfigurację połączenia do bazy danych:
@Inject Połączenie połączenie;

I inne pola tego typu, automatycznie wstrzykiwane (jeśli wstrzykiwane klasy też mają pola zaadnotowane @Inject to obiekty tych klas są rekurencyjnie wstrzykiwane) przy wywoływaniu injector.getInstance( ... );

Scope może być inne niż SINGLETON np ServletScope.REQUEST. Wtedy mamy jeden i ten sam obiekt na czas całego żądania HTTP. W sytuacji gdy mamy wiele wątków i trzeba np utworzyć dla nich kilka egzemplarzy pewnej klasy, po jednym egzemplarzu dla np max 5 wątków to można stworzyć nowy Scope.

Przy programowaniu na wiele rdzeni (vide GPGPU) zapis do pamięci współdzielonej jest tragicznie wolny.