🚀 go-pugleaf

On 5 Dec 2005 00:09:06 +0100, "Hattori Hanzo"
<hattoriWYTNIJTO@poczta.onet.pl> wrote:

>Witam
>
>Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
>
>Jaka jest idea programowania obiektowego?
>czym sie ona rozni od strukturalnego?
>Czy jest jakas rzecz, ktorej nie da sie zrobic w strukturalnym
>programowaniu a tylko w obiektowym?
>

Wszystko da sie zrobic w czymkolwiek. nawet w asemblerze a nawet
Maszynie Turinga. Obiektowoc czy nieobiektowosc to sposob
postrzegania zadanai ktore sie ma rozwiazac.

>Prosze o jakis przyklad.
>Prosze tylko nie  pisac ze jest ono latwiejsze do zrozumienia
>bo wszystko jest postrzegane jako obiekty, takie argumenty nie sa
>najlepsze.

Niestety, nikt nei bedzie pzrepisywal tu ksiazek. Proponuje udac sie
do ksiegarni albo biblioteki, a tu pojawic sie z konkretnymi
pytaniami.

A.L.

"Hattori Hanzo" <hattoriWYTNIJTO@poczta.onet.pl> writes:

> Witam
>
> Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
>
> Jaka jest idea programowania obiektowego?

polimorfizm, enkapsulacja, dziedziczenie

> czym sie ona rozni od strukturalnego?

Tymi trzema technikami.

> Czy jest jakas rzecz, ktorej nie da sie zrobic w strukturalnym
> programowaniu a tylko w obiektowym?

Pytanie na poziomie 'czy jest jakaś rzecz, którą da się zaprogramować
na Maszynie Turinga, której nie da się zdefiniować w rachunku
lambda?'.  Otóż, zgodnie z najnowszymi hipotezami teoretyków, nie.

> Prosze o jakis przyklad.

Programowania OO?  Dużo przykładów jest w kodzie źródłowym
OpenOffice.org.

> Prosze tylko nie pisac ze jest ono latwiejsze do zrozumienia bo
> wszystko jest postrzegane jako obiekty, takie argumenty nie sa
> najlepsze.

Programowanie OO jest obecnie wiodącą techniką programistyczną.

8-)

-- 
http://www.piotr.dembiński.prv.pl

Hattori Hanzo napisał(a):
> Witam
> 
> Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
> 
> Jaka jest idea programowania obiektowego?
> czym sie ona rozni od strukturalnego?
> Czy jest jakas rzecz, ktorej nie da sie zrobic w strukturalnym
> programowaniu a tylko w obiektowym?
> 
> Prosze o jakis przyklad.
> Prosze tylko nie  pisac ze jest ono latwiejsze do zrozumienia
> bo wszystko jest postrzegane jako obiekty, takie argumenty nie sa
> najlepsze.
> 
> pozdrawiam
> hh
> 
W jednym z ostatnich wydań pc world komputer był artykuł na ten temat. 
Uważam że na paru stronach dość zrozumiale to opisali. Inna sprawa że OO 
nie jest mi obce także nie wiem co zyska z niego osoba nie znająca 
tematu. Ja zrozumiałem OO po po przeczytaniu tej pozycji:
http://helion.pl/ksiazki/cpzobv.htm

pozdrawiam r

Dnia Mon, 05 Dec 2005 13:41:53 +0100, Piotr Dembiński skrobie:
> "Hattori Hanzo" <hattoriWYTNIJTO@poczta.onet.pl> writes:

> > Witam
> >
> > Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
> >
> > Jaka jest idea programowania obiektowego?

> polimorfizm, enkapsulacja, dziedziczenie

Niektórzy są zdania, że niestety nie.

Te trzy rzeczy to jedynie narzędzia (i to nie jedyne) do osiągnięcia tego
celu. Ich stosowanie jest jedynie kwestią tego, że takie narzędzia uznano do
tego celu za najlepsze i ich stosowanie jest powszechne. Nie znaczy to wcale,
że ich używanie warunkuje programowanie obiektowe.

A celem programowania obiektowego jest wykorzystanie obiektu jako elementu
decydującego o sposobie wykonania wskazanej mu operacji.

Polimorfizm to wykonuje, ale żebyśmy mówili o "polimorfiźmie" to musimy
przyjąć jakąś "postaciowość" w ogóle, stwierdzić że ona istnieje i jest
opisana określonymi regułami. Polimorfizm jest zatem również związany z
istnieniem jakichś podstawowych i rozbudowanych form. Możemy tego nie mieć w
ogóle i korzystać z jakiejś innej metody sposobu decydowania przez obiekt o
tym, jak ma wykonać zadaną operację.

Enkapsulacja z kolei to co najwyżej stwierdzenie, że odpowiednio decydujemy o
udostępnianiu na zewnątrz wnętrza obiektu. Jest to zatem rzecz dość oczywista,
bo skoro nie mówimy o implementacji, to w jaki niby sposób dane miałyby być
udostępniane? Jest sens o tym mówić, gdy musimy używać określonych sposobów na
ukrywanie, a nie sposobów na udostępnianie.

A dziedziczenie to tylko metoda na ułatwienie sobie życia i bezpośrednio z
obiektowością związku nie ma. Aby mówić o dziedziczeniu, trzeba mówić też o
klasach, które nie są jedyną metodą na zdefiniowanie sposobu odpowiedzi
obiektu na zadane wymuszenie. Jeśli nie jest to realizowane przez klasy, to i
nie ma mowy o żadnym dziedziczeniu.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Mon, 05 Dec 2005 13:41:53 +0100, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>"Hattori Hanzo" <hattoriWYTNIJTO@poczta.onet.pl> writes:
>
>> Witam
>>
>> Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
>>
>> Jaka jest idea programowania obiektowego?
>
>polimorfizm, enkapsulacja, dziedziczenie
>
>> czym sie ona rozni od strukturalnego?
>
>Tymi trzema technikami.

Niestety, mozna robic programowanei obiektowe bez zadnej z powyzszych
rzeczy.

A.L>

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

[...]

> A celem programowania obiektowego jest wykorzystanie obiektu jako
> elementu decydującego o sposobie wykonania wskazanej mu operacji.

Fakt.  Jak jeszcze nie ma tego w FAQ, to proponuję dopisać.

Dnia Thu, 08 Dec 2005 20:19:08 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> [...]

