On 30 Cze, 15:13, j...@p...onet.pl wrote:
> Mam pytanie dot. programowania obiektowego:
> Czy zasady wydzielania metody przypominaj zasady wydzielania podprogramu?
> Zauwa y em, e w aplikacjach obiektowych d y si do wi kszej ilo ci drobnych
> metod (i klas) a nie mniejszej ilo ci bardziej z o onych.
>
> --
> Wys ano z serwisu OnetNiusy:http://niusy.onet.pl

Przykładem bardzo małej metody jest np.:

class Pies {
int dlugosc_zycia;
Rasa rasa;

Pies( Rasa rasa, int dlugosc_zycia ) {
this->dlugosc_zycia = dlugosc_zycia;
this->rasa = rasa;
}

int get_dlugosc() {
return dlugosc_zycia;
}

};

Nic nie stoi na przeszkodzie aby tak małych metod nie stosowac, a
bezposrednio
odwolywac sie do pola dlugosc zycia, tym bardziej do odczytu. Jednak w
przyszlosci
moze zapragniesz do klasy pies dodac np. klimat w jakim zyje i moze
sie
okazac ze niektore rasy zyjace w tropiku dozywaja o 10% krocej niz w
klimacie
umiarkowanym. Majac metode, zmodyfikujesz caly program natychmiast:

return dluosc_zycia * ( klimat == "torpik" && rasa.zimnolubna() ?
0.9 : 1.0 );

Odwolujac sie do pola, takiej mozliwosci nie zostawiasz sobie na
pozniej.

Poza tym do metody get_dlugosc mozesz dodc nowy parametr i rozszerzyc
funkcjonalnosc w dowolny sposob, a kompilator ladnie wykryje wszystkie
miejsca gdzie uzyles wczesniej tej metody bez uzycia parametrow.

Z punktu widzenia dobrego projektu, a programowanie obiektowe jest po
to
aby projekty byly dobre, zawsze lepiej jest rozbic kod na duza ilosc
malych
metod i malych klas.

Pozdrawiam