🚀 go-pugleaf

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