W dniu wtorek, 18 lutego 2014 16:01:08 UTC+1 użytkownik firr napisał:
> najdziwniejszy wydaje mi sie tu ten kawałek z mouse handlerem - objekt ktory
dodajesz do objektu okna (by w nim samym ustawic wybrana metode z obiektu game)
>
>
>
> czy tak sie normalnie robi? (w .netcie czy gdzies ?)
>
>
>
> pozniej mam pare innych uwag co do tego przykładu


no dobra, z dalszych uwag co do tego przykładu

mamy 4 glowne obiekty tj game, blitter, pixelbuffer i window (mamy tez obiekt handler
ale on jest powiedzialbym usługowy nieco jednak komplikuje
obraz) - mamy tez 5 element funkcje main

tworzysz obiekt Game i dodajesz do niego pozostale 3 obiekty tj pixelbuffer, blitter
i window

(jest to faktycznie dosyc charakterystyczny dla mnie
styl obiektowy, o tyle jest to calkiem dobry przyklad, charakterystyczny jest ten
setup obiektów i to konfigurowanie ich połaczeń

1) mozesz powiedziec moze (albo ktos inny kto uzywa opu) czemu pixelbuffer
przekazujesz w konstruktorze a pozostale metodami ?

2) mozesz powiedziec czemu 'osadzenie' tych obiektów i ich konfigurowanie jest w tych
miejscach w ktorych ono jest?

dla przykladu czy nie lepiej osadzic pixelbufora
blittera i window od razu w Game, lub jeszcze
inaczej na przyklad window w game a pixelbufor w
window z kolei blitter w pixelbufor lub jeszcze inaczej? Co o tym decyduje?

do góry

> dla przykladu czy nie lepiej osadzic pixelbufora
> blittera i window od razu w Game, lub jeszcze
> inaczej na przyklad window w game a pixelbufor w
> window z kolei blitter w pixelbufor lub jeszcze inaczej? Co o tym decyduje?

w systemie modułowym cały ten 'setup' i 'konfiguracja'
wzajemnej widzialnosci miedzy tymi obiektami ktora tutaj jest wypączkowywana w
runtime (dla mnie brzydka i ograniczona, choc jestem chetny uslyszec jak ktos chce
tego braonic) jest po prostu statycznie dany w bardzo ładnej i czystej formie w
systemie modułowym , gdzie u mnie wygladołoby to mw tak (nie mialbym modulu game ale
zamiast niego moduł
ramka, kod updatujacy i rysujacy dana ramke

///// pixelbuffor.c /////////

// references nothing

void Resize(int x, int y) { /***/}
void DrawLine(int, int, int, int, int color) { /***/ }
void SetPixel(int , int, int color ) { /***/}

/// blitter.c ///////////

// references pixelbuffor

void Blit() { /***/ }

//// window.c ///////

// references blitter and frame

void winmain()
{
/* this */ SteupWindow();

for()
{
/* this */ DispatchMessages();
/* frame */ RunFrame();
/* blitter */ Blit();
}
}

//// frame.c /////////

// references pixelbufor

void RunFrame()
{

DrawLine( /***/);
}

/////////////////

do góry

firr <p...@g...com>:
> > dla przykladu czy nie lepiej osadzic pixelbufora
> > blittera i window od razu w Game, lub jeszcze
> > inaczej na przyklad window w game a pixelbufor w
> > window z kolei blitter w pixelbufor lub jeszcze inaczej? Co o tym decyduje?
> w systemie modułowym cały ten 'setup' i 'konfiguracja' wzajemnej
> widzialnosci miedzy tymi obiektami ktora tutaj jest wypączkowywana w runtime
> (dla mnie brzydka i ograniczona, choc jestem chetny uslyszec jak ktos chce
> tego braonic) jest po prostu statycznie dany w bardzo ładnej i czystej
> formie w systemie modułowym , gdzie u mnie wygladołoby to mw tak (nie
> mialbym modulu game ale zamiast niego moduł ramka, kod updatujacy i rysujacy
> dana ramke
[bzzz]

Aby zrozumieć, że OOP nie ogranicza w żaden sposób programowania, może
powinieneś wyobrazić sobie nie sam akt pisania programu, ale jego przyszły
rozwój.

To znaczy: napisałeś program, który w 100% wypełnia zachcianki klienta, czyli
rysuje piksel na ekranie. Potem natomiast przychodzi drugi klient, i zamawia u
ciebie program, który rysuje nie piksel, ale prostokąt. Teraz, aby nie kopiować
projektu A do katalogu B, i nie posiadać dwóch wersji dość podobnego kodu
źródłowego, mógłbyś kombinować tak, żeby tylko dopisać do kodu A funkcję
rysowania prostokątów, ale tak, aby funkcja rysowania pikseli nie została
usunięta. Czyli, aby program był w stanie rysować i piksele i prostokąty, ale
nie obydwa na raz.

Twój kod modułowy może osiągnąć to np. tak:

1) W funkcji rysującej piksel możesz dodać warunek:

if(pierwszyKlient) { rysujPiksel(); } else { rysujProstokąt(); }

Jednak, gdy przyjdzie trzeci klient, i zechce program, który blituje od tyłu do
przodu, a nie tak, jak pierwszych dwóch klientów, od przodu do tyłu, sytuacja
może się skomplikować (szczególnie jak przyjdzie kolejnych 10 klientów z
kolejnymi zachciankami).

2) Możesz wyrzucić funkcję rysującą do oddzielnego pliku cpp, dopisać nowy plik
cpp, który implementuje tą samą funkcję, ale zamiast piksela rysuje prostokąt.

