🚀 go-pugleaf

W dniu 2013-01-03 09:40, Jadalbert pisze:
> problem (czy raczej moja niewiedza) jest taki
> Mam program liczący pewne wielkości i, dajmy na to w uproszczeniu, w
> klasie Geom metodę
> public double V(double x, double y, double z) {
>      return x * y * z;
> }
> gdzieś tam jest to wywoływane:
> V_ = Geom.V(2,3,4);
> czyli trzeba wstawić trzy argumenty. Wszystko działa bez zarzutu.
> Teraz, z klas liczących chcę zrobić beans'y.
> Czyli powinno być tak (opierając się na powyższym przykładzie):
> private double v;
> ...
> public double getV() {return v};
> public void setV(double v) {this.v = v;}

To jest tylko para sette/getter. W zamyśle razem tworzą jedną właściwość 
obiektu.

> i tu, zgodnie z konwencją, metoda set ma tylko jeden argument, a ja
> potrzebuję przekazać 3. Jak wybrnąć sensownie z takiej sytuacji? Osobna
> klasa licząca + osobna typu beans? W beans'ie dodatkowe metody liczące?
> Można oczywiście już w implementacji dołożyć odpowiednie zmienne, ale co
> wtedy przekazywać jako argument?
> Najchętniej wszystko co dotyczy liczenia i, że tak powiem, formalnej
> struktury beans'ów chciałbym mieć w jednej klasie.

Możesz to zrobić np tak

//property X
public double getX() {return x};
public void setX(double x) {this.x = x;}
//property Y
public double getY() {return y};
public void setY(double y) {this.y = y;}
//property Z
public double getZ() {return z};
public void setZ(double z) {this.z = z;}

//property V
public double getV() {return x * y * z;}


Jak widzisz, właściwość V nie ma settera, jest tyko do odczytu. A 
jednocześnie jej getter wykonuje potrzebne obliczenia.

Zauważ że w ciałach setterów/getterów nie musisz wcale pisać/czytać ze 
zmiennych. Możesz na przykład przekazywać wartości do innych obiektów, 
lub bazy danych, albo wołać jakieś funkcje API odwołujące się do 
realnego świata (np. sterować robotem).

-- 
Arivald

W dniu 2013-01-03 10:18, Arivald pisze:
> W dniu 2013-01-03 09:40, Jadalbert pisze:
>> problem (czy raczej moja niewiedza) jest taki
>> Mam program liczący pewne wielkości i, dajmy na
>> to w uproszczeniu, w
>> klasie Geom metodę
>> public double V(double x, double y, double z) {
>>      return x * y * z;
>> }
>> gdzieś tam jest to wywoływane:
>> V_ = Geom.V(2,3,4);
>> czyli trzeba wstawić trzy argumenty. Wszystko
>> działa bez zarzutu.
>> Teraz, z klas liczących chcę zrobić beans'y.
>> Czyli powinno być tak (opierając się na
>> powyższym przykładzie):
>> private double v;
>> ...
>> public double getV() {return v};
>> public void setV(double v) {this.v = v;}
>
> To jest tylko para sette/getter. W zamyśle razem
> tworzą jedną właściwość obiektu.
>
>> i tu, zgodnie z konwencją, metoda set ma tylko
>> jeden argument, a ja
>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>> takiej sytuacji? Osobna
>> klasa licząca + osobna typu beans? W beans'ie
>> dodatkowe metody liczące?
>> Można oczywiście już w implementacji dołożyć
>> odpowiednie zmienne, ale co
>> wtedy przekazywać jako argument?
>> Najchętniej wszystko co dotyczy liczenia i, że
>> tak powiem, formalnej
>> struktury beans'ów chciałbym mieć w jednej klasie.
>
> Możesz to zrobić np tak
>
> //property X
> public double getX() {return x};
> public void setX(double x) {this.x = x;}
> //property Y
> public double getY() {return y};
> public void setY(double y) {this.y = y;}
> //property Z
> public double getZ() {return z};
> public void setZ(double z) {this.z = z;}
>
> //property V
> public double getV() {return x * y * z;}
>
>
> Jak widzisz, właściwość V nie ma settera, jest
> tyko do odczytu. A jednocześnie jej getter
> wykonuje potrzebne obliczenia.
>
> Zauważ że w ciałach setterów/getterów nie musisz
> wcale pisać/czytać ze zmiennych. Możesz na
> przykład przekazywać wartości do innych obiektów,
> lub bazy danych, albo wołać jakieś funkcje API
> odwołujące się do realnego świata (np. sterować
> robotem).
>
Dziękuję za odpowiedź.
Tyle, że dane do getV pochodzą z innej klasy, u 
mnie z takiego kontenera danych. Nie ma więc 
(potrzeby?) get/set właściwości x,y,z w klasie 
liczącej.

Z tego by wynikało, że aby zachować konwencje 
beans'a wystarczy mi jedynie odczytywać wartość:

private double v;
...
public double getV() {
   return kontener.x * kontener.y * kontener.z;
}
Czy dobrze rozumiem?

W dniu 2013-01-03 11:03, Jadalbert pisze:
> W dniu 2013-01-03 10:18, Arivald pisze:
>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>> problem (czy raczej moja niewiedza) jest taki
>>> Mam program liczący pewne wielkości i, dajmy na
>>> to w uproszczeniu, w
>>> klasie Geom metodę
>>> public double V(double x, double y, double z) {
>>>      return x * y * z;
>>> }
>>> gdzieś tam jest to wywoływane:
>>> V_ = Geom.V(2,3,4);
>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>> działa bez zarzutu.
>>> Teraz, z klas liczących chcę zrobić beans'y.
>>> Czyli powinno być tak (opierając się na
>>> powyższym przykładzie):
>>> private double v;
>>> ...
>>> public double getV() {return v};
>>> public void setV(double v) {this.v = v;}
>>
>> To jest tylko para sette/getter. W zamyśle razem
>> tworzą jedną właściwość obiektu.
>>
>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>> jeden argument, a ja
>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>> takiej sytuacji? Osobna
>>> klasa licząca + osobna typu beans? W beans'ie
>>> dodatkowe metody liczące?
>>> Można oczywiście już w implementacji dołożyć
>>> odpowiednie zmienne, ale co
>>> wtedy przekazywać jako argument?
>>> Najchętniej wszystko co dotyczy liczenia i, że
>>> tak powiem, formalnej
>>> struktury beans'ów chciałbym mieć w jednej klasie.
>>
>> Możesz to zrobić np tak
>>
>> //property X
>> public double getX() {return x};
>> public void setX(double x) {this.x = x;}
>> //property Y
>> public double getY() {return y};
>> public void setY(double y) {this.y = y;}
>> //property Z
>> public double getZ() {return z};
>> public void setZ(double z) {this.z = z;}
>>
>> //property V
>> public double getV() {return x * y * z;}
>>
>>
>> Jak widzisz, właściwość V nie ma settera, jest
>> tyko do odczytu. A jednocześnie jej getter
>> wykonuje potrzebne obliczenia.
>>
>> Zauważ że w ciałach setterów/getterów nie musisz
>> wcale pisać/czytać ze zmiennych. Możesz na
>> przykład przekazywać wartości do innych obiektów,
>> lub bazy danych, albo wołać jakieś funkcje API
>> odwołujące się do realnego świata (np. sterować
>> robotem).
>>
> Dziękuję za odpowiedź.
> Tyle, że dane do getV pochodzą z innej klasy, u mnie z takiego kontenera
> danych. Nie ma więc (potrzeby?) get/set właściwości x,y,z w klasie
> liczącej.
>
> Z tego by wynikało, że aby zachować konwencje beans'a wystarczy mi
> jedynie odczytywać wartość:
>
> private double v;
> ...
> public double getV() {
>    return kontener.x * kontener.y * kontener.z;
> }
> Czy dobrze rozumiem?

