W dniu 2011-04-05 17:14, A.L. pisze:
> On Mon, 4 Apr 2011 22:08:45 -0700 (PDT), Mariusz Marszałkowski
> <m...@g...com> wrote:
>>
> Obiekty w kodzie
>> odwzorowuja jeden do jeden obiekty rzeczywiste.
>>
> Naprawde?...
>
Na poziomie szkolnym mozna tak podawac ;)
jablko, gruszka, owoc itd.

W sam raz na poziomie pierwotnego pyania.

do góry

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
> > <m...@g...com>  wrote:
>
> > Obiekty w kodzie
> >> odwzorowuja jeden do jeden obiekty rzeczywiste.
>
> > Naprawde?...
>
> Na poziomie szkolnym mozna tak podawac ;)
> jablko, gruszka, owoc itd.
>
> W sam raz na poziomie pierwotnego pyania.
To na poziomie bardziej zaawansowanym jak powinno się podawac?
Pozdrawiam

do góry

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
>>> <m...@g...com> wrote:
>>
>>> Obiekty w kodzie
>>>> odwzorowuja jeden do jeden obiekty rzeczywiste.
>>
>>> Naprawde?...
>>
>> Na poziomie szkolnym mozna tak podawac ;)
>> jablko, gruszka, owoc itd.
>>
>> W sam raz na poziomie pierwotnego pyania.
> 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


Np mi tzw "praktykowi" potrzebne bylo nie tyle szczegolowe poznanie 21
(liczba dowolna) oficjalnych wzorców GoF, ile przestawienie czy
zwerbalizowanie zmian w patrzeniu. Pomogla mi ksiazka (juz niedostepna)
http://helion.pl/ksiazki/projektowanie-zorientowane-
obiektowo-wzorce-projektowe-wydanie-ii-alan-shallowa
y-james-r-trott,probw2.htm

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.

do góry

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

do góry

jaki jest MINIMALNY (ale dopuszczalny)
sposob uzywania tych wszystkich obiektow

czy sposob polegajacy na tym ze w kazdym
obiekcie ustawia sie twarde wskazmiki na potrzebne
mu inne obiekty ujdzie ?



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On Wed, 06 Apr 2011 12:44:50 +0200, Jacek Czerwinski <...@...z.pl> wrote:

>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).

Wzorce nie maja nic, ale to zupelnie nic wspolnego z obiektowoscia.

A.L.

do góry

W dniu 2011-04-06 14:45, A.L. pisze:
> On Wed, 06 Apr 2011 12:44:50 +0200, Jacek Czerwinski<...@...z.pl> wrote:
>
>> 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).
>
> Wzorce nie maja nic, ale to zupelnie nic wspolnego z obiektowoscia.
>

A wiesz, nie bede polemizowal.

ja to wzorce widze, za w/w autorem, raczej jako 'pokorna' analize i
werbalizacje, jak to 'my' tradycyjnie robimy typowe rzeczy, niz
oglaszanie z ambony 'od teraz bedzie tak'.

W tym sensie wzorce wczuwaja sie w pewne tradycje, sposoby, intuicje,
starsze niz programowanie obiektowe. Nigdy nie bylem religijnym
zwolennikiem, ze wzorców jest dokladnie 22 (czy inna liczba), prawie
wszystkie (moze bez 2-3) wyrosly na NASIONACH (wybacz wiosenne
skojarzenie) starszych niz OOP. Dostaly nazwy, slowa, porzadek, ale same
idee byly bardzo stare.

W tym sensie sie zgadzam.

W praktyce A.D. 2011 sa one wyartykulowane i podawane w dominujacym dzis
paradygmacie, na sposob obiektowy.

Ale nie wiem, co A.L. konkretnie miales na mysli.

do góry

W dniu 2011-04-06 14:14, p...@p...onet.pl pisze:
> jaki jest MINIMALNY (ale dopuszczalny)
> sposob uzywania tych wszystkich obiektow

Minimalny to spojrzenie choc troche abstrakcyjne, na implementacje
przyjdzie czas.

do góry

A. L. wrote:

> On Wed, 06 Apr 2011 12:44:50 +0200, Jacek Czerwinski <...@...z.pl> wrote:
>
>>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).
>
> Wzorce nie maja nic, ale to zupelnie nic wspolnego z obiektowoscia.

Chodzi ci o wzorce w ogolnosci?
Bo jesli chodzi konkretnie o wzrorce tzw. GoF to chyba jednak maja:
http://en.wikipedia.org/wiki/Design_Patterns_(book)

--
Michal

do góry

On 6 Kwi, 12:44, Jacek Czerwinski <x...@...z.pl> wrote:
> Np mi tzw "praktykowi" potrzebne bylo nie tyle szczegolowe poznanie 21
> (liczba dowolna) oficjalnych wzorców GoF, ile przestawienie czy
> zwerbalizowanie zmian w patrzeniu. Pomogla mi ksiazka (juz
niedostepna)http://helion.pl/ksiazki/projektowanie-z
orientowane-obiektowo-wzorce-...
>
> 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.

Niczemu z powyzszych nie zaprzeczam. W programie mam obiekt
brama i samochod, takie bardzo "twarde" obiekty. Ale przejazd
samochodu
przez brame byl tak skomplikowany ze mam hierarchie roznych
przejazdow. Okreslony obiekt przejazdu powstaje, samochod
przejezdza, twarde obiekty sa modyfikowane przez obiekt
przejazdu i w koncu obiekt przejazdu ginie. Ale fakt, zgrabniej
jest nazywac przejazd "dzialaniem" niz "obiektem rzeczywistym".

Pozdrawiam

do góry