🚀 go-pugleaf

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