> > A celem programowania obiektowego jest wykorzystanie obiektu jako
> > elementu decydującego o sposobie wykonania wskazanej mu operacji.

> Fakt.  Jak jeszcze nie ma tego w FAQ, to proponuję dopisać.

Jakim FAQ? Tym, które przychodzi tutaj raz na jakiś czas?
To tylko bot, który powinien był umrzeć śmiercią naturalną, ale niestety nikt
go nie ubił, więc co jakiś czas się odzywa. To jest zwykłe zombie, tego FAQ
nikt nie aktualizował od DZIESIĘCIU (!) lat. Pomijając już to, że jest
żałosne, nawet jak na tak nieaktualne.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Thu, 8 Dec 2005 22:41:12 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Thu, 08 Dec 2005 20:19:08 +0100, Piotr Dembiński skrobie:
>> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
>
>> [...]
>
>> > A celem programowania obiektowego jest wykorzystanie obiektu jako
>> > elementu decydującego o sposobie wykonania wskazanej mu operacji.
>
>> Fakt.  Jak jeszcze nie ma tego w FAQ, to proponuję dopisać.
>
>Jakim FAQ? Tym, które przychodzi tutaj raz na jakiś czas?
>To tylko bot, który powinien był umrzeć śmiercią naturalną, ale niestety nikt
>go nie ubił, więc co jakiś czas się odzywa. To jest zwykłe zombie, tego FAQ
>nikt nie aktualizował od DZIESIĘCIU (!) lat. Pomijając już to, że jest
>żałosne, nawet jak na tak nieaktualne.

To jest bardzo pokrzepiajace, Panie Sektor. To znaczy ze jakis
komputer dziala od 10 lat i nie padl ani razu :)

A.L.

A.L. wrote (tak! stara dobra wrotka!):

> To znaczy ze jakis
> komputer dziala od 10 lat i nie padl ani razu :)

Może padł, ale ma np. sprawnego crone'a.

-- 
Zbigniew Malec Ustronie:104 gg:2756100

On Fri, 9 Dec 2005 01:14:26 +0100, Zbyszek Malec <zbyszekto@tlen.pl>
wrote:

>A.L. wrote (tak! stara dobra wrotka!):
>
>> To znaczy ze jakis
>> komputer dziala od 10 lat i nie padl ani razu :)
>
>Mo¿e pad³, ale ma np. sprawnego crone'a.

Tym niemniej, bardzo pokzrepiajace na duchu.

A.L.

Dnia Thu, 08 Dec 2005 17:23:30 -0600, A.L. skrobie:
> On Thu, 8 Dec 2005 22:41:12 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> >Dnia Thu, 08 Dec 2005 20:19:08 +0100, Piotr Dembiński skrobie:
> >> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
> >
> >> [...]
> >
> >> > A celem programowania obiektowego jest wykorzystanie obiektu jako
> >> > elementu decydującego o sposobie wykonania wskazanej mu operacji.
> >
> >> Fakt.  Jak jeszcze nie ma tego w FAQ, to proponuję dopisać.
> >
> >Jakim FAQ? Tym, które przychodzi tutaj raz na jakiś czas?
> >To tylko bot, który powinien był umrzeć śmiercią naturalną, ale niestety nikt
> >go nie ubił, więc co jakiś czas się odzywa. To jest zwykłe zombie, tego FAQ
> >nikt nie aktualizował od DZIESIĘCIU (!) lat. Pomijając już to, że jest
> >żałosne, nawet jak na tak nieaktualne.

> To jest bardzo pokrzepiajace, Panie Sektor. To znaczy ze jakis
> komputer dziala od 10 lat i nie padl ani razu :)

To pan mówi o komputerze.

Tak, są rzeczy, które potrafią przetrwać takie lata. Wydawało mi się, że pan,
jako stary wyjadacz informatyki, powinien o tym lepiej ode mnie wiedzieć.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Hattori Hanzo wrote:
>
> Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
>
> Jaka jest idea programowania obiektowego?

IMHO ciekawie ideę _projektowania_obiektowego_ sformułował dziadek
Yourdon (http://www.yourdon.com), a ponieważ dopiero od 2 lat
zgłębiam OOAD i OOP to wolę pomóc sobie cytatem, niż samodzielnie
ciepać teoriami (więc pewnie to nie ostatni cytat z mej strony :-).

Najpierw Ed rzuca taki wniosek:

"Analiza i projektowanie dużych, złożonych systemów informatycznych
są trudne. Koniec. Kropka"

a następnie stwierdza:

"Podejście obiektowe nie sprawia, że analiza i projektowanie stają
się łatwiejsze niż poprzednie metody. Pomaga jedynie zbudować
lepszy produkt. Pomaga poprawić efektywność. Ale nie jest panaceum."

(źródło "Case Studies in Object-Oriented Analysis and Design")

Wydaje mi się, że szczególnie o tej drugiej części się często
zapomina.

Dla wyjaśnienia, autor wątku pyta o _programowanie_ obiektowe (OOP),
ale co pewnie oczywiste to tylko konsekwencja analizy i projektowania
obiektowego (OOAD). Może nie konsekwencja, a bardziej dopasowany
(naturalny) sposób wyrażenia tego co wyłania się z OOAD. Jak już
Pan A.L. orzekł, programować obiektowo można "we wszystkim", nawet w
narzędziem strukturalnym, ale wydaje mi się, że mimo wszystko nawet
to musi być poprzedzone OOAD. Dlaczego? Odwrotna sytuacja (projekt
strukturalny, implementacja obiektowa) byłaby w moim przekonaniu
niemożliwa. Jak wyglądałby projekt strukturalny?
Modularyzacja oznaczałaby pocięcie problemu wg. funkcji i/lub
dodatkowo wg. struktur danych, gdzie moduł = jedna struktura danych,
gdzieś pewnie jeszcze by się zapodział podział wg.
zdarzeń...ostatecznie tak poszatkowanego systemu nikt by nie
zaimplementował w stylu OOP. Bo gdzie tu nierozłączne pojęcie
OOAD-OOP czyli obiekt?

Hehe, tu chciałbym znów zacytować dziadka Yourdona i jego
przebojową definicję obiektu:

Czym jest obiekt?
Obiekt jest niezależną, asynchroniczną, współbieżną jednostką,
która "wie, o co chodzi" (przechowuje dane), "działa" (wykonuje
usługi) i "współpracuje z innymi obiektami" (wymienia komunikaty) w
celu realizacji funkcji systemu"

(tu bym dodał od siebie, że "części systemu za jaką powołany do
życia obiekt jest odpowiedzialny").

...uwielbiam :-)

p.s. dawno na grupę nie zaglądałem, widzę, że ruch się zrobił, a
czy comp.object to siostrzana grupa w wersji angielskiej?

Pozdrawiam
--
Mateusz Łoskot
http://mateusz.loskot.net

On 10 Dec 2005 19:42:39 -0800, "Mateusz Łoskot" <mateusz@loskot.net>
wrote:
 
>Czym jest obiekt?
>Obiekt jest niezależną, asynchroniczną, współbieżną jednostką,
>która "wie, o co chodzi" (przechowuje dane), "działa" (wykonuje
>usługi) i "współpracuje z innymi obiektami" (wymienia komunikaty) w
>celu realizacji funkcji systemu"

To ciekawe. Bo ja mam tu obiekty ktore a) nie sa niezalezne, b) nie
sa asynchroniczne, c) nie wymieniaja z nikim komunikatow. Znaczy
sie, nie programuje obiektowo?... Tylko jak?....

