final vs. private static final

[Raveman]

mam wrazenie, ze wszyscy zawsze uzywaja tego drugiego - czy tak sie powinno
robic? ja osobiscie uzywam tego gdy wartosc jest uzywana w wiecej niz jednej
metodzie, badz moze byc modyfikowana, np. mam metode sprawdzajaca date i
format w jakim musi byc paramter mam podany w final String, gdybym podal go
w private static to wydaje mi sie, ze slabiej by bylo widac co sie dzieje.
Albo testy operacji na stringach, latwiej zobaczyc co sie dzieje jesli
string jest tuz nad sprawdzaniem.

[Krzysztof Wolny]

Post by Raveman
gdybym podal go
w private static to wydaje mi sie, ze slabiej by bylo widac co sie dzieje.
Albo testy operacji na stringach, latwiej zobaczyc co sie dzieje jesli
string jest tuz nad sprawdzaniem.

te 2 zapisy roznia sie znaczeniem a nie tylko tym gdzie sie je pisze:)

wystarczy przeczytac za co odpowiada modyfikator static.

[Raveman]

Post by Krzysztof Wolny

gdybym podal go w private static to wydaje mi sie, ze slabiej by bylo
widac co sie dzieje. Albo testy operacji na stringach, latwiej zobaczyc
co sie dzieje jesli string jest tuz nad sprawdzaniem.

te 2 zapisy roznia sie znaczeniem a nie tylko tym gdzie sie je pisze:)
wystarczy przeczytac za co odpowiada modyfikator static.

moze zle sie wyrazilem chodzi mi o zmienna final oraz o pole private static
final i to czy sie powinno stosowac to pierwsze rozwiazanie dla stalych
wartosci i nie w sensie wydajnosciowym, ale raczej j2ee

[Krzysztof Wolny]

Post by Raveman

Post by Krzysztof Wolny

gdybym podal go w private static to wydaje mi sie, ze slabiej by bylo
widac co sie dzieje. Albo testy operacji na stringach, latwiej zobaczyc
co sie dzieje jesli string jest tuz nad sprawdzaniem.

te 2 zapisy roznia sie znaczeniem a nie tylko tym gdzie sie je pisze:)
wystarczy przeczytac za co odpowiada modyfikator static.

moze zle sie wyrazilem chodzi mi o zmienna final oraz o pole private static
final i to czy sie powinno stosowac to pierwsze rozwiazanie dla stalych
wartosci i nie w sensie wydajnosciowym, ale raczej j2ee

IMHO wiele zalezy od sytuacji, moze podaj przyklad, ktory napedzil Ci
tych watpliwosci i nad nim pomyslimy ?:)

[Raveman]

IMHO wiele zalezy od sytuacji, moze podaj przyklad, ktory napedzil Ci tych
watpliwosci i nad nim pomyslimy ?:)

metoda sprawdzania czy data jest poprawna - wprowadzasz Stringa ( yymmdd ) i
dostajesz boolean. format daty mam w tej funkcji jako stala ( final String
FORMAT = "yymmdd") czy ma sens exportowac ja jako pole ?

[Krzysztof Wolny]

Post by Raveman

IMHO wiele zalezy od sytuacji, moze podaj przyklad, ktory napedzil Ci tych
watpliwosci i nad nim pomyslimy ?:)

metoda sprawdzania czy data jest poprawna - wprowadzasz Stringa ( yymmdd ) i
dostajesz boolean. format daty mam w tej funkcji jako stala ( final String
FORMAT = "yymmdd") czy ma sens exportowac ja jako pole ?

to tez zalezy w jakiej klasie masz ta metode, za co ta klasa jest
odpowiedzialna. choc mysle ze tak czy inaczej mozna ja wyniesc jak pole
klasy, IMHO jest wtedy lepiej widoczne i latwiejsze do modyfikacji.

[Raveman]

Post by Krzysztof Wolny
to tez zalezy w jakiej klasie masz ta metode, za co ta klasa jest
odpowiedzialna. choc mysle ze tak czy inaczej mozna ja wyniesc jak pole
klasy, IMHO jest wtedy lepiej widoczne i latwiejsze do modyfikacji.

ale jesli modifikujesz ja to musisz zmodyfikowac metode, jeszcze mam jedno
pytanie ... czy wypada uzywac w programie funkcji w stylu if
("yymmdd".equals(dateToCheck)){} ? czy tez to musi byc stala ?

[Krzysztof Wolny]

Post by Raveman

Post by Krzysztof Wolny
to tez zalezy w jakiej klasie masz ta metode, za co ta klasa jest
odpowiedzialna. choc mysle ze tak czy inaczej mozna ja wyniesc jak pole
klasy, IMHO jest wtedy lepiej widoczne i latwiejsze do modyfikacji.

ale jesli modifikujesz ja to musisz zmodyfikowac metode

