-
Koziołek [brat Javowiec]
Co innego w zamian? Notacja węgierska? IMO fuj. Java dopracowała się konwencji JavaBeans i chyba trzymanie się jej nie wymaga jakiś super zabiegów. -
bartkiller
>Koziołek [brat Javowiec] napisał
>Co innego w zamian?
Przecież napisałem - jest dużo różnych prostych konwencji, które pozwalają na łatwe odróżnianie atrybutów od zm. lokalnych/parametrów: np. przedrostki "_" lub "m_" lub "m", lub przyrostek "_", które są dość powszechnie stosowane np. w C++.
>Java dopracowała się konwencji JavaBeans i chyba trzymanie się
>jej nie wymaga jakiś super zabiegów.
Jak ostatni raz "widziałem" język Java (a dawno to było temu :) ) to chyba jednak "standardowa", zalecana konwencja odróżniała te byty (chyba, że źle pamiętam). Więc dziwi mnie, że teraz tak "się pisze" :O
(i chciałem się upewnić, że w istocie tak jest, a nie, że jest to tylko styl autorki tematu - jeśli tak, to nie nazwałbym tego 'dopracowaniem się' tylko regresem; P) -
Lilianne E. Blaze
>odróżniała te byty (chyba, że źle pamiętam). Więc
>dziwi mnie, że teraz tak "się pisze" :O
>(i chciałem się upewnić, że w istocie tak jest, a nie,
>że jest to tylko styl autorki tematu - jeśli tak, to nie
>nazwałbym tego 'dopracowaniem się' tylko regresem; P)
Nie wiem (i prawde mowiac nie robi mi to jakiejs specjalnie duzej roznicy) na ile jest to przyjete, ale tak na szybko to powiedzialabym ze tak bylo w co najmniej 2/3 kodu - i komercyjnego i open - ktory widzialam/ przy ktorym pracowalam.
I naprawde nie uwazam (moi wspolpracownicy tez nie) zeby to zmniejszalo czytelnosc, chyba ze kod jest juz i tak malo czytelny z X innych powodow. -
the_javu
Przecież nie zawsze właściwość musi być polem. Metody typu setX
i getX nie będące akcesorami sensu stricte przydają się choćby przy Java Server Faces. Składnia właściwości powoduje refleksyjne wywołania metod o takich nazwach. -
-
bartkiller
Rozumiem. Mnie się wydaje, że ciężko by mi się pracowało w takiej konwencji (piszę głównie w C++ i C#). No i trudno zaprzeczyć, że daje ona _możliwość_ pomyłki, natomiast te, o których wspomniałem ją wykluczają :) Ale z tego co mówisz wynika, że pewno jest to zjawisko marginalne. -
Koziołek [brat Javowiec]
>bartkiller napisał
>Jak ostatni raz "widziałem" język Java (a dawno to było
>temu :) ) to chyba jednak "standardowa", zalecana konwencja
>odróżniała te byty (chyba, że źle pamiętam). Więc
>dziwi mnie, że teraz tak "się pisze" :O
>(i chciałem się upewnić, że w istocie tak jest, a nie,
>że jest to tylko styl autorki tematu - jeśli tak, to nie
>nazwałbym tego 'dopracowaniem się' tylko regresem; P)
Odróżnianie jest oparte o "ludzką" gramatykę. Poza setterami i getterami są proste zasady:
- pola klasy to przymiotniki,
- metody to czasowniki,
- nazwy klas to rzeczowniki.
Co do zasady się sprawdza. Dodatkowo w wiele narzędzi opiera się o zasadę "Convension Over Configuration". Dobrym przykładem jest JUnit, który rozpoznaje nazwy metod testowych na podstawie przyrostka Test w nazwie. Trochę inaczej wygląda to w mavenie, który o ile jest pozostawiony "sam sobie" w kwestii nazewnictwa i struktury projektu to świetnie potrafi zarządzać tymi sprawami. -
Lilianne E. Blaze
-
boska renia
>Lilianne E. Blaze napisała:
>Ok, ale moge jakis feedback n/t kodu a nie skladni?; /
Mówimy tu o Javie, więc "convention over configuration" - to jest tutaj ważne, a nie jakiś kod;) Jest to chyba najważniejsze pojęcie w tym języku -- Java to zdecydowanie język konwencji, w którym "dobre praktyki" są dosyć istotne; i jest to zdecydowanie w kontrze do języków C/C++/C#.
> - pola klasy to przymiotniki,
po tym stwierdzeniu nabrałem wątpliwości, ale jednak pozwole sobie na stwierdzenie, że pola są zwykle rzeczownikami; przymiotnikami jeśli już, to są pola statyczne (stałe). -
bartkiller
>Koziołek [brat Javowiec] napisał
>Odróżnianie jest oparte o "ludzką" gramatykę. Poza
>setterami i getterami są proste zasady:
>- pola klasy to przymiotniki,
>- metody to czasowniki,
>- nazwy klas to rzeczowniki.
Omg, przecież to zupełnie nie na temat. (Inna sprawa, że to co ja poruszyłem jest na granicy offtopu :) ) - chodziło mi o... zresztą przeczytaj sobie no :X -
boska renia
>Lilianne E. Blaze napisała:
>Ok, ale moge jakis feedback n/t kodu a nie skladni?; /
drobne uwagi na drugi rzut oka:
-- tworzenie klas z samymi metodami statycznymi jest czasem wątpliwe; korzystanie z metod statycznych skutecznie ogranicza możliwość skorzystania z polimorfizmu; lepiej raczej wstawić jedną statyczną metodę getInstance(). To raczej ogólna uwaga, nie musi być tutaj w pełni trafna. Klasę z samymi metodami statycznymi wypada wtedy sfinalizować.
-- w żadnym z dwóch plików jar nie znalazłem includowanej klasy "net.lilianne_blaze.debugstrin gutils.DebugStringBean" -
boska renia
>bartkiller napisał
>Rozumiem. Mnie się wydaje, że ciężko by mi się
>pracowało w takiej konwencji (piszę głównie w C++ i C#).
Ja natomiast z moich przygód z C++ (a raczej BC++) pamiętam dziesiątki dziwnych słów kluczowych oraz "bardzo znaczące" podwójne podkreślenia przed nazwami metod. To właśnie mnie zdecydowanie odrzuciło od tego języka w kierunki Javy; w której sam język jest twardą i nienaruszalną bazą i, szczególnie po wprowadzeniu adnotacji, dziesiątki magicznych słów kluczowych nie są potrzebne. -
Lilianne E. Blaze
>boska renia napisał
>drobne uwagi na drugi rzut oka:
>
>-- tworzenie klas z samymi metodami statycznymi jest czasem
>wątpliwe; korzystanie z metod statycznych skutecznie
>ogranicza możliwość skorzystania z polimorfizmu; lepiej
W zasadzie sie zgadzam, ale tu (HeaderPatternUtils) jest praktycznie sam glue code i to dosc malo. Mialoby to sens gdyby calosc rozbudowac o kompletna dowolnosc dobierania dodatkowych informacji, ale wtedy to juz by byl przerost formy nad trescia.
>-- w żadnym z dwóch plików jar nie znalazłem
>includowanej klasy
>"net.lilianne_blaze.debugstri ngutils.DebugStringBean"
Jest napisane na samym poczatku, "requires (linki)", kod w zalacznikach. http://www.lilianne-blaze.net/wiki/... (wymagane) i http://www.lilianne-blaze.net/wiki/... (opcjonalne) -
bartkiller
>boska renia napisał
>Ja natomiast z moich przygód z C++ (a raczej BC++)
>pamiętam dziesiątki dziwnych słów kluczowych oraz
>"bardzo znaczące" podwójne podkreślenia przed nazwami
>metod. To właśnie mnie zdecydowanie odrzuciło od tego
>języka w kierunki Javy; w której sam język jest twardą i
>nienaruszalną bazą i,
Nie wiem czy chcemy tu kontynuować dyskusję o wyższości jednego nad drugim (bo autorka wątku nas zabije; -) ). Generalnie raczej Twój problem tkwił raczej w BC++, a nie w istocie C++. Teraz już się tak nie pisze i zdecydowanie sam język nie wymusza korzystania z tych mechanizmów. Gwarantuje Ci, że również w Javie da się napisać gówniany kod :)
Dodatkowo nadchodzący standard C++0x bardzo zbliży C++ do Javy jeśli chodzi o wygodę użytkowania (w szczególności będzie mieć też parę rzeczy, których wydaje mi się, że w Javie nie ma (np. funkcje lambda) (am i right ?)).
>szczególnie po wprowadzeniu
>adnotacji, dziesiątki magicznych słów kluczowych nie są
>potrzebne.
Też mi zamiana - dziesiątki magicznych słów kluczowych na dziesiątki magicznych adnotacji; P -
boska renia
> Też mi zamiana - dziesiątki magicznych słów kluczowych na dziesiątki magicznych adnotacji; P
Kończąc offtop dodam tylko, że magiczne słowa kluczowe to element języka, natomiast adnotacja to twór na poziomie kodu, którego definicja jest widoczna dla programisty. Nie wspominę już o możliwości skompilowania "kodu C++" (cokolwiek to oznacza) pod różnymi kompilatorami, które tej magii zupełnie nie rozumieją;)
- Przeglądaj grona w kategorii Internet i Komputery
- Przeglądaj grona w okolicy Warszawa
- Załóż własne grono tematyczne
- Zostań moderatorem
Podobne Tematy
|
|
Wszystko co związane z programowaniem w Java (J2EE, JSP, JDBC, itd) test
Fotki
Miejsca grona (1)
-
Kino Luna ul. Marszałkowska, Warszawa
www.kinoluna.pl kino.luna@maxfilm.com.pl 22 621 78 28
- Dodaj miejsce