Dokładnie tak.

-- 
Arivald

W dniu 2013-01-03 11:15, Arivald pisze:
> W dniu 2013-01-03 11:03, Jadalbert pisze:
>> W dniu 2013-01-03 10:18, Arivald pisze:
>>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>>> problem (czy raczej moja niewiedza) jest taki
>>>> Mam program liczący pewne wielkości i, dajmy na
>>>> to w uproszczeniu, w
>>>> klasie Geom metodę
>>>> public double V(double x, double y, double z) {
>>>>      return x * y * z;
>>>> }
>>>> gdzieś tam jest to wywoływane:
>>>> V_ = Geom.V(2,3,4);
>>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>>> działa bez zarzutu.
>>>> Teraz, z klas liczących chcę zrobić beans'y.
>>>> Czyli powinno być tak (opierając się na
>>>> powyższym przykładzie):
>>>> private double v;
>>>> ...
>>>> public double getV() {return v};
>>>> public void setV(double v) {this.v = v;}
>>>
>>> To jest tylko para sette/getter. W zamyśle razem
>>> tworzą jedną właściwość obiektu.
>>>
>>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>>> jeden argument, a ja
>>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>>> takiej sytuacji? Osobna
>>>> klasa licząca + osobna typu beans? W beans'ie
>>>> dodatkowe metody liczące?
>>>> Można oczywiście już w implementacji dołożyć
>>>> odpowiednie zmienne, ale co
>>>> wtedy przekazywać jako argument?
>>>> Najchętniej wszystko co dotyczy liczenia i, że
>>>> tak powiem, formalnej
>>>> struktury beans'ów chciałbym mieć w jednej
>>>> klasie.
>>>
>>> Możesz to zrobić np tak
>>>
>>> //property X
>>> public double getX() {return x};
>>> public void setX(double x) {this.x = x;}
>>> //property Y
>>> public double getY() {return y};
>>> public void setY(double y) {this.y = y;}
>>> //property Z
>>> public double getZ() {return z};
>>> public void setZ(double z) {this.z = z;}
>>>
>>> //property V
>>> public double getV() {return x * y * z;}
>>>
>>>
>>> Jak widzisz, właściwość V nie ma settera, jest
>>> tyko do odczytu. A jednocześnie jej getter
>>> wykonuje potrzebne obliczenia.
>>>
>>> Zauważ że w ciałach setterów/getterów nie musisz
>>> wcale pisać/czytać ze zmiennych. Możesz na
>>> przykład przekazywać wartości do innych obiektów,
>>> lub bazy danych, albo wołać jakieś funkcje API
>>> odwołujące się do realnego świata (np. sterować
>>> robotem).
>>>
>> Dziękuję za odpowiedź.
>> Tyle, że dane do getV pochodzą z innej klasy, u
>> mnie z takiego kontenera
>> danych. Nie ma więc (potrzeby?) get/set
>> właściwości x,y,z w klasie
>> liczącej.
>>
>> Z tego by wynikało, że aby zachować konwencje
>> beans'a wystarczy mi
>> jedynie odczytywać wartość:
>>
>> private double v;
>> ...
>> public double getV() {
>>    return kontener.x * kontener.y * kontener.z;
>> }
>> Czy dobrze rozumiem?
>
> Dokładnie tak.
>
Ok, dzięki, działam.

On Thu, 03 Jan 2013 11:15:53 +0100, Arivald 
<arivald_@AT_interia_DOT_.pl> wrote:
> > Z tego by wynika?o, ?e aby zachowa? konwencje beans'a wystarczy mi
> > jedynie odczytywa? warto??:
> >
> > private double v;
> > ...
> > public double getV() {
> >    return kontener.x * kontener.y * kontener.z;
> > }
> > Czy dobrze rozumiem?
> Dok?adnie tak.

Naprawd? tak sie to robi? Zaczynam rozumie? czemu ludzie nienawidz? 
Java Beans.

RW

W dniu 2013-01-03 20:23, Roman W pisze:
> On Thu, 03 Jan 2013 11:15:53 +0100, Arivald
> <arivald_@AT_interia_DOT_.pl> wrote:
>> > Z tego by wynika?o, ?e aby zachowa? konwencje beans'a wystarczy mi
>> > jedynie odczytywa? warto??:
>> >
>> > private double v;
>> > ...
>> > public double getV() {
>> >    return kontener.x * kontener.y * kontener.z;
>> > }
>> > Czy dobrze rozumiem?
>> Dok?adnie tak.
>
> Naprawd? tak sie to robi? Zaczynam rozumie? czemu ludzie nienawidz? Java
> Beans.
>
> RW

Jak masz jakieś uwagi, to merytorycznie poproszę.

I używaj proszę jakiegoś kompatybilnego czytnika newsów, albo 
do-konfiguruj sobie ten Twój żeby prawidłowo kodował polskie literki... 
Przypominam że kodowanie na grupach do albo ISO-8859-2, albo UTF-8.

-- 
Arivald

W dniu 2013-01-03 09:40, Jadalbert pisze:
> problem (czy raczej moja niewiedza) jest taki
> Mam program liczący pewne wielkości i, dajmy na to w uproszczeniu, w
> klasie Geom metodę
> public double V(double x, double y, double z) {
>      return x * y * z;
> }
> gdzieś tam jest to wywoływane:
> V_ = Geom.V(2,3,4);
> czyli trzeba wstawić trzy argumenty. Wszystko działa bez zarzutu.
> Teraz, z klas liczących chcę zrobić beans'y.
> Czyli powinno być tak (opierając się na powyższym przykładzie):
> private double v;
> ...
> public double getV() {return v};
> public void setV(double v) {this.v = v;}
>
> i tu, zgodnie z konwencją, metoda set ma tylko jeden argument, a ja
> potrzebuję przekazać 3. Jak wybrnąć sensownie z takiej sytuacji? Osobna
> klasa licząca + osobna typu beans? W beans'ie dodatkowe metody liczące?
> Można oczywiście już w implementacji dołożyć odpowiednie zmienne, ale co
> wtedy przekazywać jako argument?
> Najchętniej wszystko co dotyczy liczenia i, że tak powiem, formalnej
> struktury beans'ów chciałbym mieć w jednej klasie.

Konwencja JavaBeans ma zastosowanie w przypadku klas, których obiekty 
mają jakieś "pola" lub "własności". W przypadku klasy Geom to nie zachodzi.

Czy jest jakiś konkretny powód, dla którego chcesz zastosować JavaBeans ?

Możesz oczywiście wykonać swoje obliczenie w ten sposób:

Geom g = new Geom();
g.setX(2);
g.setY(3);
g.setZ(4);
println(g.getV());

ale to jest po prostu bez sensu.

Pozdrawiam,
Marcin Jaskolski