Jednak, gdy przyjdzie klient, który zechce, by na ekranie został narysowany
prostokąt, a na nim piksel, nie będziesz mógł wykorzystać obu plików cpp
jednocześnie. Będziesz zmuszony stworzyć trzeci plik, który rysuje prostokąt i
piksel, będzie on jednak powielał kod i z pierwszego pliku cpp, i z drugiego.

3) Masz jakiś inny pomysł? ;)

Mój kod obiektowy wymaga stworzenia nowego interfejsu logiki rysowania i dwóch
klas:

class RysujPiksel: public LogikaRysowania { };

class RysujProstokąt: public LogikaRysowania { };

Sama funkcja rysująca wykorzystuje klasę LogikaRysowania, więc automatycznie
akceptuje wszystkie klasy, które ją dziedziczą. Wybór, która klasa ma zostać
użyta, może być dokonany podczas działania programu. Może być to jedna klasa,
albo obie i nie trzeba wybierać, które pliki skompilować, a których nie ;)

do góry

W dniu wtorek, 18 lutego 2014 20:40:49 UTC+1 użytkownik toslaw napisał:
> firr <p...@g...com>:
>
> > > dla przykladu czy nie lepiej osadzic pixelbufora
>
> > > blittera i window od razu w Game, lub jeszcze
>
> > > inaczej na przyklad window w game a pixelbufor w
>
> > > window z kolei blitter w pixelbufor lub jeszcze inaczej? Co o tym decyduje?
>
> > w systemie modułowym cały ten 'setup' i 'konfiguracja' wzajemnej
>
> > widzialnosci miedzy tymi obiektami ktora tutaj jest wypączkowywana w runtime
>
> > (dla mnie brzydka i ograniczona, choc jestem chetny uslyszec jak ktos chce
>
> > tego braonic) jest po prostu statycznie dany w bardzo ładnej i czystej
>
> > formie w systemie modułowym , gdzie u mnie wygladołoby to mw tak (nie
>
> > mialbym modulu game ale zamiast niego moduł ramka, kod updatujacy i rysujacy
>
> > dana ramke
>
> [bzzz]
>
>
>
> Aby zrozumieć, że OOP nie ogranicza w żaden sposób programowania, może
>
> powinieneś wyobrazić sobie nie sam akt pisania programu, ale jego przyszły
>
> rozwój.
>
>
>
> To znaczy: napisałeś program, który w 100% wypełnia zachcianki klienta, czyli
>
> rysuje piksel na ekranie. Potem natomiast przychodzi drugi klient, i zamawia u
>
> ciebie program, który rysuje nie piksel, ale prostokąt. Teraz, aby nie kopiować
>
> projektu A do katalogu B, i nie posiadać dwóch wersji dość podobnego kodu
>
> źródłowego, mógłbyś kombinować tak, żeby tylko dopisać do kodu A funkcję
>
> rysowania prostokątów, ale tak, aby funkcja rysowania pikseli nie została
>
> usunięta. Czyli, aby program był w stanie rysować i piksele i prostokąty, ale
>
> nie obydwa na raz.
>
>
>
> Twój kod modułowy może osiągnąć to np. tak:
>
>
>
> 1) W funkcji rysującej piksel możesz dodać warunek:
>
>
>
> if(pierwszyKlient) { rysujPiksel(); } else { rysujProstokąt(); }
>
>
>
> Jednak, gdy przyjdzie trzeci klient, i zechce program, który blituje od tyłu do
>
> przodu, a nie tak, jak pierwszych dwóch klientów, od przodu do tyłu, sytuacja
>
> może się skomplikować (szczególnie jak przyjdzie kolejnych 10 klientów z
>
> kolejnymi zachciankami).
>
>
>
> 2) Możesz wyrzucić funkcję rysującą do oddzielnego pliku cpp, dopisać nowy plik
>
> cpp, który implementuje tą samą funkcję, ale zamiast piksela rysuje prostokąt.
>
>
>
> Jednak, gdy przyjdzie klient, który zechce, by na ekranie został narysowany
>
> prostokąt, a na nim piksel, nie będziesz mógł wykorzystać obu plików cpp
>
> jednocześnie. Będziesz zmuszony stworzyć trzeci plik, który rysuje prostokąt i
>
> piksel, będzie on jednak powielał kod i z pierwszego pliku cpp, i z drugiego.
>
>
>
> 3) Masz jakiś inny pomysł? ;)
>
>
>
> Mój kod obiektowy wymaga stworzenia nowego interfejsu logiki rysowania i dwóch
>
> klas:
>
>
>
> class RysujPiksel: public LogikaRysowania { };
>
>
>
> class RysujProstokąt: public LogikaRysowania { };
>
>
>
> Sama funkcja rysująca wykorzystuje klasę LogikaRysowania, więc automatycznie
>
> akceptuje wszystkie klasy, które ją dziedziczą. Wybór, która klasa ma zostać
>
> użyta, może być dokonany podczas działania programu. Może być to jedna klasa,
>
> albo obie i nie trzeba wybierać, które pliki skompilować, a których nie ;)

