W dniu 2011-04-06 12:44, Jacek Czerwinski pisze:
> W dniu 2011-04-06 00:43, Mariusz Marszałkowski pisze:
>> On 5 Kwi, 19:55, Jacek Czerwinski<x...@...z.pl> wrote:
>>> W dniu 2011-04-05 17:14, A.L. pisze:> On Mon, 4 Apr 2011 22:08:45
>>> -0700 (PDT), Mariusz Marsza kowski
[...]
>> To na poziomie bardziej zaawansowanym jak powinno się podawac?
>> Pozdrawiam
>
> Od czasu pojawienia sie wzorców (szeroko ujmujac, pewien etap rozwoju
> m.in. postulat drugiej fali OOP zawieranie zamiast dziedziczenia w
> przeciwstawieniu do potwornie glebokich hierarchii 1-go etapu itd)
> obiekt = funkcjonalnosc (juz nie rzecz).
>
> Czyli
> samochod osobowy extends samochod
> i zawiera
> funkcjonalnosc ABS
> funkcjonalnosc Klima
> funkcjonalnosc naped 2x lub
> funkcjonalnosc naped 4x
>
> Przyklad jest lekko naciagany, ciagle widac w nim 'rzeczy' a nie czyste
> 'funkcjonalnosci', ale chcialem obrazem szkolnym sie posluzyc. O! dodajmy:
> funkcjonalnosc ruch prawostronny
> funkcjonalnosc ruch lewostronny
[...]
> W kazdym razie w "drugiej fali" programowania obiektowego
> a) hierarchie maja mniejsza glebokosc
> b) klas jest wiecej
> c) nie kazda klasa jest tak konkretna jak 'jablko' czy 'owoc'.
> itd.

Prostym przykładem jest wzorzec Dekoratora - obiekt klasy nie
reprezentuje "rzeczy" (np. pliku), ale sposób zmiany/dodania
zachowania "dekorowanego" obiektu (np. cache dla obiektu
implementującego interfejs pliku). Dzięki nie dziedziczymy
FileWithCache z File, ale "opakowujemy" obiekt z interfejsem IFile
w obiekt implementujący IFile i dodający funkcjonalność.

Inne to Strategia lub Stan - klasa nie odwzorowuje obiektu, ale
zachowania w pewnych przypadkach.

Nieco obok, ale też podobne - refaktoryzacja "Replace Method with
Method Object". Tworzymy klasę, której obiekty reprezentują stan
lokalnych zmiennych metody.

--
Paweł Kierski
n...@p...net