W dniu 2013-01-03 11:15, Arivald pisze:
> W dniu 2013-01-03 11:03, Jadalbert pisze:
>> W dniu 2013-01-03 10:18, Arivald pisze:
>>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>>> problem (czy raczej moja niewiedza) jest taki
>>>> Mam program liczący pewne wielkości i, dajmy na
>>>> to w uproszczeniu, w
>>>> klasie Geom metodę
>>>> public double V(double x, double y, double z) {
>>>>      return x * y * z;
>>>> }
>>>> gdzieś tam jest to wywoływane:
>>>> V_ = Geom.V(2,3,4);
>>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>>> działa bez zarzutu.
>>>> Teraz, z klas liczących chcę zrobić beans'y.
>>>> Czyli powinno być tak (opierając się na
>>>> powyższym przykładzie):
>>>> private double v;
>>>> ...
>>>> public double getV() {return v};
>>>> public void setV(double v) {this.v = v;}
>>>
>>> To jest tylko para sette/getter. W zamyśle razem
>>> tworzą jedną właściwość obiektu.
>>>
>>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>>> jeden argument, a ja
>>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>>> takiej sytuacji? Osobna
>>>> klasa licząca + osobna typu beans? W beans'ie
>>>> dodatkowe metody liczące?
>>>> Można oczywiście już w implementacji dołożyć
>>>> odpowiednie zmienne, ale co
>>>> wtedy przekazywać jako argument?
>>>> Najchętniej wszystko co dotyczy liczenia i, że
>>>> tak powiem, formalnej
>>>> struktury beans'ów chciałbym mieć w jednej klasie.
>>>
>>> Możesz to zrobić np tak
>>>
>>> //property X
>>> public double getX() {return x};
>>> public void setX(double x) {this.x = x;}
>>> //property Y
>>> public double getY() {return y};
>>> public void setY(double y) {this.y = y;}
>>> //property Z
>>> public double getZ() {return z};
>>> public void setZ(double z) {this.z = z;}
>>>
>>> //property V
>>> public double getV() {return x * y * z;}
>>>
>>>
>>> Jak widzisz, właściwość V nie ma settera, jest
>>> tyko do odczytu. A jednocześnie jej getter
>>> wykonuje potrzebne obliczenia.
>>>
>>> Zauważ że w ciałach setterów/getterów nie musisz
>>> wcale pisać/czytać ze zmiennych. Możesz na
>>> przykład przekazywać wartości do innych obiektów,
>>> lub bazy danych, albo wołać jakieś funkcje API
>>> odwołujące się do realnego świata (np. sterować
>>> robotem).
>>>
>> Dziękuję za odpowiedź.
>> Tyle, że dane do getV pochodzą z innej klasy, u mnie z takiego kontenera
>> danych. Nie ma więc (potrzeby?) get/set właściwości x,y,z w klasie
>> liczącej.
>>
>> Z tego by wynikało, że aby zachować konwencje beans'a wystarczy mi
>> jedynie odczytywać wartość:
>>
>> private double v;
>> ...
>> public double getV() {
>>    return kontener.x * kontener.y * kontener.z;
>> }
>> Czy dobrze rozumiem?
>
> Dokładnie tak.
>

Oj to nie wygląda za dobrze. Przede wszystkim dlatego, że większość 
programistów zinterpretuje nazwę getV() jako "zwracam pole V". Tymczasem 
metoda nawet nie operuje na polach obiektu na rzecz którego jest 
wywoływana, tylko na obiekcie "kontener"...

Pozdrawiam,
Marcin Jaskolski

W dniu 2013-01-03 21:33, x pisze:
> W dniu 2013-01-03 09:40, Jadalbert pisze:
>> problem (czy raczej moja niewiedza) jest taki
>> Mam program liczący pewne wielkości i, dajmy na
>> to w uproszczeniu, w
>> klasie Geom metodę
>> public double V(double x, double y, double z) {
>>      return x * y * z;
>> }
>> gdzieś tam jest to wywoływane:
>> V_ = Geom.V(2,3,4);
>> czyli trzeba wstawić trzy argumenty. Wszystko
>> działa bez zarzutu.
>> Teraz, z klas liczących chcę zrobić beans'y.
>> Czyli powinno być tak (opierając się na
>> powyższym przykładzie):
>> private double v;
>> ...
>> public double getV() {return v};
>> public void setV(double v) {this.v = v;}
>>
>> i tu, zgodnie z konwencją, metoda set ma tylko
>> jeden argument, a ja
>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>> takiej sytuacji? Osobna
>> klasa licząca + osobna typu beans? W beans'ie
>> dodatkowe metody liczące?
>> Można oczywiście już w implementacji dołożyć
>> odpowiednie zmienne, ale co
>> wtedy przekazywać jako argument?
>> Najchętniej wszystko co dotyczy liczenia i, że
>> tak powiem, formalnej
>> struktury beans'ów chciałbym mieć w jednej klasie.
>
> Konwencja JavaBeans ma zastosowanie w przypadku
> klas, których obiekty mają jakieś "pola" lub
> "własności". W przypadku klasy Geom to nie zachodzi.
>
> Czy jest jakiś konkretny powód, dla którego chcesz
> zastosować JavaBeans ?
>
> Możesz oczywiście wykonać swoje obliczenie w ten
> sposób:
>
> Geom g = new Geom();
> g.setX(2);
> g.setY(3);
> g.setZ(4);
> println(g.getV());
>
> ale to jest po prostu bez sensu.
>
> Pozdrawiam,
> Marcin Jaskolski
W klasie Geom rzeczywiście nie ma to sensu ale to 
tylko prosty przykład. Inne klasy mają własności.
Nie mam dużego doświadczenia w javie, ale 
pamiętam, że kiedyś czytałem, że pisze się jakby 
dwie klasy. Jedna to typowy beans z polami np. V_, 
a druga to klasa licząca to V i nie będąca beansem.
i wtedy będzie 1.setV_(2.V);
tak w uproszczeniu rzecz jasna.
Ale jestem raz leniwy, a dwa nie wiem czy to aby 
na pewno jest sensowne i poprawne.

A powód tych beansów jest taki, że się 
przeliczyłem w tym by mieć prosty (tylko java) 
program do robienia obliczeń z danych wsadowych. 
Zagadnienie jednak wymaga jakiegoś interfejsu 
zjadliwego dla użytkownika stąd chcę to przerobić 
na jsf, jsp czy tak jakoś. Choćby prezentacja 
wyników - za dużo ich na konsolę czy plik 
tekstowy. Prócz tego te beansy będą mieć 
zastosowanie przy rozbudowie aplikacji.