troche glupawe te przyklady (troche to malo
powiedziane)

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 (*)

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>


(*) tymbardziej ze system modulowy dziala po prostu swietnie, choc w c dobrze bybylo
go poprawic

1) o typowanie symboli w binarnych modulach tak zeby nie trzebbylo pisac naglowków
funkcji

2) o slowo kluczowe jawnie wypisujace u gory modulu z jakimi innymi modulami go
linkowac (tak zeby linker nie linkowal wszystkiego z wszystkim i zeby byla tez
kontrola zabezpieczenie przed pomylkami
no i tez rodzaj komentarza itp)

3) o mozliwosc podania nazwy modulu przed funkcja tak zeby mozna bylo rozroznic w
razie konfliktów,
plut tez czasem mozna to wykorzystac jako rodzaj komentarza

( (4) ... mozliwe ze tez o inne daleko idace usprawnienia ale to juz rzecz z troche
innej paczki)

do góry

co do dziedziczenia z kolei to dla mnie dziedziczenie jest ortogonalnym zagadnieniem,
(w stosunku do tego tutaj), [dziedziczenie mozna by wbudowac nawet w basic
itp], paradygmatem w sumie (podchodzi bardziej pod pojecie programowania
generycznego, tj na ogólnikach), czy chcialbym cos z tego dzidziczenia wbudowac w c
to nie wiem /ale to jest inny temat, mala dygresja przy okazji/

do góry

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

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

do góry

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

do góry

>
> wydaje mi sie ze mozliwosci scislej przedmiotowej i konkretnej rozmowy sie tu mw
wyczerpaly

aczkolwiek przyklad (tj ten kod) był dobry, ciekawe czy (w ramach tego samego jezyka)
jacys inni ludzie
napisaliby to jakos inaczej - prawdopodobnie byloby to mw to samo (gdyby cos innego
to przydaloby sie tez zobaczyc, ale pewnie nie )

do góry

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

do góry

W dniu środa, 19 lutego 2014 10:58:35 UTC+1 użytkownik g...@g...com napisał:
> 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").

no dobra widze ze nie jestem rozumiany,
mi chodzilo o to by jakis jaki taki znawca opu
zrozumial to co nazywam wewnetrzna strona opu
(na ktora skladaja sie ciała obiektów polaczonych
wzajemnymi referencjami 'przez wskaznik')
(ta wewnetrzna strona opu przypomina troche system
modułowy) - i to co nazywam zewnetrzna strona opu
(czyli ten smutny fakt ze objektowa siatka
jest jeszcze jakos tam instancjonowana i konfigurowana - ale niewazne, zebym mogl tu
cos
pogadac to chyba musialbym miec wiecej konkretnych
przykladów programow napisanych w oop i popatrzec na
te architektury , moze kiedys popatrze, na razie nie
mam chyba specjalnej checi

do góry