A.L.

P.S. Tak na marginesie, co to jest "projekt strukturalny"?...

On 10 Dec 2005 19:42:39 -0800, "Mateusz Łoskot" <mateusz@loskot.net>
wrote:

>H 
>to musi być poprzedzone OOAD. Dlaczego? Odwrotna sytuacja (projekt
>strukturalny, implementacja obiektowa) byłaby w moim przekonaniu
>niemożliwa. Jak wyglądałby projekt strukturalny?

Projekt strukturalny wygladalby jak projekt strukturalny. Jako "data
flows", "prcesses" i "stores". Mozna to-to zaimplementowac w sposob
dowolny, obiektowy jak najbardziej. Juz to widze: obiekt "data
flow", obiekt "process", obiekt "store". Na czym polega problem? 


>Modularyzacja oznaczałaby pocięcie problemu wg. funkcji i/lub
>dodatkowo wg. struktur danych, gdzie moduł = jedna struktura danych,
>gdzieś pewnie jeszcze by się zapodział podział wg.
>zdarzeń...ostatecznie tak poszatkowanego systemu nikt by nie
>zaimplementował w stylu OOP. Bo gdzie tu nierozłączne pojęcie
>OOAD-OOP czyli obiekt?

Co to jest "styl OOP"?...

Proponuje pogoglowac na haslo Clemens Szyperski, Component Software,
Oberon. Juz dawno odkryto ze obiektowosc i modularyzacja to pojecia
ortogonalne i wzajemnie sie uzupelniajace. Zreszta, jezyk Oberon ma
oba, to znaczy moduly i obiekty, ktore na dodatek nie sa tworzone
przy pomocy klas. Oberon po prostu nie ma klas, i mimo tego jest
jezykiem obiektowym. Proponuje zajrzec do ksiazki Szyperskiego
"Component Software: Beyond Object Oriented Programming" i do
materialow europejskiej konferencji obiektowej EOOP. Nei pamietam
roku, neistety
>
>Hehe, tu chciałbym znów zacytować dziadka Yourdona i jego
>przebojową definicję obiektu:
>
>Czym jest obiekt?
>Obiekt jest niezależną, asynchroniczną, współbieżną jednostką,
>która "wie, o co chodzi" (przechowuje dane), "działa" (wykonuje
>usługi) i "współpracuje z innymi obiektami" (wymienia komunikaty) w
>celu realizacji funkcji systemu"
>

Jak juz napisalem w innym poscie, jest to totalna bzdura.

>(tu bym dodał od siebie, że "części systemu za jaką powołany do
>życia obiekt jest odpowiedzialny").
>
>...uwielbiam :-)
>
>p.s. dawno na grupę nie zaglądałem, widzę, że ruch się zrobił, a
>czy comp.object to siostrzana grupa w wersji angielskiej?
>
>Pozdrawiam

A.L. <alewando@fala56.com> writes:

[...]

> P.S. Tak na marginesie, co to jest "projekt strukturalny"?...

deployment diagram?

A.L. <alewando@fala56.com> writes:

[...]

>>Obiekt jest niezależną, asynchroniczną, współbieżną jednostką, 
>>która "wie, o co chodzi" (przechowuje dane), "działa" (wykonuje 
>>usługi) i "współpracuje z innymi obiektami" (wymienia komunikaty) 
>>w celu realizacji funkcji systemu"
>>
>
> Jak juz napisalem w innym poscie, jest to totalna bzdura.

A 'wymiana komunikatów' nie jest przypadkiem uogólnieniem 
dla odwoływania się do metod obiektu?

A.L. wrote:
> On 10 Dec 2005 19:42:39 -0800, "Mateusz Łoskot" <mateusz@loskot.net>
> wrote:
>
> >Czym jest obiekt?
> >Obiekt jest niezależną, asynchroniczną, współbieżną jednostką,
> >która "wie, o co chodzi" (przechowuje dane), "działa" (wykonuje
> >usługi) i "współpracuje z innymi obiektami" (wymienia komunikaty) w
> >celu realizacji funkcji systemu"
>
> To ciekawe. Bo ja mam tu obiekty ktore a) nie sa niezalezne, b) nie
> sa asynchroniczne, c) nie wymieniaja z nikim komunikatow. Znaczy
> sie, nie programuje obiektowo?... Tylko jak?....
>

Proszę zwrócić uwagę na to w jaki sposób odniosłem się do tej
definicji:

"Hehe, tu chciałbym znów zacytować dziadka Yourdona i jego
przebojową definicję obiektu:"

i na koniec

...uwielbiam :-)

Tym samym chciałem wyrazić pewne obazy czy zdziwienie tą definicją.

A teraz odnoszą się do Pana "zarzutów":

a) i b) - jeszcze nie dotarłem (nie wiem gdzie szukać) wyjaśnienia
tych terminów w rozumieniu Yourdon'a; tak aby to tu miało sens.
Tak więc nie wiem, czy niezależność należy rozumieć jako
enkapsulację. Osobiście to wymyśliłem (pewnie ktoś mi powie, abym
już nie wymyślał, ale co mi tam :-)
sobie taką analogię do tej niezależności, że to jest jak z
komórką (jednostka żywej materii), której niezależność strzeże
błona komórkowa (selektywna komunikacja/wymiana danych) - czyli
interfejs obiektu.