wlasnie nie, taki jest sens *stalych*, ze zmieniasz ja potem tylko w
jednym miejscu, nie w metodach...

Post by Raveman
jeszcze mam jedno
pytanie ... czy wypada uzywac w programie funkcji w stylu if
("yymmdd".equals(dateToCheck)){} ? czy tez to musi byc stala ?

to akurat nie ma sensu bo data raczej nie bedzie miala *wartosci*
"yymmdd" :)



pozatym chyba sie troche nie rozumiemy :)

ja problem Twoj rozumiem tak:

public class Tools
{
private static final String DATE_FORMAT = "ddmmyy";

public static boolean checkFormat(String dateString)
{
SimpleDateFormat sdf=new SimpleDateFormat(DATE_FORMAT);

try
{
sdf.parse(dateString);

return true;
}
catch(ParseException pe)
{
return false;
}
}
}

jest to troche nieoptymalne go obiekt SimpleDateFormat mozna zrobic
statyczny i wtedy uzywac tylko jednej instancji.

[Adam W.]

Post by Krzysztof Wolny
jest to troche nieoptymalne go obiekt SimpleDateFormat mozna zrobic
statyczny i wtedy uzywac tylko jednej instancji.

Tylko o synchronizacji trzeba pamietac, to jzu porsciej zostawic go
niestatycznym

Sam sie ostatnio zdziwilem:
http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html
Synchronization
Date formats are not synchronized. It is recommended to create separate
format instances for each thread. If multiple threads access a format
concurrently, it must be synchronized externally.


Pozdrawiam,
Adam

[Raveman]

Post by Krzysztof Wolny

Post by Raveman

Post by Krzysztof Wolny
to tez zalezy w jakiej klasie masz ta metode, za co ta klasa jest
odpowiedzialna. choc mysle ze tak czy inaczej mozna ja wyniesc jak pole
klasy, IMHO jest wtedy lepiej widoczne i latwiejsze do modyfikacji.

ale jesli modifikujesz ja to musisz zmodyfikowac metode

wlasnie nie, taki jest sens *stalych*, ze zmieniasz ja potem tylko w
jednym miejscu, nie w metodach...

ok, dzieki .. o to mi chodzilo

[thad]

Post by Raveman
mam wrazenie, ze wszyscy zawsze uzywaja tego drugiego - czy tak sie powinno
robic? ja osobiscie uzywam tego gdy wartosc jest uzywana w wiecej niz jednej
metodzie, badz moze byc modyfikowana, np. mam metode sprawdzajaca date i
format w jakim musi byc paramter mam podany w final String, gdybym podal go
w private static to wydaje mi sie, ze slabiej by bylo widac co sie dzieje.
Albo testy operacji na stringach, latwiej zobaczyc co sie dzieje jesli
string jest tuz nad sprawdzaniem.

To ze jest private nie wiele zmiena, kluczowy jest static.
Deklaracja final {X} oznacza ze X jest stale w obrebie instancji obiektu.
Deklaracja static final {X} oznacza ze X jest stale w obrebie klasy co
umozliwia bardzo dobra optymalizacje przez kompilatory JIT. static final
umozliwia kompilatorom JIT wstawienie wartosci w miejscu wywolania
zamiast pobierania zmiennej, co daje efekt podobny do zdefiniowanych
stalych w C.

[Raveman]

Post by thad
To ze jest private nie wiele zmiena, kluczowy jest static.
Deklaracja final {X} oznacza ze X jest stale w obrebie instancji obiektu.
Deklaracja static final {X} oznacza ze X jest stale w obrebie klasy co
umozliwia bardzo dobra optymalizacje przez kompilatory JIT. static final
umozliwia kompilatorom JIT wstawienie wartosci w miejscu wywolania zamiast
pobierania zmiennej, co daje efekt podobny do zdefiniowanych stalych w C.

masz racje, ale mi chodzi raczej o dobre praktyki programistyczne ( w javie
nie wydajnosc jest najwazniejsza )

[Jacek Laskowski]

Post by Raveman
masz racje, ale mi chodzi raczej o dobre praktyki programistyczne ( w javie
nie wydajnosc jest najwazniejsza )

Witaj,

Wydaje mi się, że dobre praktyki programistyczne są wypadkową m.in.
prac podnoszących wydajność aplikacji. W końcu kto by chciał mieć
dobrze (uwaga: przymiotnik) zaprojektowaną aplikację, która
ślimaczyłaby się i nie dałoby się na niej pracować? Jedno i
drugie jest ważne, ale dobra praktyka to sposób na obniżenie
kosztów rozwoju i późniejszego utrzymania aplikacji (to interesuje
twórców aplikacji - jedna strona), natomiast wydajność jest cechą
określaną per projekt i ma znaczenie dla użytkowników końcowych
(druga strona - strona płacąca).

Jacek