• 01/07/2008 06:38
• 

• Git! 0

  Kit! 0

Implementacja pomyslu z http://juliusdavies.ca/logging.html , wczesna beta, open source Apache 2.0/ WTFPL.

http://www.lilianne-blaze.net/wiki/...

Komentarze, uwagi, prosby, sugestie?

p.s. Tak, tak, zrobie tego svna przed koncem tygodnia.

• 01/07/2008 11:09
• 

• Git! 0

  Kit! 0

<Java amateur>

Nazywasz atrybuty klasy tak samo jak parametry metod - nie boisz się ?; o

</Java amateur>

• 01/07/2008 17:14
• 

• Git! 0

  Kit! 0

Czego/ dlaczego mam sie bac?

• 01/07/2008 23:06
• 

• Git! 0

  Kit! 0

Ehm... feedback?; /

• 01/07/2008 23:49
• 

• Git! 0

  Kit! 0

za krótkie jeszcze wieczory na dogłębny audyt kodu;)

• 01/07/2008 23:53
• 

• Git! 0

  Kit! 0

Tak sobie mi sie chce czekac do zimy :/

• 01/07/2008 23:53
• 

• Git! 0

  Kit! 0

a w ramach sugestii: przyda się najpewniej również wersja pod JULa.

• 02/07/2008 00:01
• 

• Git! 0

  Kit! 0

>boska renia napisał
>a w ramach sugestii: przyda się najpewniej również wersja
>pod JULa.

Ktos tego uzywa?; \

Ok, zobacze. Ale z JUL to nie mam zadnego doswiadczenia.

• 02/07/2008 00:03
• 

• Git! 0

  Kit! 0

>Lilianne E. Blaze napisała:
>Czego/ dlaczego mam sie bac?

no dwie nazwy "a" i "a", które znaczą co innego i użycie jednej zamiast drugiej w niektórych sytuacjach nie spowoduje błędu kompilacji są błędogenne

• 02/07/2008 00:26
• 

• Git! 0

  Kit! 0

>bartkiller napisał
>>Lilianne E. Blaze napisała:
>>Czego/ dlaczego mam sie bac?
>
>no dwie nazwy "a" i "a", które znaczą co innego i użycie
>jednej zamiast drugiej w niektórych sytuacjach nie
>spowoduje błędu kompilacji są błędogenne

Konkretniej? setA(int a) { this.a = a} ? To nie jest problem. Zreszta zdaje sie ze zadne wspolczesne ide nie pozwoli na popelnienie w tym bledu. A rzeczy typu "setA(int _a)" daja brzydkie javadocsy.

• 02/07/2008 00:47
• 

• Git! 0

  Kit! 0

>Lilianne E. Blaze napisała:
>Konkretniej? setA(int a) { this.a = a} ? To nie jest
>problem. Zreszta zdaje sie ze zadne wspolczesne ide nie
>pozwoli na popelnienie w tym bledu.

No jasne, że z prostymi setterami nikt nie będzie miał problemu, ale przecież zdarzają się metody na kilkanaście linijek, w których trzeba zrobić coś konkretniejszego i tam już współczesne ide nie zrozumie czy na pewno chciałaś wziąć this.a przed przypisaniem a czy może potem czy odwrotnie czy jest dobrze itp.

>A rzeczy typu "setA(int _a)" daja brzydkie javadocsy.

Niewątpliwie, ale to nie jest jedyna konwencja różna od, mówiąc oględnie "this.a = a". Zwykle raczej atrybutom klasy nadaje się inną formę, a parametry mogą pozostać w intuicyjnej i ładnej postaci.

• 02/07/2008 00:49
• 

• Git! 0

  Kit! 0

> Ktos tego uzywa?; \

Cały stos sunowy od dołu góry jest o to oparty, łącznie z GFem, sunowym JBI, itp itd. Poza tym JUL od wersji JDK1.4 wyewoluował podobnie jak sam język.

• 02/07/2008 00:56
• 

• Git! 0

  Kit! 0

>No jasne, że z prostymi setterami nikt nie będzie miał
>problemu, ale przecież zdarzają się metody na
>kilkanaście linijek, w których trzeba zrobić coś
>konkretniejszego i tam już współczesne ide nie zrozumie
>czy na pewno chciałaś wziąć this.a przed przypisaniem a
>czy może potem czy odwrotnie czy jest dobrze itp.

a pojawia się to gdzieś poza setterami?

