moge ew dodac jeszcze pytanie pomocnicze,

od jakiegos czasu zaczalem podejrzewac (powiedzmy na 80% powaznie) ze sasada
designowa oopu dla wielu
przynajmniej ludzi brzmi "podziel i poopakowywuj kod w klasy po czym zrób zeby to
jakos działało"

ten omawiany przyklad moglby na przyklad pod to podchodzic

- czy jest to prawda czy jednak są tu jakies dodatkowe ale konkretne 'wytyczne'
(zasady jak ma to wygladac a jak nie) (*) (i czy sa to bardziej calosciowe zasady
'pozytywne' tj mowiace jak ma to wygladac, czy raczej czesciowe zasady 'negatywne'
mowiaca tylko czego nie robic, czy tez wogole nie ma zasad i jet to 'wolna
amerykanka' ? ;D


(*) JAKIE ?

do góry

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

co do tego to jest to nie na temat, ale w c tez tak jest, tj program w c sklada sie z
galezi i danym galeziom mozna przyporzadkowac dane (ktore tylko ta galaz moglaby
czytac - mozna zrobic np dane statyczne na jakims poziomie a pzoniej ciagac w dol jak
amazonke do tych podgalezi do ktorych trzeba (choc byloby to moze dosyc smieszne)) -
problem jest nawet nie w skutkach ubocznych które mozna wyeliminowac tylko moze w tym
ze te amazonki nie sa moze zbyt wygodne - tak naprawde wydaje sie ze np nie chodzi o
to by tylko jedna galaz operowala na danych ale o to by kazda galaz zostawiala je w
dobrze okreslonym 'zamknietym' stanie - z czym ja raczej nie mam problemu (byc moze
to wogole moglobybyc podlozem pewnego paradygmatu, skoro te paradygmaty kodowania juz
tak sie mnoża, paradygmatu fazowego, tj paradygmetu z zamknietymi fazami, a moze jest
to cos innego niz paradygmat ale to stoi w
jakims tam sensie u podnoza przyzwoitego programowania, podzial na zamkniete fazy

do góry

On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
wrote:

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

Nie. Komponentyzacja, modularyacja i obiektowosc to deko inne koncpty

A.L.

do góry

On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
wrote:

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

Sorry, nonsens.

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

Ze co?..

>
>Tak by wygladal mniej wiecej moj poglad na te kwestie.

Proponuje jescze arz przemyslec.

>Inna rzecz, ze programisci czy projektanci OOP stosuja
>rozne wynalazki, ktorych nigdy nie rozumialem,

No i wlasnei tu jest pogrzebany przyslowiowy pies. Proponuje
powstrzymac sie od komentowania rzeczy ktorych sie nei rozumie

A.L.

do góry

W dniu środa, 19 lutego 2014 16:10:55 UTC+1 użytkownik A. L. napisał:
> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
> wrote:
> >
> >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)
> >
>
> Sorry, nonsens.

http://pl.wikipedia.org/wiki/Nonsens

Proponowalbym zapoznanie sie ze znaczeniem slowa, ktorego
chce sie uzyc, zanim zacznie sie nim szafowac na prawo i lewo.
Sorry.

> >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.
> >
>
> Ze co?..

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H
-10.html#%_sec_1.1.5
oraz
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H
-19.html#%_chap_3

> >Tak by wygladal mniej wiecej moj poglad na te kwestie.
>
> Proponuje jescze arz przemyslec.

Szanowny Panie.
Jezeli ma Pan jakies konkretne zarzuty wzgledem tego,
co napisalem, to prosze je sformulowac. Gdyby zechcial mi
Pan dowiesc, ze w moich wypowiedziach znajduja sie jakies
logiczne sprzecznosci albo merytoryczne niescislosci,
to bylbym naprawde bardzo szczesliwy, gdyby zdolal je Pan
wypunktowac. Jezeli jednak chce Pan uparcie utrzymywac,
ze to, co pisze, to jest "kompletna bzdura", nie podajac
przy tym zadnych uzasadnien, to prosze Pana laskawie o to,
zeby dodal mnie Pan do swojego "KF" czy jak to Pan nazywa,
poniewaz wszelka moja dotychczasowa dyskusja z Panem, pomimo
jak najlepszych checi z mojej strony, jest jedna z najbardziej
jalowych, w jakich kiedykolwiek mialem okazje uczestniczyc.

> >Inna rzecz, ze programisci czy projektanci OOP stosuja
> >rozne wynalazki, ktorych nigdy nie rozumialem,
>
> No i wlasnei tu jest pogrzebany przyslowiowy pies. Proponuje
> powstrzymac sie od komentowania rzeczy ktorych sie nei rozumie

Zostalem zapytany, wiec udzielilem odpowiedzi.
Jezeli z czyms sie Pan nie zgadza, to prosze powiedziec,
z czym konkretnie, a moze wowczas uda sie nam jakos dojsc
do porozumienia. Niestety nie jestem tak genialny jak Pan
i nie mam bezposredniego wgladu w istote rzeczy, w zwiazku
z czym musze sie w swoim poznaniu poslugiwac takimi (zapewne
Panu obcymi, z tego przynajmniej, co zdazylem zauwazyc)
ulomnymi technikami, jak rozumowanie czy argumentacja.

do góry

On Wed, 19 Feb 2014 09:26:38 -0800 (PST), g...@g...com
wrote:

>Zostalem zapytany, wiec udzielilem odpowiedzi.
>Jezeli z czyms sie Pan nie zgadza, to prosze powiedziec,
>z czym konkretnie, a moze wowczas uda sie nam jakos dojsc
>do porozumienia. Niestety nie jestem tak genialny jak Pan
>i nie mam bezposredniego wgladu w istote rzeczy, w zwiazku
>z czym musze sie w swoim poznaniu poslugiwac takimi (zapewne
>Panu obcymi, z tego przynajmniej, co zdazylem zauwazyc)
>ulomnymi technikami, jak rozumowanie czy argumentacja.

rzeczywiscie, powstrzymam sie od komentowania. Zzajeloby mi zbyt duzo
czasu ktorego nei mam.

Proponuje wyjsc poza SICP i poczytac wiecej. N poczatek Clemensa
Szyperskiego, na przykald

http://research.microsoft.com/en-us/um/people/cszype
rs/pub/ecoop92.pdf

czy tez jego ksiazke na temat komponentyzacji i obiektow.

SICP jest dsyc zlezala i trudnia ja dzis traktwoac jako solidne
zrodlo. Zreszta, fragmenty ktore Pan cytowal niespecjalnie maja sie do
tego co Pan napisal.


A.L.

do góry

On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
wrote:

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

Zarowno hermetyzacja jai i polimorfizm nic nie maja ze soba wspolnego
ani nic nie maja wspolnego z obiektowoscia. Owszem, sa w jezykach OO
uzywane, ale powstaly zupelnie neizaleznie

"Hermetyzacja" ustala reguly dostepu do zmiennych i procedur. Istnieje
od dosyc dawna; w pelni uzyta pierwszy raz w jezyku Modula-2 Wirtha.
Jezyk definiowal "moduly" i reguly dostepu do nich. Pdobnai Ada
definiwala "packages" - pakiety, i reguly dostepu do nich. Bylo to na
dlugo pzred OO

Polimorfizm mowi z grubsza o operacjach ktore moba byc zaaplikowane do
zmiennych roznych typow, przy czym wlasciwa implementacja wybierana
jest automatycznie, stosownie do tych typow.

Operacja + w jezyku takim jak Pascal jest polimorficzna, bo dodawac
moze zmienne roznych typow, a procedura dodawania bedzie wybrana
wlasciwie.

Polimorfizm to rozneiz generics w Javie i templates w C++. Taki
polimorfizm nazywa sie "polimorfizmem parametrycznym"

W OO polimorfizm jest taki jak polimorfizm + w Pascalu: metoda moze
byc deklarowana wielokrotnie w ciagu klas tworzacych ciag
dziedziczenia; implementacja bedzie wybierana stosownei do
dynamicznego typu obiektu

Polimorfizm nic nie mowi o "zastepowaniu klas".

Tak na marginesie, interfejs nei okrecla calkowicie zachowanai modulu;
moduly o identycznych interfejsach nie musza byc identyczne

A.L.

do góry

On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
wrote:

>Wydaje mi sie, ze jezeli chce sie stworzyc system bazujacy
>na jakiejs persystencji, to stosowanie analizy obiektowej
>jest jak najlepszym pomyslem.

Persystencja (persistency) to zdolnosc do zachowanai stanu obiektu
dluzej niz czas zycia obiektu. Generalnie, przez persistency rozumie
zsie zdolnosc zachowanai stanu obiektu na mozniku zewnetrznym (baza
danych).

Obiekty neispecjalnie dobzre realizujaten koncept - wymagaja
serializacji oarz pzreksztalcenia do rozmatu dododnego dla bazy danych
(relacyjnego). Model obiektowy i relacyjny nei bardzo do siebie
pasuja, i realizacja "persistency" najezona jest trudnosciami. OO
wcale nie jest do tego najlepsze

A.L.

do góry

On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
wrote:

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

Szczegolnie dobrze sie ten postulat realizuje gdy w grupie jest 20
programistow a system ma 5 milionow linii kodu

A.L.

do góry

A.L <a...@a...com>:
> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
> wrote:
>
> >Wydaje mi sie, ze jezeli chce sie stworzyc system bazujacy
> >na jakiejs persystencji, to stosowanie analizy obiektowej
> >jest jak najlepszym pomyslem.
>
> [...]
> Obiekty neispecjalnie dobzre realizujaten koncept - wymagaja
> serializacji oarz pzreksztalcenia do rozmatu dododnego dla bazy danych
> (relacyjnego). Model obiektowy i relacyjny nei bardzo do siebie
> pasuja, i realizacja "persistency" najezona jest trudnosciami. OO
> wcale nie jest do tego najlepsze

Tak zapytam z ciekawości, jaki jest najlepszy (najwygodniejszy?) sposób na
zachowywanie obiektów w nośniku stałym (plik, baza danych, etc)?

Konkretnie pytam o technikę `serializacji' klasy, aby jej stan móc zrzucić, a
potem przywrócić w późniejszym czasie, który uważany jest za `najbardziej
poprawny', i jeśli OO nie jest do tego najlepsze, to co jest?

(nie sugeruję, że uważam, że OO jest do tego najlepsze)

do góry