c) IMHO to znaczy, ze Pana obiekty są w ogóle nieużywane.

> P.S. Tak na marginesie, co to jest "projekt strukturalny"?...

Fakt, pojęcie troche niefortunne w odniesieniu do czegoś, co stoi po
jakby przeciwnej stronie dla OOAD-OOP. Oczywiste, że OOAD-OOP określa
jakąś strukturę.
Chodziło mi o połączenie dekopozycji funkcjonalnej, strukturalnej
czyli dekompozycja względem danych.

Pozdrawiam
--
Mateusz Łoskot
http://mateusz.loskot.net

A.L. wrote:
> On 10 Dec 2005 19:42:39 -0800, Mateusz Łoskot wrote:
>
> >to musi być poprzedzone OOAD. Dlaczego? Odwrotna sytuacja (projekt
> >strukturalny, implementacja obiektowa) byłaby w moim przekonaniu
> >niemożliwa. Jak wyglądałby projekt strukturalny?
>
> Projekt strukturalny wygladalby jak projekt strukturalny. Jako "data
> flows", "prcesses" i "stores". Mozna to-to zaimplementowac w sposob
> dowolny, obiektowy jak najbardziej. Juz to widze: obiekt "data
> flow", obiekt "process", obiekt "store". Na czym polega problem?

Hm, poddaję się :-) Ja po prostu nie widzę (widziałem) takich
obiektów.
Równie dobrze serwer HTTP można potraktować jako obiekt.

>
> Co to jest "styl OOP"?...
>

Określiłbym to tak (zapewne są tu braki): Styll OOP to realizacja z
użyciem cech języka pozwalających na zdefiniowanie "czarnej
skrzynki" jaką niewątpliwie jest obiekt, zapewniającej odpowiednią
izolację implementacji (wnętrza) od świata zewnętrznego.

> Proponuje pogoglowac na haslo Clemens Szyperski, Component Software,
> Oberon.

Dzięki, znalazłem, jak znajdę książke to poczytam.

> Juz dawno odkryto ze obiektowosc i modularyzacja to pojecia
> ortogonalne i wzajemnie sie uzupelniajace.

Bo co złego w nazwaniu obiektu modułem?

> Zreszta, jezyk Oberon ma
> oba, to znaczy moduly i obiekty, ktore na dodatek nie sa tworzone
> przy pomocy klas. Oberon po prostu nie ma klas, i mimo tego jest
> jezykiem obiektowym.

Nie twierdzę, że tak nie może być. Jeśli daje możliwość
określenia "czarnych skrzynek" (zwał jak zwał) to zgadzam się.

> >Hehe, tu chciałbym znów zacytować dziadka Yourdona i jego
> >przebojową definicję obiektu:
> >
> >Czym jest obiekt?
> >Obiekt jest niezależną, asynchroniczną, współbieżną jednostką,
> >która "wie, o co chodzi" (przechowuje dane), "działa" (wykonuje
> >usługi) i "współpracuje z innymi obiektami" (wymienia komunikaty) w
> >celu realizacji funkcji systemu"
> >
>
> Jak juz napisalem w innym poscie, jest to totalna bzdura.

Jak napisałem w poprzedniej odpowidzi, dla mnie jest to dośc
egzotyczna definicja.
Zgodziłbym się z drugą jej częścią:
"wie, o co chodzi" (przechowuje dane), "działa" (wykonuje usługi) i
"współpracuje z innymi obiektami" (wymienia komunikaty)"

Ale i tu, spotkałem się z określeniem usług jako właśnie
komunikatów, gdzie zwykłe wywołanie metody danej klasy na rzecz
jakiegoś obiektu to wywołanie komunikatu czyli relacja
request-answer.

Ktoś inny stwierdzi, że definicja obiektu sformułowana przez pana X
to jest też bzdura.
Ja osobiście za krótki jestem aby jednoznacznie wyrokować co jest a
co nie jest dobrą definicją.

Pozdrawiam
--
Mateusz Łoskot
http://mateusz.loskot.net

Dnia Sun, 11 Dec 2005 12:49:10 +0100, Piotr Dembiński skrobie:
> A.L. <alewando@fala56.com> writes:

> [...]

> > P.S. Tak na marginesie, co to jest "projekt strukturalny"?...

> deployment diagram?

To jest schemat wdrożenia.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Sun, 11 Dec 2005 12:49:10 +0100, pdemb@gazeta.pl (Piotr
Dembiński) wrote:

>A.L. <alewando@fala56.com> writes:
>
>[...]
>
>> P.S. Tak na marginesie, co to jest "projekt strukturalny"?...
>
>deployment diagram?

Ja zadalem pytanie retoryczne do oryginalnego pytacza. "Projekt
strukturalny" to projekt sformulowany w kategoriach przeplywow,
procesow i jednostek pamieci (store). Tak sie projektowalo dawnymi
czasy i nadal sie projektuje w sytuacjach gdy wlasnei taki model
swiata pasuje bardziej niz obiektowy. Bardziej on pasuje w takich
sytuacjach jak "workflow" gdy dane przesylane sa od jednej "stacji
obrobczej" do nastepnej. Jest to wyluszczone w roznych ksiazkach, na
przyklad ksiazce tegoz Yourdona "Modern Structured Analysis", 1989
czy De Marco "Structured Analysis and System Specification", 1979.

Jeszcze raz powtorze, ze opis strukturalny. obiektowy czy
jakikolwiek inny to MODEL rzeczywistosci, i w kazdym okreslonym
przypadku jeden z nich jest na ogol bardziej poreczny niz drugi
(prosze zwrocic uwage ze nie mowie "lepszy"). Ta sama rzeczywistosc
moze meic wiele roznych modeli. Model obiektowy wcale nie jest z
definicji lepszy niz na przyklad strukturalny.

Oba modele mozna zaprogramowac jak sie chce i w czym sie chce. Tyle
ze pewne jezyki posiadaja wsparcie dla okreslonego modelu przez
dostarczeni konstrukcji programistycznych ktore ulatwiaja
programowanie okresonego modelu. Nei ma jednak nijakiego
a'priorycznego zwiazku miedzy modelem a sposobem implementacji,
podobnie jak nei ma zadnego przymusu aby stosowac okreslone
narzedzia. W konsekwencji obiektowa analiza i projektowanie ma
niewiele wspolnego z obiektowym programowaniem.