W dniu 2013-01-03 21:47, x pisze:
> W dniu 2013-01-03 11:15, Arivald pisze:
>> W dniu 2013-01-03 11:03, Jadalbert pisze:
>>> W dniu 2013-01-03 10:18, Arivald pisze:
>>>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>>>> problem (czy raczej moja niewiedza) jest taki
>>>>> Mam program liczący pewne wielkości i, dajmy na
>>>>> to w uproszczeniu, w
>>>>> klasie Geom metodę
>>>>> public double V(double x, double y, double z) {
>>>>>      return x * y * z;
>>>>> }
>>>>> gdzieś tam jest to wywoływane:
>>>>> V_ = Geom.V(2,3,4);
>>>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>>>> działa bez zarzutu.
>>>>> Teraz, z klas liczących chcę zrobić beans'y.
>>>>> Czyli powinno być tak (opierając się na
>>>>> powyższym przykładzie):
>>>>> private double v;
>>>>> ...
>>>>> public double getV() {return v};
>>>>> public void setV(double v) {this.v = v;}
>>>>
>>>> To jest tylko para sette/getter. W zamyśle razem
>>>> tworzą jedną właściwość obiektu.
>>>>
>>>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>>>> jeden argument, a ja
>>>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>>>> takiej sytuacji? Osobna
>>>>> klasa licząca + osobna typu beans? W beans'ie
>>>>> dodatkowe metody liczące?
>>>>> Można oczywiście już w implementacji dołożyć
>>>>> odpowiednie zmienne, ale co
>>>>> wtedy przekazywać jako argument?
>>>>> Najchętniej wszystko co dotyczy liczenia i, że
>>>>> tak powiem, formalnej
>>>>> struktury beans'ów chciałbym mieć w jednej
>>>>> klasie.
>>>>
>>>> Możesz to zrobić np tak
>>>>
>>>> //property X
>>>> public double getX() {return x};
>>>> public void setX(double x) {this.x = x;}
>>>> //property Y
>>>> public double getY() {return y};
>>>> public void setY(double y) {this.y = y;}
>>>> //property Z
>>>> public double getZ() {return z};
>>>> public void setZ(double z) {this.z = z;}
>>>>
>>>> //property V
>>>> public double getV() {return x * y * z;}
>>>>
>>>>
>>>> Jak widzisz, właściwość V nie ma settera, jest
>>>> tyko do odczytu. A jednocześnie jej getter
>>>> wykonuje potrzebne obliczenia.
>>>>
>>>> Zauważ że w ciałach setterów/getterów nie musisz
>>>> wcale pisać/czytać ze zmiennych. Możesz na
>>>> przykład przekazywać wartości do innych obiektów,
>>>> lub bazy danych, albo wołać jakieś funkcje API
>>>> odwołujące się do realnego świata (np. sterować
>>>> robotem).
>>>>
>>> Dziękuję za odpowiedź.
>>> Tyle, że dane do getV pochodzą z innej klasy, u
>>> mnie z takiego kontenera
>>> danych. Nie ma więc (potrzeby?) get/set
>>> właściwości x,y,z w klasie
>>> liczącej.
>>>
>>> Z tego by wynikało, że aby zachować konwencje
>>> beans'a wystarczy mi
>>> jedynie odczytywać wartość:
>>>
>>> private double v;
>>> ...
>>> public double getV() {
>>>    return kontener.x * kontener.y * kontener.z;
>>> }
>>> Czy dobrze rozumiem?
>>
>> Dokładnie tak.
>>
>
> Oj to nie wygląda za dobrze. Przede wszystkim
> dlatego, że większość programistów zinterpretuje
> nazwę getV() jako "zwracam pole V". Tymczasem
> metoda nawet nie operuje na polach obiektu na
> rzecz którego jest wywoływana, tylko na obiekcie
> "kontener"...
>
> Pozdrawiam,
> Marcin Jaskolski
>
>
no właśnie też mi się wydaje, że do zmiany 
wartości pola służy set..., a get... do odczytu
i stąd moje całkiem na górze pytanie i wątpliwości
jednak w javie to se poczynam na razie mizernie

W dniu 2013-01-03 21:47, x pisze:
> W dniu 2013-01-03 11:15, Arivald pisze:
>> W dniu 2013-01-03 11:03, Jadalbert pisze:
>>> W dniu 2013-01-03 10:18, Arivald pisze:
>>>
>>> Z tego by wynikało, że aby zachować konwencje beans'a wystarczy mi
>>> jedynie odczytywać wartość:
>>>
>>> private double v;
>>> ...
>>> public double getV() {
>>>    return kontener.x * kontener.y * kontener.z;
>>> }
>>> Czy dobrze rozumiem?
>>
>> Dokładnie tak.
>>
>
> Oj to nie wygląda za dobrze. Przede wszystkim dlatego, że większość
> programistów zinterpretuje nazwę getV() jako "zwracam pole V". Tymczasem
> metoda nawet nie operuje na polach obiektu na rzecz którego jest
> wywoływana, tylko na obiekcie "kontener"...

Większość programistów? Może Javowców.
A interpretacja jest nie "zwracam pole V", tylko "zwracam wartość 
właściwości 'V' ". A że właściwość jest zależna od innych, to trzeba ją 
obliczyć. Gdyby chodziło tylko o dostęp do pola, to nie miało by sensu w 
ogóle robienie settera czy gettera.

W językach gdzie właściwości (property) są standardem (C#, VB, Delphi 
czy JavaScript), jest to normalne podejście żeby robić jakieś proste 
obliczenie w getterze. A czasem nawet skomplikowane działania typu lazy 
init, czy obsługa cache.

Tak samo jak w setterze sprawdza się czy nowa wartość jest inna niż 
dotychczasowa, i jeśli tak to podejmuje się stosowną akcję (no 
odrysowanie kontrolki po zmianie jej rozmiaru czy koloru).

A Java nie ma natywnego wsparcia dla właściwości, ma tyko konwencję 
"Java beans", która symuluje właściwości. Może dlatego tyle 
nieporozumień z tym związanych.

-- 
Arivald

W dniu 2013-01-03 21:54, Jadalbert pisze:
> W dniu 2013-01-03 21:33, x pisze:
>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>> problem (czy raczej moja niewiedza) jest taki
>>> Mam program liczący pewne wielkości i, dajmy na
>>> to w uproszczeniu, w
>>> klasie Geom metodę
>>> public double V(double x, double y, double z) {
>>>      return x * y * z;
>>> }
>>> gdzieś tam jest to wywoływane:
>>> V_ = Geom.V(2,3,4);
>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>> działa bez zarzutu.
>>> Teraz, z klas liczących chcę zrobić beans'y.
>>> Czyli powinno być tak (opierając się na
>>> powyższym przykładzie):
>>> private double v;
>>> ...
>>> public double getV() {return v};
>>> public void setV(double v) {this.v = v;}
>>>
>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>> jeden argument, a ja
>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>> takiej sytuacji? Osobna
>>> klasa licząca + osobna typu beans? W beans'ie
>>> dodatkowe metody liczące?
>>> Można oczywiście już w implementacji dołożyć
>>> odpowiednie zmienne, ale co
>>> wtedy przekazywać jako argument?
>>> Najchętniej wszystko co dotyczy liczenia i, że
>>> tak powiem, formalnej
>>> struktury beans'ów chciałbym mieć w jednej klasie.
>>
>> Konwencja JavaBeans ma zastosowanie w przypadku
>> klas, których obiekty mają jakieś "pola" lub
>> "własności". W przypadku klasy Geom to nie zachodzi.
>>
>> Czy jest jakiś konkretny powód, dla którego chcesz
>> zastosować JavaBeans ?
>>
>> Możesz oczywiście wykonać swoje obliczenie w ten
>> sposób:
>>
>> Geom g = new Geom();
>> g.setX(2);
>> g.setY(3);
>> g.setZ(4);
>> println(g.getV());
>>
>> ale to jest po prostu bez sensu.
>>
>> Pozdrawiam,
>> Marcin Jaskolski
> W klasie Geom rzeczywiście nie ma to sensu ale to tylko prosty przykład.
> Inne klasy mają własności.
> Nie mam dużego doświadczenia w javie, ale pamiętam, że kiedyś czytałem,
> że pisze się jakby dwie klasy. Jedna to typowy beans z polami np. V_, a

