W dniu 2011-04-14 09:48, Paweł Kierski pisze:

>
> Techniki obiektowe też są tylko narzędziem. Celem jest zwykle taka
> struktura, która jest czytelna, podatna na modyfikacje, a jednocześnie
> stabilna jeśli chodzi o sposób współpracy między elementami. Na pewno
> warto spisywać i stosować reguły, dzięki którym ten cel będzie prostszy
> do osiągnięcia.
>

Podobnie patrze na OOP. Pojawilo sie, jest jakims etapem rozwoju, ale w
glebokim sensie realizuje starsze postulaty. Czytelnosc, izolacja i
separacja, konserowalnosc, nazewnictwo (w sensie samodokumentowanie
intencji programisty)

Czyli OOP to aż i tylko etap (istotny).

do góry

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

do góry

Wojciech Jaczewski wrote:

> A. L. wrote:
>
>> Qrde, to jakis nonsens z ta "forma" i "trescia". "Tresc" ma byc taka
>> ze program robi to co ma robic, "forma" ma byc taka za program ma sie
>> wykonywac szybko i niezawodnie, ma byc tak prosty jak sie da ale nie
>> prostszy, a tekst programu ma byc czytelny.
>
> Sprecyzuję, co ja rozumiem pod pojęciem "przerost formy nad treścią".
> Program napisany na wyczucie, bez zastosowania różnych "dobrych praktyk"
> można zapisać w X linii kodu. Ktoś jednak upiera się by zrobić to np.
> "obiektowo" i wychodzi mu 3*X linii. W takim kodzie nie widać, co się
> rzeczywiście dzieje, bo jego duża część to bezużyteczne wypełniacze.

Koncentrowanie sie na minimalizacji LoC jest bledem - sa tez inne
miary/wskazniki mowiace o jakosci/skomplikowaniu/podatnosci na modyfikacje
oprogramowania i bardzo czesto jest tak, ze LoC rzeczywiscie wzrosnie jesli
chcemy poprawic te inne.
Z drugiej strony rowniez jest tak, ze wraz ze wzrostem LoC (czyli rozmiaru
systemu) te - jak je nazywasz "bezuzyteczne wypelniacze" stanowia coraz
mniejsza czesc calosci, zas przynosza na tyle duzo korzysci, ze przestaja
byc "bezuzytecznymi wypelniaczami".

--
Michal

do góry

On Thu, 14 Apr 2011 09:48:32 +0200, Paweł Kierski<n...@p...net>
wrote:
> > No dobra, ale mówiliśmy o fundamentalnych sprawach
> > typu czy, kiedy i jak stosować techniki obiektowe.
>
> Techniki obiektowe też są tylko narzędziem.
> Celem jest zwykle taka
> struktura, która jest czytelna, podatna na modyfikacje, a
> jednocześnie stabilna jeśli chodzi o sposób współpracy
> między elementami. Na pewno warto spisywać
> i stosować reguły, dzięki którym ten cel będzie prostszy
> do osiągnięcia.

No dobra, ale nie chodzi o to, czy akurat OO jest najlepszym
rozwiązaniem na świecie, tylko że to jest przykład rzeczy, na którą
warto standardyzować. Tekst ze spacją po ifie był kompletnie non
sequitur.

do góry

> > Taka dość znana postać jak Linus Torvalds pewnie też jest samodzielnym
> > klepaczem, bo też da się znaleźć jego negatywne opinie na temat m.in.
> > programowania obiektowego.
>
> Najciekawsze jest to, ze spora czesc kernela jest jak najbardziej OO -
> wystarczy chociazby popatrzec na VFS. Tyle ze to OO - ze tak powiem -
> "dziergane recznie" - bez wsparcia jezyka.

Ciekawe czy tak rzeczywiscie jest bo nie wydaje mi sie specjalnie
prawdopodobne by ktos kto pisze w c akurat chcialby nasladowac w 'OO'

Jak to niby mialoby wygladac (wyglada w linuksie) - 'pączkowane' mallokami
kawalki ramu (obiekty) z masa wskaznikow oddajacych 'obiektowa siatke' ?

- Wydaje mi sie to malo prwdopodobne i tym samym powatpiewam by mozna
powiedziec ze 'spora czesc kernela jest "jak najbardziej OO"'









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

do góry

On Thu, 14 Apr 2011 11:01:42 +0200, Michal Kleczek <k...@g...com>
wrote:

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

Niestety, Kolega nie ma racji: istnieja tylko Kolega ich nei zna bo
zostaly zapomniane

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

Szkoda ze Kolega nie pamieta czasow gdy programowanie strukturalne
bylo taka sensacja jak pozniej programowanie obiektowe. Dorobiono sie
wyedy wielu metodyk, zarowno projektowania jak i utrzymania kodu i to
w "pelnym cyklu".

Niestety, wszystko to zostalo wraz z OO zapomniane, bo OO bylo
"lepsze"

A.L.

do góry

p...@p...onet.pl wrote:

>
>> > Taka dość znana postać jak Linus Torvalds pewnie też jest samodzielnym
>> > klepaczem, bo też da się znaleźć jego negatywne opinie na temat m.in.
>> > programowania obiektowego.
>>
>> Najciekawsze jest to, ze spora czesc kernela jest jak najbardziej OO -
>> wystarczy chociazby popatrzec na VFS. Tyle ze to OO - ze tak powiem -
>> "dziergane recznie" - bez wsparcia jezyka.
>
> Ciekawe czy tak rzeczywiscie jest bo nie wydaje mi sie specjalnie
> prawdopodobne by ktos kto pisze w c akurat chcialby nasladowac w 'OO'
>

A to niespodzianka cie spotkala...

> Jak to niby mialoby wygladac (wyglada w linuksie) - 'pączkowane' mallokami
> kawalki ramu (obiekty) z masa wskaznikow oddajacych 'obiektowa siatke' ?

Ze co?

>
> - Wydaje mi sie to malo prwdopodobne i tym samym powatpiewam by mozna
> powiedziec ze 'spora czesc kernela jest "jak najbardziej OO"'
>

Widziales kiedys (Linux) kernel? Czy tez nawet "kernel jadl ci z reki"?
Polecam:
http://lmgtfy.com/?q=linux+kernel+vfs

--
Michal

do góry

A. L. wrote:

> On Thu, 14 Apr 2011 11:01:42 +0200, Michal Kleczek <k...@g...com>
> wrote:
>
>>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).
>>
>
> Niestety, Kolega nie ma racji: istnieja tylko Kolega ich nei zna bo
> zostaly zapomniane

Bardzo chetnie sie zapoznam. Mozna prosic o jakies namiary?

>
>>Dopoki takie metodyki, notacje i narzedzia sie nie pojawia inne
>>paradygmaty pozostana czysto akademickie lub moga stanowic jakies (inna
>>sprawa - jakie) uzupelnienie OO.
>
> Szkoda ze Kolega nie pamieta czasow gdy programowanie strukturalne
> bylo taka sensacja jak pozniej programowanie obiektowe. Dorobiono sie
> wyedy wielu metodyk, zarowno projektowania jak i utrzymania kodu i to
> w "pelnym cyklu".

Jak pisalem - chodzilo mi o metodyki dla paradygmatow innych niz
proceduralny i obiektowy (czyli np. funkcyjny).

>
> Niestety, wszystko to zostalo wraz z OO zapomniane, bo OO bylo
> "lepsze"

Czyli OO bylo/jest lepsze z definicji :)

--
Michal

do góry

> >> Najciekawsze jest to, ze spora czesc kernela jest jak najbardziej OO -
> >> wystarczy chociazby popatrzec na VFS. Tyle ze to OO - ze tak powiem -
> >> "dziergane recznie" - bez wsparcia jezyka.
> >
> > Ciekawe czy tak rzeczywiscie jest bo nie wydaje mi sie specjalnie
> > prawdopodobne by ktos kto pisze w c akurat chcialby nasladowac w 'OO'
> >
>
> A to niespodzianka cie spotkala...
>
> > Jak to niby mialoby wygladac (wyglada w linuksie) - 'pączkowane' mallokami
> > kawalki ramu (obiekty) z masa wskaznikow oddajacych 'obiektowa siatke' ?
>
> Ze co?
>
> >
> >  - Wydaje mi sie to malo prwdopodobne i tym samym powatpiewam by mozna
> > powiedziec ze 'spora czesc kernela jest "jak najbardziej OO"'
> >
>
> Widziales kiedys (Linux) kernel? Czy tez nawet "kernel jadl ci z reki"?
> Polecam:
> http://lmgtfy.com/?q=linux+kernel+vfs
>

nie mam czasu ani checi na zapoznawanie sie kernelem linuksa - skoro wiesz
o czym mowisz to moze opowiesz jak to programisci c dziargaja "o o" w linux
kernel i VFS - bo jak mowie wydaje mi sie to malo prawdopodobne [by komus w c
chacilo sie odtwarzac obiektowopodobna 'siatke' a zwlaszcza porzadki 'kreacji'
obiektow jak w 'o o']




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

do góry

W dniu 2011-04-14 15:50, kenobi pisze:
[...]
>> Widziales kiedys (Linux) kernel? Czy tez nawet "kernel jadl ci z reki"?
>> Polecam:
>> http://lmgtfy.com/?q=linux+kernel+vfs
>>
>
> nie mam czasu ani checi na zapoznawanie sie kernelem linuksa - skoro wiesz
> o czym mowisz to moze opowiesz jak to programisci c dziargaja "o o" w linux
> kernel i VFS - bo jak mowie wydaje mi sie to malo prawdopodobne [by komus w c
> chacilo sie odtwarzac obiektowopodobna 'siatke' a zwlaszcza porzadki 'kreacji'
> obiektow jak w 'o o']

Mylisz OO z implementacją w C++.

Nie musisz studiować całego kernela. Gdybyś ze zrozumieniem objerzał
np. sqlite'a, to wiedziałbyś o co chodzi. Żebyś się nie męczył
z szukaniem - interfejs systemu plików w sqlite:
http://www.sqlite.org/c3ref/vfs.html

Analogiczne rozwiązanie masz w openssl'u:
http://www.openssl.org/docs/crypto/bio.html - tu są nawet użyte wzorce
projektowe (do dyskusji, czy Chain of Responsibility, czy Decorator,
ale to już szczegóły).

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

do góry