A.L.

A.L. <alewando@fala56.com> writes:

[...]

> Jeszcze raz powtorze, ze opis strukturalny. obiektowy czy
> jakikolwiek inny to MODEL rzeczywistosci, i w kazdym okreslonym
> przypadku jeden z nich jest na ogol bardziej poreczny niz drugi
> (prosze zwrocic uwage ze nie mowie "lepszy"). Ta sama rzeczywistosc
> moze meic wiele roznych modeli. Model obiektowy wcale nie jest 
> z definicji lepszy niz na przyklad strukturalny.
>
> Oba modele mozna zaprogramowac jak sie chce i w czym sie chce. 

Ależ modeli się nie programuje.  Modele można co najwyżej wykorzystać
do zaprojektowania systemu.

Piotr Dembiński wrote:
> A.L. <alewando@fala56.com> writes:
>
> [...]
>
> > Jeszcze raz powtorze, ze opis strukturalny. obiektowy czy
> > jakikolwiek inny to MODEL rzeczywistosci, i w kazdym okreslonym
> > przypadku jeden z nich jest na ogol bardziej poreczny niz drugi
> > (prosze zwrocic uwage ze nie mowie "lepszy"). Ta sama rzeczywistosc
> > moze meic wiele roznych modeli. Model obiektowy wcale nie jest
> > z definicji lepszy niz na przyklad strukturalny.
> >
> > Oba modele mozna zaprogramowac jak sie chce i w czym sie chce.
>
> Ależ modeli się nie programuje.  Modele można co najwyżej wykorzystać
> do zaprojektowania systemu.

Piotr, kombinujesz albo nie czytasz ze zrozumieniem.

Stwierdzenie "Oba modele mozna zaprogramowac jak sie chce i w czym sie
chce." oznacza, że mając model (taki albo taki) można oprogramować
to co on reprezentuje.
Na zasadzie jest projekt (model) no i na jebo bazie coś budujesz
(programujesz).

Oprogramowanie modelu oznacza wykonanie programu na bazie jakiegoś
modelu/projektu.

Pozdrawiam
--
Mateusz Łoskot
http://mateusz.loskot.net

On Sun, 11 Dec 2005 23:37:26 +0100, pdemb@gazeta.pl (Piotr
Dembiński) wrote:

>A.L. <alewando@fala56.com> writes:
>
>[...]
>
>> Jeszcze raz powtorze, ze opis strukturalny. obiektowy czy
>> jakikolwiek inny to MODEL rzeczywistosci, i w kazdym okreslonym
>> przypadku jeden z nich jest na ogol bardziej poreczny niz drugi
>> (prosze zwrocic uwage ze nie mowie "lepszy"). Ta sama rzeczywistosc
>> moze meic wiele roznych modeli. Model obiektowy wcale nie jest 
>> z definicji lepszy niz na przyklad strukturalny.
>>
>> Oba modele mozna zaprogramowac jak sie chce i w czym sie chce. 
>
>Ależ modeli się nie programuje.  Modele można co najwyżej wykorzystać
>do zaprojektowania systemu.

Zna Pan dowcip o bacy i juhasie?...

A.L.

A.L. wrote (tak! stara dobra wrotka!):

> Zna Pan dowcip o bacy i juhasie?...

Nie wiem jak Piotr, ale ja nie znam. Można prosić?

-- 
Zbigniew Malec Ustronie:104 gg:2756100

On Sun, 11 Dec 2005 23:58:37 +0100, Zbyszek Malec
<zbyszekto@tlen.pl> wrote:

>A.L. wrote (tak! stara dobra wrotka!):
>
>> Zna Pan dowcip o bacy i juhasie?...
>
>Nie wiem jak Piotr, ale ja nie znam. Można prosić?

Brzydki jest....

A.L.

A.L. wrote:
> On Sun, 11 Dec 2005 23:58:37 +0100, Zbyszek Malec
> <zbyszekto@tlen.pl> wrote:
>
> >A.L. wrote (tak! stara dobra wrotka!):
> >
> >> Zna Pan dowcip o bacy i juhasie?...
> >
> >Nie wiem jak Piotr, ale ja nie znam. Można prosić?
>
> Brzydki jest....
>

A wyjaśnia ideę OOP? ,-)
Jak tak to chyba nie będzie OT.
Pozdrawiam
--
Mateusz Łoskot
http://mateusz.loskot.net

On 11 Dec 2005 19:32:42 -0800, "Mateusz Łoskot" <mateusz@loskot.net>
wrote:

>A.L. wrote:
>> On Sun, 11 Dec 2005 23:58:37 +0100, Zbyszek Malec
>> <zbyszekto@tlen.pl> wrote:
>>
>> >A.L. wrote (tak! stara dobra wrotka!):
>> >
>> >> Zna Pan dowcip o bacy i juhasie?...
>> >
>> >Nie wiem jak Piotr, ale ja nie znam. Można prosić?
>>
>> Brzydki jest....
>>
>
>A wyjaśnia ideę OOP? ,-)
>Jak tak to chyba nie będzie OT.
>Pozdrawiam

Nie, nie wyjasnia...

A.L.

A.L. wrote:
> On 11 Dec 2005 19:32:42 -0800, Mateusz Łoskot wrote:
>
> >
> >A wyjaśnia ideę OOP? ,-)
> >Jak tak to chyba nie będzie OT.
> >Pozdrawiam
>
> Nie, nie wyjasnia...
>

No to może aby nie przedłużać wątku pokusiłby się Pan o jakieś
krótkie podsumowanie czym jest a czym nie jest OOP?
Wiem, że to kwalifikuje się na książkę, ale skoro np.
Yourdon'owska definicja obiektu jest niewypałem, to czyja jest trafna?
Kto z autorów prezentuje najsensowniejszą wizję OOAD-OOP.

A już w ogóle byłoby cudnie, jakby mógł Pan podać:

Najkrótszą z prawdziwych definicji obiektu, jeśli jest możliwe
wyrażenie tego pojęcia w 2-5 zdaniach.

Jak OOAD-OOP się ma do innych metodyk/styli/<tu trafna nazwa związana
z dekompozycją funkcjonalna/strukturalną problemów>?

Jeśli nie to choć parę tytułów/nazwisk godnych uwagi?