Czyli jedna klasa opisuje strukturę danych, a w drugiej siedzi logika 
obliczeń. Moim zdaniem to ma ręce i nogi, przede wszystkim dlatego że 
logika obliczeń lubi się mocno rozrastać. Co gorsza, często dotyczy 
więcej niż 1 obiektu, więc wpychanie jej do klasy "domenowej" nie musi 
być najlepszym pomysłem.

Oczywiście umieszczenie logiki w klasie domenowej jest bardziej "obiektowe".

Oczywiście klasa opisująca strukturę danych wcale nie musi być beanem.

> druga to klasa licząca to V i nie będąca beansem.
> i wtedy będzie 1.setV_(2.V);
Coś dziwnego - skąd obiekt 2 weźmie wartość v ?

Prędzej:

Obliczacz o = new Obliczacz();
MojeDane dane = new Dane(7, true, "ble");
o.obliczCoś(dane);


> tak w uproszczeniu rzecz jasna.
> Ale jestem raz leniwy, a dwa nie wiem czy to aby na pewno jest sensowne
> i poprawne.
>
> A powód tych beansów jest taki, że się przeliczyłem w tym by mieć prosty
> (tylko java) program do robienia obliczeń z danych wsadowych.
> Zagadnienie jednak wymaga jakiegoś interfejsu zjadliwego dla użytkownika
> stąd chcę to przerobić na jsf, jsp czy tak jakoś. Choćby prezentacja
> wyników - za dużo ich na konsolę czy plik tekstowy. Prócz tego te beansy
> będą mieć zastosowanie przy rozbudowie aplikacji.

Aha. Zdaje się że JSP lubią się z beanami.

Pozdrawiam,
Marcin Jaskolski

W dniu 2013-01-03 21:54, Jadalbert pisze:
> W dniu 2013-01-03 21:33, x pisze:
>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>> problem (czy raczej moja niewiedza) jest taki
>>> Mam program liczący pewne wielkości i, dajmy na
>>> to w uproszczeniu, w
>>> klasie Geom metodę
>>> public double V(double x, double y, double z) {
>>>      return x * y * z;
>>> }
>>> gdzieś tam jest to wywoływane:
>>> V_ = Geom.V(2,3,4);
>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>> działa bez zarzutu.
>>> Teraz, z klas liczących chcę zrobić beans'y.
>>> Czyli powinno być tak (opierając się na
>>> powyższym przykładzie):
>>> private double v;
>>> ...
>>> public double getV() {return v};
>>> public void setV(double v) {this.v = v;}
>>>
>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>> jeden argument, a ja
>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>> takiej sytuacji? Osobna
>>> klasa licząca + osobna typu beans? W beans'ie
>>> dodatkowe metody liczące?
>>> Można oczywiście już w implementacji dołożyć
>>> odpowiednie zmienne, ale co
>>> wtedy przekazywać jako argument?
>>> Najchętniej wszystko co dotyczy liczenia i, że
>>> tak powiem, formalnej
>>> struktury beans'ów chciałbym mieć w jednej klasie.
>>
>> Konwencja JavaBeans ma zastosowanie w przypadku
>> klas, których obiekty mają jakieś "pola" lub
>> "własności". W przypadku klasy Geom to nie zachodzi.
>>
>> Czy jest jakiś konkretny powód, dla którego chcesz
>> zastosować JavaBeans ?
>>
>> Możesz oczywiście wykonać swoje obliczenie w ten
>> sposób:
>>
>> Geom g = new Geom();
>> g.setX(2);
>> g.setY(3);
>> g.setZ(4);
>> println(g.getV());
>>

Zakładając że Geom ma liczyć coś dla jakichś obiektów (tu obiekt 
'figura'), można by to zrobić tak:

println(new Geom(figura).getV());


albo zrobić Geom klasą statyczną (a dokładniej jej funkcję getV):

println(Geom.getV(figura));


Ostatnia wersja wydaje się być najoptymalniejsza, bo nie tworzy obiektu 
tymczasowego.


>> ale to jest po prostu bez sensu.
>>
>> Pozdrawiam,
>> Marcin Jaskolski
> W klasie Geom rzeczywiście nie ma to sensu ale to tylko prosty przykład.
> Inne klasy mają własności.
> Nie mam dużego doświadczenia w javie, ale pamiętam, że kiedyś czytałem,
> że pisze się jakby dwie klasy. Jedna to typowy beans z polami np. V_, a
> druga to klasa licząca to V i nie będąca beansem.
> i wtedy będzie 1.setV_(2.V);
> tak w uproszczeniu rzecz jasna.
> Ale jestem raz leniwy, a dwa nie wiem czy to aby na pewno jest sensowne
> i poprawne.

To raczej miało tak wyglądać:

klasa 1 to POJO (http://pl.wikipedia.org/wiki/Plain_Old_Java_Object), 
ergo nie ma żadnego przetwarzania, tylko dane. Może być beanem (bez 
serializacji).

do tego druga klasa (lub kolekcja klas) realizująca jakieś przetwarzanie.

pełny przykład:

   public class First {
     private double x;
     private double y;
     private double z;

     public double getX() {
       return x;
     }
     public void setX(double x) {
       this.x = x;
     }
     public double getY() {
       return y;
     }
     public void setY(double y) {
       this.y = y;
     }
     public double getZ() {
       return z;
     }
     public void setZ(double z) {
       this.z = z;
     }
   }

   public class Second {
     private First first;

     public Second(First first) {
       this.first = first;
     }

     public double getV() {
       return first.getX() * first.getY() * first.getZ();
     }
   }


i użycie:

First f = something.getFirst(); //skądś tam się bierz
Second sec = new Second(f);
double v = sec.getV();

lub nawet

double v = new Second(something.getFirst()).getV();


W innej wersji, klasa Second jest statyczna (coś jak namespace z C++), 
dostarcza obliczeń bez konieczności tworzenia instancji.

public class Second {

   public static double getV(First first) {
     return first.getX() * first.getY() * first.getZ();
   }
}


Wtedy używa się jej tak:

double v = Second.getV(something.getFirst());


Wszystko zależy od potrzeb.

-- 
Arivald

W dniu 2013-01-03 22:15, Arivald pisze:
> W dniu 2013-01-03 21:47, x pisze:
>> W dniu 2013-01-03 11:15, Arivald pisze:
>>> W dniu 2013-01-03 11:03, Jadalbert pisze:
>>>> W dniu 2013-01-03 10:18, Arivald pisze:
>>>>
>>>> Z tego by wynikało, że aby zachować konwencje beans'a wystarczy mi
>>>> jedynie odczytywać wartość:
>>>>
>>>> private double v;
>>>> ...
>>>> public double getV() {
>>>>    return kontener.x * kontener.y * kontener.z;
>>>> }
>>>> Czy dobrze rozumiem?
>>>
>>> Dokładnie tak.
>>>
>>
>> Oj to nie wygląda za dobrze. Przede wszystkim dlatego, że większość
>> programistów zinterpretuje nazwę getV() jako "zwracam pole V". Tymczasem
>> metoda nawet nie operuje na polach obiektu na rzecz którego jest
>> wywoływana, tylko na obiekcie "kontener"...
>
> Większość programistów? Może Javowców.
> A interpretacja jest nie "zwracam pole V", tylko "zwracam wartość
> właściwości 'V' ". A że właściwość jest zależna od innych, to trzeba ją
> obliczyć. Gdyby chodziło tylko o dostęp do pola, to nie miało by sensu w
> ogóle robienie settera czy gettera.

Tylko niech ta właściwość dotyczy obiektu na rzecz którego jest 
wywoływana, a nie jakiegoś innego.

> W językach gdzie właściwości (property) są standardem (C#, VB, Delphi
> czy JavaScript), jest to normalne podejście żeby robić jakieś proste
> obliczenie w getterze. A czasem nawet skomplikowane działania typu lazy
> init, czy obsługa cache.

W Javie również jest to bardzo powszechna praktyka. Ale trzeba z tym 
podejściem uważać, łatwo narobić bałaganu.

Pozdrawiam,
Marcin Jaskolski

W dniu 2013-01-03 22:53, x pisze:
> W dniu 2013-01-03 22:15, Arivald pisze:
>> W dniu 2013-01-03 21:47, x pisze:
>>> W dniu 2013-01-03 11:15, Arivald pisze:
>>>> W dniu 2013-01-03 11:03, Jadalbert pisze:
>>>>> W dniu 2013-01-03 10:18, Arivald pisze:
>>>>>
>>>>> Z tego by wynikało, że aby zachować konwencje beans'a wystarczy mi
>>>>> jedynie odczytywać wartość:
>>>>>
>>>>> private double v;
>>>>> ...
>>>>> public double getV() {
>>>>>    return kontener.x * kontener.y * kontener.z;
>>>>> }
>>>>> Czy dobrze rozumiem?
>>>>
>>>> Dokładnie tak.
>>>>
>>>
>>> Oj to nie wygląda za dobrze. Przede wszystkim dlatego, że większość
>>> programistów zinterpretuje nazwę getV() jako "zwracam pole V". Tymczasem
>>> metoda nawet nie operuje na polach obiektu na rzecz którego jest
>>> wywoływana, tylko na obiekcie "kontener"...
>>
>> Większość programistów? Może Javowców.
>> A interpretacja jest nie "zwracam pole V", tylko "zwracam wartość
>> właściwości 'V' ". A że właściwość jest zależna od innych, to trzeba ją
>> obliczyć. Gdyby chodziło tylko o dostęp do pola, to nie miało by sensu w
>> ogóle robienie settera czy gettera.
>
> Tylko niech ta właściwość dotyczy obiektu na rzecz którego jest
> wywoływana, a nie jakiegoś innego.
>

Ale czemu? To nie ma uzasadnienia.

Dla przykładu, mamy klasę Samochod:

class Samochod {
   Siedzenie kierowca;
   Siedzenie pasazerZPrzodu;
   Siedzenie kanapaTylna;

   int getIloscOsob() {
     return kierowca.getIloscOsob()
          + pasazerZPrzodu.getIloscOsob()
          + kanapaTylna.getIloscOsob();
   }

}

>> W językach gdzie właściwości (property) są standardem (C#, VB, Delphi
>> czy JavaScript), jest to normalne podejście żeby robić jakieś proste
>> obliczenie w getterze. A czasem nawet skomplikowane działania typu lazy
>> init, czy obsługa cache.
>
> W Javie również jest to bardzo powszechna praktyka. Ale trzeba z tym
> podejściem uważać, łatwo narobić bałaganu.

Oczywiście, z tym się w pełni zgadzam.

-- 
Arivald

W dniu 2013-01-03 22:51, Arivald pisze:
> W dniu 2013-01-03 21:54, Jadalbert pisze:
>> W dniu 2013-01-03 21:33, x pisze:
>>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>>> problem (czy raczej moja niewiedza) jest taki
>>>> Mam program liczący pewne wielkości i, dajmy na
>>>> to w uproszczeniu, w
>>>> klasie Geom metodę
>>>> public double V(double x, double y, double z) {
>>>>      return x * y * z;
>>>> }
>>>> gdzieś tam jest to wywoływane:
>>>> V_ = Geom.V(2,3,4);
>>>> czyli trzeba wstawić trzy argumenty. Wszystko
>>>> działa bez zarzutu.
>>>> Teraz, z klas liczących chcę zrobić beans'y.
>>>> Czyli powinno być tak (opierając się na
>>>> powyższym przykładzie):
>>>> private double v;
>>>> ...
>>>> public double getV() {return v};
>>>> public void setV(double v) {this.v = v;}
>>>>
>>>> i tu, zgodnie z konwencją, metoda set ma tylko
>>>> jeden argument, a ja
>>>> potrzebuję przekazać 3. Jak wybrnąć sensownie z
>>>> takiej sytuacji? Osobna
>>>> klasa licząca + osobna typu beans? W beans'ie
>>>> dodatkowe metody liczące?
>>>> Można oczywiście już w implementacji dołożyć
>>>> odpowiednie zmienne, ale co
>>>> wtedy przekazywać jako argument?
>>>> Najchętniej wszystko co dotyczy liczenia i, że
>>>> tak powiem, formalnej
>>>> struktury beans'ów chciałbym mieć w jednej klasie.
>>>
>>> Konwencja JavaBeans ma zastosowanie w przypadku
>>> klas, których obiekty mają jakieś "pola" lub
>>> "własności". W przypadku klasy Geom to nie zachodzi.
>>>
>>> Czy jest jakiś konkretny powód, dla którego chcesz
>>> zastosować JavaBeans ?
>>>
>>> Możesz oczywiście wykonać swoje obliczenie w ten
>>> sposób:
>>>
>>> Geom g = new Geom();
>>> g.setX(2);
>>> g.setY(3);
>>> g.setZ(4);
>>> println(g.getV());
>>>
>
> Zakładając że Geom ma liczyć coś dla jakichś obiektów (tu obiekt
> 'figura'), można by to zrobić tak:
>
> println(new Geom(figura).getV());
>
>
> albo zrobić Geom klasą statyczną (a dokładniej jej funkcję getV):
>
> println(Geom.getV(figura));
>
>
> Ostatnia wersja wydaje się być najoptymalniejsza, bo nie tworzy obiektu
> tymczasowego.
>
>
>>> ale to jest po prostu bez sensu.
>>>
>>> Pozdrawiam,
>>> Marcin Jaskolski
>> W klasie Geom rzeczywiście nie ma to sensu ale to tylko prosty przykład.
>> Inne klasy mają własności.
>> Nie mam dużego doświadczenia w javie, ale pamiętam, że kiedyś czytałem,
>> że pisze się jakby dwie klasy. Jedna to typowy beans z polami np. V_, a
>> druga to klasa licząca to V i nie będąca beansem.
>> i wtedy będzie 1.setV_(2.V);
>> tak w uproszczeniu rzecz jasna.
>> Ale jestem raz leniwy, a dwa nie wiem czy to aby na pewno jest sensowne
>> i poprawne.
>
> To raczej miało tak wyglądać:
>
> klasa 1 to POJO (http://pl.wikipedia.org/wiki/Plain_Old_Java_Object),
> ergo nie ma żadnego przetwarzania, tylko dane. Może być beanem (bez
> serializacji).
>
> do tego druga klasa (lub kolekcja klas) realizująca jakieś przetwarzanie.
>
> pełny przykład:
>
>    public class First {
>      private double x;
>      private double y;
>      private double z;
>
>      public double getX() {
>        return x;
>      }
>      public void setX(double x) {
>        this.x = x;
>      }
>      public double getY() {
>        return y;
>      }
>      public void setY(double y) {
>        this.y = y;
>      }
>      public double getZ() {
>        return z;
>      }
>      public void setZ(double z) {
>        this.z = z;
>      }
>    }

To ma ręce i nogi, oczywiście przy założeniu że koniecznie chcemy 
JavaBeana...

>
>    public class Second {
>      private First first;
>
>      public Second(First first) {
>        this.first = first;
>      }
>
>    public double getV() {
>      return first.getX() * first.getY() * first.getZ();
>    }

To jest bez sensu. Pojedynczą operację obliczenia V rozbiłeś na dwie: 
utworzenia nowego obiektu klasy Second (po co ???) i właściwego 
obliczenia. No i znowu wygląda na to, że V jest właściwością obiektu 
klasy Second, a nie jest.

Po prostu w ten sposób:

public double computeV(First first) {
   return first.getX() * first.getY() * first.getZ();
}

> i użycie:
>
> First f = something.getFirst(); //skądś tam się bierz
> Second sec = new Second(f);
> double v = sec.getV();
>
> lub nawet
>
> double v = new Second(something.getFirst()).getV();
>
> W innej wersji, klasa Second jest statyczna (coś jak namespace z C++),
> dostarcza obliczeń bez konieczności tworzenia instancji.

To jest akceptowalne w przypadku naprawdę prostych funkcjonalności (tak 
jak Apachowe StringUtils. W ogólnym przypadku trochę śliskie, bo nie da 
się zamienić implementacji (np na mocka).

>
> public class Second {
>
>    public static double getV(First first) {
>      return first.getX() * first.getY() * first.getZ();
>    }
> }
>
>
> Wtedy używa się jej tak:
>
> double v = Second.getV(something.getFirst());
>
> Wszystko zależy od potrzeb.

Należy róznież pamiętać o tym, że w Javie nie ma reguły mówiącej że 
wszystkie nazwy metod muszą się zaczynać od set lub get ;-)

Pozdrawiam,
Marcin Jaskolski

W dniu 2013-01-03 23:06, Arivald pisze:
> W dniu 2013-01-03 22:53, x pisze:
>> W dniu 2013-01-03 22:15, Arivald pisze:
>>> W dniu 2013-01-03 21:47, x pisze:
>>>> W dniu 2013-01-03 11:15, Arivald pisze:
>>>>> W dniu 2013-01-03 11:03, Jadalbert pisze:
>>>>>> W dniu 2013-01-03 10:18, Arivald pisze:
>>>>>>
>>>>>> Z tego by wynikało, że aby zachować konwencje beans'a wystarczy mi
>>>>>> jedynie odczytywać wartość:
>>>>>>
>>>>>> private double v;
>>>>>> ...
>>>>>> public double getV() {
>>>>>>    return kontener.x * kontener.y * kontener.z;
>>>>>> }
>>>>>> Czy dobrze rozumiem?
>>>>>
>>>>> Dokładnie tak.
>>>>>
>>>>
>>>> Oj to nie wygląda za dobrze. Przede wszystkim dlatego, że większość
>>>> programistów zinterpretuje nazwę getV() jako "zwracam pole V".
>>>> Tymczasem
>>>> metoda nawet nie operuje na polach obiektu na rzecz którego jest
>>>> wywoływana, tylko na obiekcie "kontener"...
>>>
>>> Większość programistów? Może Javowców.
>>> A interpretacja jest nie "zwracam pole V", tylko "zwracam wartość
>>> właściwości 'V' ". A że właściwość jest zależna od innych, to trzeba ją
>>> obliczyć. Gdyby chodziło tylko o dostęp do pola, to nie miało by sensu w
>>> ogóle robienie settera czy gettera.
>>
>> Tylko niech ta właściwość dotyczy obiektu na rzecz którego jest
>> wywoływana, a nie jakiegoś innego.
>>
>
> Ale czemu? To nie ma uzasadnienia.
>
> Dla przykładu, mamy klasę Samochod:
>
> class Samochod {
>    Siedzenie kierowca;
>    Siedzenie pasazerZPrzodu;
>    Siedzenie kanapaTylna;
>
>    int getIloscOsob() {
>      return kierowca.getIloscOsob()
>           + pasazerZPrzodu.getIloscOsob()
>           + kanapaTylna.getIloscOsob();
>    }
> }

OK, racja, w tym przypadku mamy części składowe samochodu.

Pozdrawiam,
Marcin Jaskolski

W dniu 2013-01-03 23:20, x pisze:
> W dniu 2013-01-03 22:51, Arivald pisze:
>> W dniu 2013-01-03 21:54, Jadalbert pisze:
>>> W dniu 2013-01-03 21:33, x pisze:
>>>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>> W klasie Geom rzeczywiście nie ma to sensu ale to tylko prosty przykład.
>>> Inne klasy mają własności.
>>> Nie mam dużego doświadczenia w javie, ale pamiętam, że kiedyś czytałem,
>>> że pisze się jakby dwie klasy. Jedna to typowy beans z polami np. V_, a
>>> druga to klasa licząca to V i nie będąca beansem.
>>> i wtedy będzie 1.setV_(2.V);
>>> tak w uproszczeniu rzecz jasna.
>>> Ale jestem raz leniwy, a dwa nie wiem czy to aby na pewno jest sensowne
>>> i poprawne.
>>
>> To raczej miało tak wyglądać:
>>
>> klasa 1 to POJO (http://pl.wikipedia.org/wiki/Plain_Old_Java_Object),
>> ergo nie ma żadnego przetwarzania, tylko dane. Może być beanem (bez
>> serializacji).
>>
>> do tego druga klasa (lub kolekcja klas) realizująca jakieś przetwarzanie.
>>
>> pełny przykład:
>>
>>    public class First {
>>      private double x;
>>      private double y;
>>      private double z;
>>
>>      public double getX() {
>>        return x;
>>      }
>>      public void setX(double x) {
>>        this.x = x;
>>      }
>>      public double getY() {
>>        return y;
>>      }
>>      public void setY(double y) {
>>        this.y = y;
>>      }
>>      public double getZ() {
>>        return z;
>>      }
>>      public void setZ(double z) {
>>        this.z = z;
>>      }
>>    }
>
> To ma ręce i nogi, oczywiście przy założeniu że koniecznie chcemy
> JavaBeana...
>

Oczywiście wystarczyły by publiczne pola, ale OP pytał o beany.

>>
>>    public class Second {
>>      private First first;
>>
>>      public Second(First first) {
>>        this.first = first;
>>      }
>>
>>    public double getV() {
>>      return first.getX() * first.getY() * first.getZ();
>>    }
>
> To jest bez sensu. Pojedynczą operację obliczenia V rozbiłeś na dwie:
> utworzenia nowego obiektu klasy Second (po co ???) i właściwego
> obliczenia. No i znowu wygląda na to, że V jest właściwością obiektu
> klasy Second, a nie jest.

Założenie jest takie że klasa Second realizuje wiele różnych obliczeń. W 
przykładzie jest tylko jedno.

Osobiście lubię ten model że konkretną instancję klasy danych na stałe 
wiąże się z instancją klasy obliczeniowej.

Choć nie zawsze jest to najsensowniejsze.

>
> Po prostu w ten sposób:
>
> public double computeV(First first) {
>    return first.getX() * first.getY() * first.getZ();
> }
>

Też można.
Do OP: Oczywiście w tym wypadku zakładamy że konstruktor Second jest 
domyślny, bezargumentowy, a jedna instancja klasy Second może być 
używana do obsługi wielu obiektów First. Implikuje to także bezstanowość 
klasy Second (tzn nie ma ona żadnych pól),


>> i użycie:
>>
>> First f = something.getFirst(); //skądś tam się bierz
>> Second sec = new Second(f);
>> double v = sec.getV();
>>
>> lub nawet
>>
>> double v = new Second(something.getFirst()).getV();
>>
>> W innej wersji, klasa Second jest statyczna (coś jak namespace z C++),
>> dostarcza obliczeń bez konieczności tworzenia instancji.
>
> To jest akceptowalne w przypadku naprawdę prostych funkcjonalności (tak
> jak Apachowe StringUtils. W ogólnym przypadku trochę śliskie, bo nie da
> się zamienić implementacji (np na mocka).
>

No cóż, to prawda. Coś za coś ;-)

>>
>> public class Second {
>>
>>    public static double getV(First first) {
>>      return first.getX() * first.getY() * first.getZ();
>>    }
>> }
>>
>>
>> Wtedy używa się jej tak:
>>
>> double v = Second.getV(something.getFirst());
>>
>> Wszystko zależy od potrzeb.
>
> Należy róznież pamiętać o tym, że w Javie nie ma reguły mówiącej że
> wszystkie nazwy metod muszą się zaczynać od set lub get ;-)

A to już moje przyzwyczajenie kolidujące z konwencją beanów. Na co dzień 
programuję w języku z właściwościami, i funkcje typu GetXX czy IsXX 
używam to nie są gettery ;-)

-- 
Arivald

Jadalbert pisze:

> A powód tych beansów jest taki, że się przeliczyłem w tym by mieć prosty
> (tylko java) program do robienia obliczeń z danych wsadowych.
> Zagadnienie jednak wymaga jakiegoś interfejsu zjadliwego dla użytkownika
> stąd chcę to przerobić na jsf, jsp czy tak jakoś. Choćby prezentacja
> wyników - za dużo ich na konsolę czy plik tekstowy. Prócz tego te beansy
> będą mieć zastosowanie przy rozbudowie aplikacji.

Zupełnie niepotrzebnie narzucasz ograniczenia związane z warstwą widoku 
na logikę aplikacji. JavaBeans sprawuje się dobrze w takich 
zagadnieniach jak serializacja, spring framework. To taka klasa typu 
entity. Jeśli w którymś fragmencie projektu pojawi się takie wymaganie 
(czyli najczęściej na brzegu systemu - klasy boundary), to tam dopiero 
przeprowadź konwersję obiektu biznesowego na taki który spełnia 
wymagania systemu zewnętrznego (pliku, soap,.., jsp). W ten sposób jeśli 
zmienisz system zewnętrzny, będziesz musiał wprowadzić zmiany tylko w 
jednym miejscu systemu.

W przypadku stron JSP skorzystaj z jakiegoś frameworka MVC. Ja korzystam 
ze struts. Wtedy javaBean'em jest klasa formularza. Wewnątrz akcji 
struts (metoda execute() ) odczytasz właściwości obiektu biznesowego i 
ustawisz property formularza.



-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

W dniu 2013-01-03 23:40, Arivald pisze:
> W dniu 2013-01-03 23:20, x pisze:
>> W dniu 2013-01-03 22:51, Arivald pisze:
>>> W dniu 2013-01-03 21:54, Jadalbert pisze:
>>>> W dniu 2013-01-03 21:33, x pisze:
>>>>> W dniu 2013-01-03 09:40, Jadalbert pisze:
>>>> W klasie Geom rzeczywiście nie ma to sensu ale to tylko prosty
>>>> przykład.
>>>> Inne klasy mają własności.
>>>> Nie mam dużego doświadczenia w javie, ale pamiętam, że kiedyś czytałem,
>>>> że pisze się jakby dwie klasy. Jedna to typowy beans z polami np. V_, a
>>>> druga to klasa licząca to V i nie będąca beansem.
>>>> i wtedy będzie 1.setV_(2.V);
>>>> tak w uproszczeniu rzecz jasna.
>>>> Ale jestem raz leniwy, a dwa nie wiem czy to aby na pewno jest sensowne
>>>> i poprawne.
>>>
>>> To raczej miało tak wyglądać:
>>>
>>> klasa 1 to POJO (http://pl.wikipedia.org/wiki/Plain_Old_Java_Object),
>>> ergo nie ma żadnego przetwarzania, tylko dane. Może być beanem (bez
>>> serializacji).
>>>
>>> do tego druga klasa (lub kolekcja klas) realizująca jakieś
>>> przetwarzanie.
>>>
>>> pełny przykład:
>>>
>>>    public class First {
>>>      private double x;
>>>      private double y;
>>>      private double z;
>>>
>>>      public double getX() {
>>>        return x;
>>>      }
>>>      public void setX(double x) {
>>>        this.x = x;
>>>      }
>>>      public double getY() {
>>>        return y;
>>>      }
>>>      public void setY(double y) {
>>>        this.y = y;
>>>      }
>>>      public double getZ() {
>>>        return z;
>>>      }
>>>      public void setZ(double z) {
>>>        this.z = z;
>>>      }
>>>    }
>>
>> To ma ręce i nogi, oczywiście przy założeniu że koniecznie chcemy
>> JavaBeana...
>>
>
> Oczywiście wystarczyły by publiczne pola, ale OP pytał o beany.
>
>>>
>>>    public class Second {
>>>      private First first;
>>>
>>>      public Second(First first) {
>>>        this.first = first;
>>>      }
>>>
>>>    public double getV() {
>>>      return first.getX() * first.getY() * first.getZ();
>>>    }
>>
>> To jest bez sensu. Pojedynczą operację obliczenia V rozbiłeś na dwie:
>> utworzenia nowego obiektu klasy Second (po co ???) i właściwego
>> obliczenia. No i znowu wygląda na to, że V jest właściwością obiektu
>> klasy Second, a nie jest.
>
> Założenie jest takie że klasa Second realizuje wiele różnych obliczeń. W
> przykładzie jest tylko jedno.
>
> Osobiście lubię ten model że konkretną instancję klasy danych na stałe
> wiąże się z instancją klasy obliczeniowej.

W sumie to jakiś czas temu użyłem tego podejścia w Scali i było OK ;-)

Pozdrawiam,
Marcin Jaskolski

On Thu, 03 Jan 2013 21:15:41 +0100, Arivald 
<NOSPAMarivald@interia.pl> wrote:
> >> >
> >> > private double v;
> >> > ...
> >> > public double getV() {
> >> >    return kontener.x * kontener.y * kontener.z;
> >> > }
> >> > Czy dobrze rozumiem?
> >> Dok?adnie tak.
> >
> > Naprawd? tak sie to robi? Zaczynam rozumie? czemu ludzie 
nienawidz? Java
> > Beans.
> Jak masz jakieś uwagi, to merytorycznie poproszę.

Po co deklaracja zmiennej v jezeli getV jej nie odczytuje tylko robi 
obliczenie?

RW

> Dla przykładu, mamy klasę Samochod:
>

Przez analogię z realnym światem. Nigdy nie słyszałam o tym, by samochód mówił ilu ma pasażerów. To ktoś z zewnątrz np. obserwator 
spogląda na każdy z foteli i liczy.