A. L. wrote:

> On Wed, 13 Apr 2011 00:08:15 -0700 (PDT), Mariusz Marszałkowski
> <m...@g...com> wrote:
>>
>>Dobrze powiedziane. Z tym ze "cos" to chyba zawsze techniki
>>obiektowe wnasza? Chocby szybsze odszukanie fragmentu kodu
>>do poprawki po dlugiej przerwie?
>>Pozdrawiam
>>
>
> Niekoniecznie. Prosze sobie wyobrazic aplikacja ktora ma 2 tysiace
> klas. Czy obiektowosc "ulatwia odnaleznienie kodu" raczej watpie.
> Uklul sie termin "spaghetti objects". Przedtem tzrena zrozumiec te 2
> tysiace klas - co one robie i jak ze soba wspolpracuja, zarowno
> statycznie jak i dynamicznie.
>

Zgadza sie, tyle ze to nie jest przypadlosc systemow OO - kazdy duzy system
jest trudny do ogarniecia niezaleznie od paradygmatu uzytego do jego budowy.

> Proponuje sie zastanowic skad sie wzial model obiektowy: wzial sie w
> jezyku Simula 67 ktory byl (mimo ze uniwersalny) przede wszystkm
> przeznaczony do SYMULACJI, a wiec strukturalnego odwzorowania
> rzecywiscosci w postaci programistycznych obiektow, oraz z metodologii
> "frames" w AI, gdzie motywacja byla podobna. I dzisiaj model
> obiektowy sprawdza sie doskonale gdy tzreba miec w komputerze
> odwzorowana sytuacje rzeczywiscta, a wiec wszelkiego rodzalu
> modelowaniu procesow, optymalizacji itede.
>
> Tym niemniej sa sytuacje gdy model obiektowy poasuje jak przyslowiowy
> "garbaty do sciany" - znajomy czlowiek stracil duzo czasu usilujac
> "obiektowo" napisac biblioteke do analizy sygnalow przy pomocy
> "wavelets" ("falek" po naszemu), skonczylo sie to wielkim wyrzucaniem
> do smeici i powrotem do czystego C. Nawet nie C++.
>
> Podwumowujac, obiektowosc to nie "silver bullet" ani kamien
> filozoficzny ale jedno z narzedzi w "toolboksie". Tzreba go uzywac
> wteny gdy sie nadaje, a nie uzywac jak sie nie nadaje. Podobnie jak
> budowniczy wie kiedy uzyc wietrarki a kiedy mlotka. Wiertarka, mimo ze
> bardziej elegancka niz mlotek, slabo nadaje sie do wbijania gwozdzi.
>

Wszystko to prawda, mysle jednak, ze trzeba wziac pod uwage jeszcze jeden
aspekt przy wyborze paradygmatu.
OO jest obok podejscia proceduralnego jedynym (?) paradygmatem, ktory
dorobil sie ogolnie znanych metodyk obejmujacych _pelny_ cykl zycia systemu.
Stad jego "oczywisty" wybor. Nie deprecjonujac innych paradygmatow - nie
spotkalem sie z odpowiednikiem np. metody Shlaer-Mellor (xtUML) lub SADT dla
paradygmatu funkcyjnego czy tez "logic programming". A juz tym bardziej
brakuje takich, ktore integrowalyby wiele paradygmatow w jedena spojna
calosc.
Jest nawet gorzej - nie istnieja nawet (w kazdym razie nie ogolnie
przyjete/znane) notacje graficzne pozwalajace opisywac systemy tworzone w
paradygmacie funkcyjnym czy logicznym (takie jak np. DFD, czy UML - przy
wszystkich wadach UMLa).

Dopoki takie metodyki, notacje i narzedzia sie nie pojawia inne paradygmaty
pozostana czysto akademickie lub moga stanowic jakies (inna sprawa - jakie)
uzupelnienie OO.

--
Michal