Z góry dziękuję

--
Mateusz Łoskot
http://mateusz.loskot.net

A.L. <alewando@fala56.com> writes:

[...]

> Zna Pan dowcip o bacy i juhasie?...

Ten o gąsce Balbince?

Sorry, NMSP ;)

Dnia Mon, 12 Dec 2005 12:45:49 +0100, Piotr Dembiński skrobie:
> A.L. <alewando@fala56.com> writes:

> [...]

> > Zna Pan dowcip o bacy i juhasie?...

> Ten o gąsce Balbince?

Ależ wodzu, co wódz!

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Hattori Hanzo wrote:
>
> Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
> [...]
>

Właśnie natrafiłem w sieci na blog H.S. Lahman'a, na którym jest
takie cuś:

http://pathfinderpeople.blogs.com/hslahman/what_is_oo_development_all_about/index.html

Pozdrawiam
--
Mateusz Łoskot
http://mateusz.loskot.net

> Czy moze ktos mi wytlumaczyc, lub odeslac do ciekawego zrodla:
>
> Jaka jest idea programowania obiektowego?
> czym sie ona rozni od strukturalnego?
> Czy jest jakas rzecz, ktorej nie da sie zrobic w strukturalnym
> programowaniu a tylko w obiektowym?
>
> Prosze o jakis przyklad.
> Prosze tylko nie  pisac ze jest ono latwiejsze do zrozumienia
> bo wszystko jest postrzegane jako obiekty, takie argumenty nie sa
> najlepsze.

Programując strukturanie jakiś naprawdę duży program, nawet jeśli będziesz 
się staral zrobić to czytelnie i dobrze będziesz wykonywał dokumentacje do 
tego to po pewnym czasie po prostu się w tym wszystkim pogubisz bo dojdzie 
do stytuacji w której zmieniając jakaś pierdołe w jednej części programu, 
uzyskasz taki efekt że w pozostałych partiach programu pojawi się 10 Bugów o 
których nawet nie pomyślisz (z programowania strukturalnego w praktyce robi 
się po prostu jeden wielki burdel nie do ogarnięcia). Przynajmniej z mojego 
doświadczenia tak wynika.

Oczywiście dać się da :) ale po co jak programujac obiektowo da się 
większości z takich sytuacji uniknąć (acz kolwiek to też trzeba robić z 
głową). Programowanie OOP ma to do siebie że jeśli trzymasz się pewnych 
ścisłych zasad to poszczególne wyodrębnione części programu (obiekty) są w 
maire samodzielne i niezależne od siebie. W każdym razie napewno warto 
programować obiektowo (nie wyobrażam sobie pisania dużego programu w sposób 
tylko strukturalny nie wiem może dlatego że nie potrafię strukturalnie pisać 
bo być może są jakieś metody aby zaoponować również nad strukturalnym 
programem, ale myślę że dla kogoś kto nie potrafi programować obiektowo 
pisanie strukturalne jakiegoś dużego programu było by koszmarem :) już nawet 
nie mówię że nie wyobrażam sobie pisania w grupie. 

Grzeczna odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana „Kurciok”.
> Hattori Hanzo:

>> Prosze o jakis przyklad.
>> Prosze tylko nie  pisac ze jest ono latwiejsze do zrozumienia
>> bo wszystko jest postrzegane jako obiekty, takie argumenty nie sa
>> najlepsze.

> Programując strukturanie jakiś naprawdę duży program, nawet jeśli
> będziesz się staral zrobić to czytelnie i dobrze będziesz wykonywał
> dokumentacje do tego to po pewnym czasie po prostu się w tym wszystkim
> pogubisz bo dojdzie do stytuacji w której zmieniając jakaś pierdołe
> w jednej części programu, uzyskasz taki efekt że w pozostałych
> partiach programu pojawi się 10 Bugów o których nawet nie pomyślisz
> (z programowania strukturalnego w praktyce robi się po prostu jeden
> wielki burdel nie do ogarnięcia). Przynajmniej z mojego doświadczenia
> tak wynika.
> 
> Oczywiście dać się da :) ale po co jak programujac obiektowo da się
> większości z takich sytuacji uniknąć (acz kolwiek to też trzeba
> robić z głową). Programowanie OOP ma to do siebie że jeśli trzymasz
> się pewnych ścisłych zasad to poszczególne wyodrębnione części
> programu (obiekty) są w maire samodzielne i niezależne od siebie. W
> każdym razie napewno warto programować obiektowo (nie wyobrażam sobie
> pisania dużego programu w sposób tylko strukturalny nie wiem może
> dlatego że nie potrafię strukturalnie pisać bo być może są jakieś
> metody aby zaoponować również nad strukturalnym programem, ale
> myślę że dla kogoś kto nie potrafi programować obiektowo pisanie
> strukturalne jakiegoś dużego programu było by koszmarem :) już nawet
> nie mówię że nie wyobrażam sobie pisania w grupie.

Właśnie programowanie strukturalne daje pełne możliwości dla dużego
projektu. Ale programowanie strukturalne wymaga utworzenia modelu takiego
projektu, co w wypadku programowania obiektowego nie jest konieczne.
Programowanie obiektowe narzuca pewne reguły pakowania abstrakcyjnego z
liczeniem na to, że kompilator „jakoś” to wszystko poukłada i
zoptymalizuje. Programowanie strukturalne wymaga analizy całości
zagadnienia i unikania niepotrzebnego kodu w ramach modelu, który jest
utrzymywany. W programowaniu strukturalnym możliwe są dowolne ustalone
zależności, w programowaniu obiektowym, zależnie od języka, jest
wymuszony model obiektowy, w którym podstawia się nazwy i powiązania
możliwe w takim modelu, a „niemożliwe” umożliwia się przy użyciu
sprzecznych z modelem obiektowym zachowań. W późniejszym czasie ktoś
decyduje się zrobić strukturę obiektową dla tych nieformalnych
zachowań progromowanych w języku obiektowym i powstaje
samodokumentujący się kod obiektowy. Tylko należy zauważyć, że w
modelu obiektowym jest wyraźnie od samego początku widoczna
niedogodność, która powoduje, że programiści mogą tworzyć nowe
obiekty, mające służyć jako komponenty w programie, ale za każdym
razem te obiekty nie będą w stanie rozwiązać problemu wprost.
Ta niedogodność to jest zasadnicza cecha programowania obiektowego:
każda relacja między danymi musi być zapisana w postaci obiektu
fizycznego. Tymczasem relacje między danymi w rzeczywistości nie są
obiektami. Obiektami są tylko i wyłącznie dane. Konsekwencją takiego
programowania (obiektowego) jest opakowywanie pojedynczego obiektu całą
masą innych obiektów, które reprezentują relacje między tym obiektem,
a innymi obiektami. W programowaniu strukturalnym takie relacje między
danymi są opisane w modelu i w programie muszą być przestrzegane.
Natomiast nie ma potrzeby ich opakowywać we własne wewnętrzne struktury.
Dlatego kompilacja programu napisanego strukturalnie trwa o rzędy
wielkości mniej niż programu napisanego obiektowo. To samo z użyciem
pamięci podczas kompilacji.

