W dniu środa, 19 lutego 2014 09:41:57 UTC+1 użytkownik firr napisał:
>
> 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

Nie jestem pewien, czy rozumiem. Ale wydaje mi sie, ze
celem OOP jest przede wszystkim podzial oprogramowania
na komponenty, z ktorych kazdy posiada okreslone
kompetencje. Ten podzial manifestuje sie zarowno w kodzie
zrodlowym (w jezykach wspierajacych obiekty poprzez
uzycie klas albo prototypow), jak i w samej analizie,
tj. sposobie myslenia o problemie.

W kontekscie OOP czesto mowi sie o "polimorfizmie",
"hermetyzacji (=enkapsulacji)" i "dziedziczeniu".

Zaczne od ostatniego pojecia, gdyz wydaje mi sie
najbardziej uzyteczne. Idzie o to, ze tak jak klasy
odpowiadaja pojeciom, a obiekty -- bytom, stwierdzenie
"X dziedziczy po Y" mozna rozumiec jako taksonomiczne
"X jest rodzajem Y". (W kontrascie do dziedziczenia
mowi sie tez o agregacji, gdy w definicji klasy
wystepuje pole majace przechowywac obiekt innej
klasy; taka sytuacja partonomicznemu "Y sklada sie
[m.in.] z X")

Moim zdaniem dobrze jest moc wyrazac te relacje w jezyku.

Jezeli idzie o pojecia hermetyzacji i polimorfizmu,
to sa one ze soba zwiazane. Hermetyzacja to idea, ze
szczegoly implementacyjne zwiazane z jakims zagadnieniem
ukrywa sie za publicznym, dobrze okreslonym interfejsem.
Polimorfizm zas, to taki pomysl, ze jezeli mamy rozne
klasy, ktore implementuja ten sam interfejs, to mozna
ich uzywac w takim samym kontekscie (sa ze soba zastepowalne
-- moze nie w sensie funkcjonalnosci, ale w sensie mozliwego
uzycia)

I co do tych kwestii, to mam juz nieco wiecej zastrzezen.
Po pierwsze, idea hermetyzacji moze byc odebrana jako
komunikat do programisty: "masz tylko zaimplementowac
taki-a-taki interfejs. Jezeli masz przy tym smietnik
w swoim kodzie, nie interesuje nas to". Czyli sama hermetyzacja
nie jest wytyczna dotyczaca tego, jak nalezy pisac kod.

Po drugie, czasem bywa tak, ze koniecznosc zastosowania
wymienionych tu mechanizmow obiektowych wynika stad, ze
tworca programu nie udostepnia swojego kodu zrodlowego.
W tej sytuacji, zeby dalo sie w ogole z systemem
wspolpracowac, rzeczywiscie podstawa sa dobrze zaprojektowane
interfejsy, ale w wielu wypadkach cena jest taka, ze
system jest duzo bardziej zlozony, niz moglby byc.
(A i tak zawsze bedzie mniej elastyczny niz wowczas,
gdy po prostu udostepni sie dobrze napisany kod zrodlowy
-- bo jego elastycznosc bedzie tylko tak duza, na ile
pozwolila wyobraznia jego tworcow)

Wydaje mi sie, ze jezeli chce sie stworzyc system bazujacy
na jakiejs persystencji, to stosowanie analizy obiektowej
jest jak najlepszym pomyslem. Jednak jezeli tylko mozna
unikac stanow mutowalnych (przypisan, zmiany wartosci
zmiennych -- you name it), to najlepiej pisac jak najwieksze
polacie systemu czysto funkcyjnie, bo taki kod jest duzo
prostszy w analizie, bo analizujac jego przebieg, nie trzeba
zapamietywac wartosci zmiennych.

(Mozna tez sie spotkac w srodowiskach funkcyjnych z bardziej
radykalnymi pomyslami. Programisci Haskella, a zdaje sie, ze
rowniez autorzy ksiazki o programowaniu gier w Rackecie
"How to design worlds" prezentuja takie podejscie, ze sercem
projektu gry powinna byc "czysta" funkcja, ktora pobiera biezacy
stan swiata + sterowanie, i zwraca nowy stan swiata. Ciekawy
wydaje sie tez pomysl "functional reactive programming", ale
przyznam, ze jeszcze w calosci go nie zglebilem)

Tak by wygladal mniej wiecej moj poglad na te kwestie.
Inna rzecz, ze programisci czy projektanci OOP stosuja
rozne wynalazki, ktorych nigdy nie rozumialem, albo ktore
wydawaly mi sie zawsze niepotrzebnym komplikowaniem prostych
rzeczy (jak np. schematy UML czy tzw. "wzorce projektowe").