W dniu środa, 19 lutego 2014 07:57:12 UTC+1 użytkownik toslaw napisał:
> firr <p...@g...com>:
>
> > troche glupawe te przyklady (troche to malo
>
> > powiedziane)
>
>
>
> Jaka rozmowa, takie przykłady. Dla mnie oczywistą oczywistością jest fakt, że z OOP
nie miałeś większej styczności niż być może w szkole. Niestety przesadą jest
powiedzieć, że w szkole uczą programowania, nie wspominając już o tym, że praca
programisty to 10% programowania, 90% utrzymywania ;).
>

wydaje mi sie ze mozliwosci scislej przedmiotowej i konkretnej rozmowy sie tu mw
wyczerpaly a w gadanie na poziomie bajek o pikselach i prostokatach i 11 klientach z
kapadocji jest troche nie dla mnie

rozumiem tez ze nie jestes nieststy rzecznikiem
opu tak ze nie umialbys odpowiedziec na moja pytania
ktore ew komus kto by za takiegop rzecznika mogl robic moglbym jeszcze zadac, a
brzmialyby one tak:

jak rozumiem sensem tego sposobu pisania jest
wytworzenie w programie siatki obiektów które
wzajemnie widza sie poprzez poustawiane jako swoje pola referencje, TAK CZY NIE?

jezeli nie to o co chodzi jesli nie o to a jezeli tak, to jak rzecznik opu
ustosunkowywuje sie do tego
ze oprócz takiego wypracowanego w koncu grafu
objektów (który moglbym zrozumiec) w takim oopie
funkcjonuje (chyba na zasadzie wysypiska na smieci)
drugi poziom gdzie dane obiekty nie sa zawieszone w
czystej prózni ale poosadzane w roznych zakamarkach kodu i jeszcze do tego ich setup
i konfiguracja
jest tez nieczysto uwikłany w cały code-flow

innymi slowy czy ta zewnetrzna warstwa opu stanwi
dla wyznawcow opu jakas atrakcje sama w sobie
(gdzie upatruja jakichs mozliwosci robienia czegos
ciekawego) czy jest tylko odrzutem potrzebnym do ustawienia grafu obiektów?

moze zapytam o to na innym forum - choc nie interesuje mnie to szczerze mowiac za
bardzo
jako ze to nie jest moja działka, moglbym sie
dowiadywac tylko z ciekawosci jak ci zwolennicy opu
to widzą

albo moze uzytkownik gode by umial na to odpowiedziec? (o ile uzywa opu bo juz
nie pamietam) - jesli rozumie co mam na mysli
piszac o wewnetrznej i zewnetrznej stronie opu


FiRR





>
>
> Zastanawiam się też, czy twoje przekonania wynikają z doświadczenia, czy z
dywagacji.
>
>
>
> > Nie wiem czy mam cos istotnego do dodania pozatym
>
> > co powiedziane - jesli chodzi o wlasnie utrzymywanie programu to własnie (jak
ktos w tym watku zwrocil uwage) obawiam sie ze ta 'pasożytnicza struktura' setupu
roznych obiektów i ich konfiguracji raczej pogarsza sprawe niz ja polepszac (*)
>
>
>
> Do zarządzania strukturą zależności obiektów i ich "setupu", jak to nazywasz, służą
inne techniki, np. dependency injection.
>
>
>
> > z punktu widzenia obiektu ktory ma jako pola
>
> > referencje do innych obiektow to jeszcze moze nie jest takie złe, ale ten 'setup
i konfiguracja'
>
> > i utrzymywanie tego to raczej koszmar (pisze 'raczej 'bo naprawde dawno nie
grzebalem w obiektowym programie i o tyle nie kojarze na ile uciezliwe to by dla mnie
obecnie było, czy bardzo czy moze tylko pierwiastek z bardzo ) <i to chybabyloby
wszystko na ten temat>
>
>
>
> W skrócie: "w sumie to nie wiem, ale nie przeszkadza mi to mieć bardzo jasny pogląd
na ten temat" :)
>
>
>
> > (*) tymbardziej ze system modulowy dziala po prostu swietnie, choc w c dobrze
bybylo go poprawic
>
>
>
> Różne problemy wymagają użycia różnych narzędzi. Z kolei dla człowieka, który ma
tylko młotek, każdy problem wygląda jak gwóźdź ;)
>
>
>
> Ale w jednym masz rację: to chyba wszystko na ten temat ;)