Wniosek:

Programowanie obiektowe wymusza opisywanie relacji pomiędzy
danymi w postaci obiektów zamiast trzymania się modelu programowania
specyficznego dla danego projektu. Programowanie strukturalne umożliwia
użycie danych wprost z zachowaniem modelu postępowania, który trzeba
ustalić wcześniej i uaktualniać.

Przykład:

Jako przykłady dla początkujacych programistów, by zachęcić ich do
programowania obiektowego, są podawane proste obiekty. Przykładowo:
obiekt młotek. Bardzo wygodny obiekt, który służy do jasno
określonych czynności. Kiedy programista zdecyduje się programować
obiektowo, wtedy już widzi, gdzie tkwił problem. Nie wiadomo, kto używa
młotka, nie wiadomo, jak używa młotka, nie wiadomo, na czym używa
młotka. Jedyne, co można zrobić faktycznie, to opisać, jaki jest ten
młotek. Wszystko inne trzeba robić przez definiowanie nowych obiektów,
które reprezentują relacje młotka z innymi obiektami albo wciskać do
tych obiektów metody obsługujące takie relacje - raz do jednego, raz do
drugiego. W programowaniu strukturalnym relacje określone są w modelu i
danych można użyć wprost przy pomocy funkcji usługowych dostosowanych
do konkretnego modelu tworzonego projektu.

Puenta:

Programowanie obiektowe jest wygodne do testowania nowych pomysłów
fragmentarycznych w ramach ustalonego środowiska. Różnica pomiędzy
programowanie obiektowych a strukturalnym (w szerokim pojęciu) jest jak
między językiem interpretowanym a kompilowanym. W językach
interpretowanych też mogą być tworzone duże projekty - inne jest
podejście do programowania. I jak na ironię mój odpowiednik języka
interpretowanego - program w języku obiektowym - jest często kompilowany
(ze względu na cechy języka, które posiadając musi być kompilowany) i
w takim wypadku użycie czasu i zasobów jest ogromne. Program
strukturalny musi mieć na początku określony konkretny cel jego
istnienia, a w miarę rozwoju jest on realizowany coraz lepiej w ramach
do końca rozumianego modelu. Programowanie obiektowe próbuje być
językiem deklaratywnym, ale nie jest w stanie sięgnąć języków
funkcyjnych.

Post scriptum:

Nie przekonasz osobiście - mnie do używania języka obiektowego
względem strukturalnego, jeśli chcesz to zrobić, więc raczej odpowiedz
na argumenty.

-- 
 qo   |)      > >>>>>>>> news:5af6.00001481.43561f30@newsgate.onet.pl...
    _x/ ,     błąd krytyczny: zabrakło wewnętrznie złamanych linii cytowania
    |    ng  __ -- __ -- __ -- __ -- __ -- __ -- __ -- __,
,__ -- __ -- news:5af6.000015c5.43567f13@newsgate.onet.pl

> Jako przykłady dla początkujacych programistów, by zachęcić ich do
> programowania obiektowego, są podawane proste obiekty. Przykładowo:
> obiekt młotek. Bardzo wygodny obiekt, który służy do jasno
> określonych czynności. Kiedy programista zdecyduje się programować
> obiektowo, wtedy już widzi, gdzie tkwił problem. Nie wiadomo, kto używa
> młotka, nie wiadomo, jak używa młotka, nie wiadomo, na czym używa
> młotka. Jedyne, co można zrobić faktycznie, to opisać, jaki jest ten
> młotek.

No ale do mnie to jest własnie duży plus. Bo dzięki temu mogę sobie najpierw 
napisać klasy wyszukać obiekty które istnieją w moim problemie zrobić do 
tego ładną i czytelną dokumentacje (bardzo zrozumiałą). Mogę sobie to zrobić 
nawet w taki sposób aby program działał niezaleznie od tego czy mam jakiś 
obiekt utworzony czy nie.


> Wszystko inne trzeba robić przez definiowanie nowych obiektów,
> które reprezentują relacje młotka z innymi obiektami albo wciskać do
> tych obiektów metody obsługujące takie relacje - raz do jednego, raz do
> drugiego.

No właśnie to jest łamanie zasad OOP moim zdaniem bo te relacje powinny być 
robione za pomocą zdarzeń (lub innej wymyślonej komunikacji). Ja zazwyczaj 
robię tak że tworze coś na wzór komunikatów z windowsa i jeśli jeden obiekt 
chce się skomunikować z drugim to musi zrobić to poprzez tą kolejke 
komunikatów. Inaczej mówiąc obiekt nie rozkazuje zrobić czegoś konkretnemu 
obiektowi, a tylko wysyła informację o tym że przemieścił się np. o jeden 
centrymetr w prawo. Przy okazji wszystkie obiekty są podbięte do tej kolejki 
komunikatów i nasłuchują czy przypadkiem nie powinny zareagować na jakiś 
komunikat.

On Sun, 8 Jan 2006 09:52:22 +0000 (UTC), q'Apacz
<qApacz@qApacze.invalid> wrote:
 
>
>Nie przekonasz osobiście - mnie do używania języka obiektowego
>względem strukturalnego, jeśli chcesz to zrobić, więc raczej odpowiedz
>na argumenty.

Nawet nei bede probowal.

A.L.

Grzeczna odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana
„Kurciok”.