• 02/07/2008 01:04
• 

• Git! 0

  Kit! 0

>boska renia napisał
>a pojawia się to gdzieś poza setterami?

W tej chwili mogę tylko strzelać, że tak, bo nie chce mi się przykładu wymyślać.
Dla ułatwienia zaznaczę, że napisałem "prostymi setterami" co miało sugerować, że zakładam istnienie setterów, które nie są proste i robią jeszcze jakieś dodatkowe rzeczy (chyba, że to już nie nazywa się setterem ?).

Ogólnie bardzo sensownie jest w jakiejkolwiek metodzie móc łatwo poznać czy zmienna jest lokalną/parametrem czy atrybutem klasy tylko patrząc na jej nazwę - bez tego wydaje mi się, że kod jest mniej czytelny.

• 02/07/2008 01:34
• 

• Git! 0

  Kit! 0

W zwykłych setterach ta sama nazwa zmiennej co pola jest raczej klasyką i chyba dobrą praktyką, zwiększającą czytelność i "standaryzującą" settery. Idea JavaBeans ("właściwości" klasy) opiera się o konwencję, a nie np. o słowo kluczowe jak w innych językach, więc tym bardziej jest to argument za stosowaniem standardowej postaci definicji setterów/getterów.

Inną kwestią jest natomiast umieszczania bardziej złożonego kodu w setterach/getterach. W kodzie, który wyraźnie oddziela od siebie logikę od struktur danych (na przykład MVC, zdalnych wywołaniach, czy jakichkolwiek bardziej złożonych kontenerach) umieszczanie logiki w getterach/setterach jest bardzo nierozsądne, a w entity beanach nawet wprost zabronione.

Co prawda bez odwołania się do źródeł, ale pozwole sobie na stwierdzenie, że umieszczanie bardziej złożonego kodu od leniwego ładowania w metodach get/set nie jest dobrą praktyką.

• 02/07/2008 01:37
• 

• Git! 0

  Kit! 0

> Cały stos sunowy od dołu góry jest o to oparty

Inaczej - uzywa tego ktos, kto nie musi? W porownaniu z Log4j i LogBackiem to naprawde ssie :/

Dzieki za sugestie, ale - przynajmniej na razie - ja sie tego nie podejmuje.

> Ogólnie bardzo sensownie

To juz kwestia indywidualnego stylu. Osobiscie nigdy nie mialam z tym problemow chyba ze musialam poprawiac jakies _wyjatkowo_ wielkie i monolityczne klasy.

• 02/07/2008 01:45
• 

• Git! 0

  Kit! 0

a co mówią mądre książki o umieszczaniu metod getX/setX bez pola o nazwie X? Czy cokolwiek mówią na ten temat?

• 02/07/2008 02:05
• 

• Git! 0

  Kit! 0

>boska renia napisał
>a co mówią mądre książki o umieszczaniu metod getX/setX
>bez pola o nazwie X? Czy cokolwiek mówią na ten temat?

Musialabym sprawdzic. Zdaje sie ze mowia "setX(int x) {this.x = x; }" i poprzestaja na tym.

• 02/07/2008 02:10
• 

• Git! 0

  Kit! 0

> Musialabym sprawdzic. Zdaje sie ze mowia "setX(int x) {this.x = x; }" i poprzestaja na tym.

Chodziło mi również o to, czy dobrą praktyką jest umieszczanie metod getX/setX, które de facto nie są accessorami pól.

• 02/07/2008 08:44
• 

• Git! 0

  Kit! 0

>Lilianne E. Blaze napisała:
>To juz kwestia indywidualnego stylu. Osobiscie nigdy nie
>mialam z tym problemow chyba ze musialam poprawiac jakies
>_wyjatkowo_ wielkie i monolityczne klasy.

No jak się pisze samemu dla siebie to pewnie, że nie ma co dyskutować jak lepiej, bo i tak każdy będzie po swojemu pisał :) Natomiast jeśli chodzi o kod, który być może będą czytać/poprawiać inni to zdecydowanie nie jest to kwestia indywidualnego stylu.

>Chodziło mi również o to, czy dobrą praktyką jest umieszczanie >metod getX/setX, które de facto nie są accessorami pól.

ad meritum.... - dla uproszczenia może rozmawiajmy o innych metodach niż set/get - bo przecież klasy nie składają się tylko z takich. Interesuje mnie właśnie czy takie nazewnictwo to jakaś dość powszechnie przyjęta konwencja ?