>> Jako przykłady dla początkujacych programistów, by zachęcić ich do
>> programowania obiektowego, są podawane proste obiekty. Przykładowo:
>> obiekt młotek. Bardzo wygodny obiekt, który służy do jasno
>> określonych czynności. Kiedy programista zdecyduje się programować
>> obiektowo, wtedy już widzi, gdzie tkwił problem. Nie wiadomo, kto używa
>> młotka, nie wiadomo, jak używa młotka, nie wiadomo, na czym używa
>> młotka. Jedyne, co można zrobić faktycznie, to opisać, jaki jest ten
>> młotek.
> No ale do mnie to jest własnie duży plus. Bo dzięki temu mogę sobie najpierw 
> napisać klasy wyszukać obiekty które istnieją w moim problemie zrobić do 
> tego ładną i czytelną dokumentacje (bardzo zrozumiałą). Mogę sobie to zrobić 
> nawet w taki sposób aby program działał niezaleznie od tego czy mam jakiś 
> obiekt utworzony czy nie.
Zgadzam się, że jest wygodne dla programisty. Natomiast jaki związek ma
z rzeczywistością, w której fragment program ma się wkomponować.
Nawet utworzenie obiektu A, gdy w rzeczywistości jest obiekt A, jest tym
samym, co utworzenie dla rzeczywistego obiektu A dowolnego obiektu X.
Program ma realizować określone zadanie a nie być odbiciem fizycznych
obiektów, choćby dlatego że nie da się odwzorować fizycznych
obiektów a jedynie pewien zakres ich znaczenia. W takim razie nie ma
równoważności obiektu fizycznego A z obiektem A w programie. Każdy
obiekt w programie jest pewną abstrakcją relacji pomiędzy obiektami
fizycznymi, a skoro obiekty fizyczne same są odwzorowane w programie jako
abstrakcje, więc obiekt w programie jest abstrakcją relacji pomiędzy
obiektami w programie. Jeśli obiekt w programie byłby tylko obiektem
składającym się z danych, to wtedy możnaby się doszukiwać w nim relacji
między obiektami w programie - w formacie danych, jakiego używa do
przechowywania tych danych, naturalnego dla danej relacji. Jeśli zawiera
jakikolwiek kod programu, to ten kod opisuje relacje.
W poprzednim poście pisałem, że obiekty oznaczające relacje są
tworzone dla obiektu centralnego. Tutaj piszę, że obiekt centralny tak
samo opisuje relacje, jak obiekty go otaczające. Wolałem opisywać krok
po kroku z powiązaniem do opisu języka obiektowego, któremu zaprzeczam,
przez niezanegowanie od razu obiektu centralnego.

>> Wszystko inne trzeba robić przez definiowanie nowych obiektów,
>> które reprezentują relacje młotka z innymi obiektami albo wciskać do
>> tych obiektów metody obsługujące takie relacje - raz do jednego, raz do
>> drugiego.
> No właśnie to jest łamanie zasad OOP moim zdaniem bo te relacje powinny być 
> robione za pomocą zdarzeń (lub innej wymyślonej komunikacji). Ja zazwyczaj 
> robię tak że tworze coś na wzór komunikatów z windowsa i jeśli jeden obiekt 
> chce się skomunikować z drugim to musi zrobić to poprzez tą kolejke 
> komunikatów. Inaczej mówiąc obiekt nie rozkazuje zrobić czegoś konkretnemu 
> obiektowi, a tylko wysyła informację o tym że przemieścił się np. o jeden 
> centrymetr w prawo. Przy okazji wszystkie obiekty są podbięte do tej kolejki 
> komunikatów i nasłuchują czy przypadkiem nie powinny zareagować na jakiś 
> komunikat.
Zdarzenia są już wyborem danego modelu w programowaniu niezależnie od
użytego języka programowania. No chyba że mówimy o nich w tym sensie,
że zdarzeniami są obiektami i jak te obiekty-zdarzenia wyglądają.
Jeśli pominąć to, że zdarzenia są niezależne od rodzaju
programowania, to powstaje kolejna niewadoma: czas obsługi zdarzenia.
Trzeba tutaj coś założyć albo na bazie konkretnego środowiska języka
obiektowego, albo przy użyciu... (aż, no zapomniałem) :DDD Nie ważne.
W każdym razie czas nie znajduje się w ścisłej kategorii
„programowanie obiektowe”, lecz jest używany w programowaniu
obiektowym na wyższym poziomie abstrakcji niż samo programowanie
obiektowe. (Ciekawe czy ktokolwiek to zrozumie, ale ja wiem, o co chodzi.)
Można nie używać czasu, a dalej programowanie będzie obiektowe.
Czyli nie wiadomo, kiedy zdarzenie zostanie obsłużone, ale można
wymusić kolejność zdarzeń - kolejność obiektów wzbudzanych zdarzeniami.
Czyli potrzebna jest synchronizacja, a synchronizacja sprowadza się do
sekcji krytycznych. I ostatecznie wygląda na to, że faktem jest tylko
pakowanie zdarzenia w obiekty, ponieważ wystarczyłaby centralna
procedura obsługująca i dysponująca zdarzeniami, która decydowałaby o
wzbudzaniu konkretnych obiektów.
Moża ja czegoś nie widzę dobrze, ale wygloda to na programowanie
zdarzeniowe na wyższym poziomie abstrakcji przy użyciu programowania
obiektowego na niższym poziomie abstrakcji. A jeśli tak, to to byłby
inny temat dyskusji.
Jeśli natomiast zdarzenia są obiektami, to tym samym w takim
obiekcie-zdarzeniu trzeba zapisać, co ma robić gdy jest wzbudzany przez
określony obiekt. Czyli musiałby wiedzieć o innych obiektach już
wcześniej.
Myślę, że ostatecznie całość sprowadza się do zewnętrznego modelu
(dokumentacja projektu), który opisuje prawdziwe relacje, mające
zachodzić w programie. I tutaj ja uważam, że programowanie obiektowe
jest po to, by opisywać te relacje, ale nie jest w stanie sobie z tym
poradzić, ponieważ taki opis tworzy zbyt wiele komplikacji względem
tego, co w zamian daje. To jeśli chodzi o programy kompilowane.

-- 
 qo   |)      > >>>>>>>> news:5af6.00001481.43561f30@newsgate.onet.pl...
    _x/ ,     błąd krytyczny: zabrakło wewnętrznie złamanych linii cytowania
    |    ng  __ -- __ -- __ -- __ -- __ -- __ -- __ -- __,
,__ -- __ -- news:5af6.000015c5.43567f13@newsgate.onet.pl

Uhmm :)