A.L <a...@a...com>:
> On Thu, 20 Feb 2014 06:42:13 +0000 (UTC), toslaw <s...@n...4u.pl>
> wrote:
>
> >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)?
>
> Odpowiedz jest prosta: zaden. Wszystkie maja swoje problemy. Zalezy
> zreszta, do czego to jest potzrebne.

Więc po co twierdzić, że OOP się do tego nie nadaje, skoro żaden się nie nadaje?

Pominę zupełnie fakt, że 'żaden' to żadna odpowiedź. Niektóre rozwiązania mogą być
lepsze, niektóre gorsze. Pytam o najlepsze aktualnie dostępne, takie musi istnieć,
nawet gdyby było dostępne tylko jedno rozwiązanie.

> De facto standardem dla Javy jest Hibernate. Dosyc upierdliwy, ale
> dziala.
>
> >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)
>
> Pytanie jest sformulowane tak ze nie rozumiem,
>
> Java posiada interfejs Serializable ktory wlasnei sluzy do tego.

Pytałem o połączenie serializacji (lub innej techniki implementującej persystencję) i
języka, które wg. Ciebie ma sens.

Teraz ja Cię z kolei nie rozumiem.

1) Piszesz o tym, że OOP i Serializacja to złe połączenie.
2) Pytam Cię, jakie jest dobre połączenie.
3) Mówisz mi, że Java i interfejs Serializacji ze sobą współpracują.

Java to OOP. Twoje posty są ze sobą sprzeczne!

do góry

W dniu czwartek, 20 lutego 2014 22:43:50 UTC+1 użytkownik A. L. napisał:

> Definicja obiektu minilanla to "struktura posiadajaca tozsamosc, stan
> i zachowanie(behavior)". Niczego wiecej od obiektowosci sie nei
> wymaga.

Już kiedyś o tym tutaj dyskutowaliśmy.
Jeszcze raz: powyższe warunki spełniają np. rejestry w asemblerze. Zmienne w Basicu
też te warunki spełniają. Z tego by wynikało, że zarówno asembler jak i Basic są
obiektowe.

Takie definicje nie pozwalają na rozróżnianie od siebie różnych rzeczy a przez to są
po prostu bezużyteczne - w szczególności nie pozwalają odpowiedzieć sensownie na
pytanie, czym różni się programowanie obiektowe od innych.
Napinasz się, że Wikipedia pisze bzdury a podajesz bezużyteczne definicje jako lepszą
i bardziej autorytatywną alternatywę? I jednocześnie piszesz, że czasy się zmieniają,
to i owo się w programowaniu zmienia a i tak trzymasz się na siłę uproszczonej
definicji, która w swojej bezużyteczności jest ponadczasowa i tak samo bezużyteczna
mogła być też 30 lat temu?

E tam.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

W dniu piątek, 21 lutego 2014 09:48:34 UTC+1 użytkownik Maciej Sobczak napisał:
> W dniu czwartek, 20 lutego 2014 22:43:50 UTC+1 użytkownik A. L. napisał:
>
>
>
> > Definicja obiektu minilanla to "struktura posiadajaca tozsamosc, stan
>
> > i zachowanie(behavior)". Niczego wiecej od obiektowosci sie nei
>
> > wymaga.
>
>
>
> Już kiedyś o tym tutaj dyskutowaliśmy.
>
> Jeszcze raz: powyższe warunki spełniają np. rejestry w asemblerze. Zmienne w Basicu
też te warunki spełniają. Z tego by wynikało, że zarówno asembler jak i Basic są
obiektowe.
>
>
>
> Takie definicje nie pozwalają na rozróżnianie od siebie różnych rzeczy a przez to
są po prostu bezużyteczne - w szczególności nie pozwalają odpowiedzieć sensownie na
pytanie, czym różni się programowanie obiektowe od innych.
>
> Napinasz się, że Wikipedia pisze bzdury a podajesz bezużyteczne definicje jako
lepszą i bardziej autorytatywną alternatywę? I jednocześnie piszesz, że czasy się
zmieniają, to i owo się w programowaniu zmienia a i tak trzymasz się na siłę
uproszczonej definicji, która w swojej bezużyteczności jest ponadczasowa i tak samo
bezużyteczna mogła być też 30 lat temu?
>
>
wlasnie nie, ta definicja jest wlasnie dosyc dobra tj zgodna wlasnie z tym jak jest -
z tym ze z pewnymi subtelnosciami -- dla mnie pewne subtelnosci
polegaja chocby na tym ze nie calkiem bylbym zadowolony z tego gdyby pojecie objetku
mialo
kompletnie zawłaszczac pojecie 'struktury z funkcjami' - nie dlatego ze mam cos
przeciwko pojeciu obiektu (od biedy moze byc) tylko
dlatego ze taki obiekt kojarzy sie od razu z tymi nieszczesnymi oopami takimi jak w
jawie czy cpp i inn

wiecej z przykładów -
osobiscie dosyc czesto uzywam pojecia
encja badz instancja które jest ogólniejsze i
szersze w pewien sposob spaja pojecia 1) zwyklej encji 2) struktury 3) obiektu i 4)
modułu jak i byc moze jeszcze wiecej mozliwych kawałków tego typu
(jak np 5) agent albo 6) obiekt abstrakcyjny - i potencjalnie inne)

do góry

W dniu czwartek, 20 lutego 2014 22:43:50 UTC+1 użytkownik A. L. napisał:

> >W dniu czwartek, 20 lutego 2014 04:19:30 UTC+1 użytkownik A. L. napisał:
> >> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
> >> wrote:
> >>
> >> Zarowno hermetyzacja jai i polimorfizm nic nie maja ze soba wspolnego
> >> ani nic nie maja wspolnego z obiektowoscia.
> >
> >Przepraszam, ze sie powolam na to zrodlo, ale wydaje mi sie, ze
> >ono dosc dobrze reprezentuje "powszechne mniemanie" (i ma te zalete,
> >ze jezeli uwazasz, ze jest pelne glupot, a Ty wiesz lepiej, to
> >mozesz samemu to poprawic):
> >http://en.wikipedia.org/wiki/Object-oriented_progra
mming,
> >tamze:
> >
> >An object is an abstract data type with the addition
> >of polymorphism and inheritance.
> >
> >i dalej:
> >
> >Object orientation eases maintenance by the use of
> >encapsulation and information hiding.
> >
>
> To ze Wikipedia tak sobei uwaza, to nei znaczy ze to ejst prawda.
>
> Definicja obiektu minilanla to "struktura posiadajaca tozsamosc, stan
> i zachowanie(behavior)". Niczego wiecej od obiektowosci sie nei
> wymaga.
>
> Hermetyzacja, polimorfizm i subtyping sa zupelnie neizaleznymi
> pojecia,i, ktore i owszem, mozna w OO wykorzystywac. Ale nie ma takiej
> koniecznosci.
>
> Posumowujac: akurat w tej dziedzinei Wikipediapisze bzdury
>
> >> 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.
> >[...]
> >>
> >> Polimorfizm nic nie mowi o "zastepowaniu klas".
> >
> >Moze tutaj rzeczywiscie wyrazilem sie dosc niefortunnie.
> >Chodzilo mi o zastapienie obiektu jednej klasy obiektem
> >innej, implementujacej ten sam interfejs. Byl to skrot
> >myslowy, ale przyznam, ze nie widze jak inaczej mozna by
> >go sensownie interpretowac.
> >
>
> To tez nie jest polimorfizm. Proponuje pzreczytac to co napisalem i
> sie zastanowic. Zajzrec tez do Wikipedii. Akurat o polimorfizmie
> Wikipedia pisze z sensem.

A moze jest wlasnie na odwrot -- moze o obiektowosci pisze z sensem,
a o polimorfizmie belkoce?

Z wikipedia jako "zrodlem wiedzy" jest pare problemow,
a jednym z najwiekszych jest to, ze nie ogranicza sie do
opisywania rzeczywistosci, ale rowniez ja ksztaltuje
(i jest to nieuniknione). Problem ten jest jednak problemem
tylko wtedy, gdy chcemy traktowac wikipedie jako zrodlo
wiedzy o rzeczach; znika natomiast wowczas, gdy potraktujemy
ja jako zrodlo wiedzy o ludziach (tych, ktorzy ja pisza
i czytaja) i ich mniemaniach.

Oczywiscie ma Pan racje, ze polimorfizm, hermetyzacja,
dziedziczenie i obiektowosc to sa rozlaczne pojecia,
i przynajmniej dwa pierwsze mozna rozwazac w calkowitym
oderwaniu od pojecia obiektu [w sensie okreslonym powyzej
przez Pana, tj. tozsamosc+stan+zachowanie]. Jednak kiedy
ludzie mowia o "programowaniu zorientowanym obiektowo",
czesto nie maja po prostu na mysli programowania, w ktorym
uzywa sie obiektow, ale pewien calosciowy pomysl (czy moze
religie) dotyczacy tego, jak tworzyc dobre oprogramowanie,
zas wsrod kluczowych idei znajduja sie te tutaj przytoczone.

Zeby nie byc goloslownym, ale i nie szukac za daleko:
http://en.wikipedia.org/wiki/Object-oriented_design#
Object-oriented_concepts

The five basic concepts of object-oriented design (...):
- Object/Class (...)
- Information hiding (...)
- Inheritance (...)
- Interface (object-oriented programming) (...)
- Polymorphism (...)

Choc posluzylem sie poreczna wikipedia, zapewniam, ze takich
kolokacji mozna znalezc duzo wiecej. (Byc moze ma to swoje
zrodlo u Stroustrupa, a moze jeszcze wczesniej). Jezeli uwaza
Pan, ze to nieprawda, albo co wiecej -- ze ta nieprawda moze
byc szkodliwa, to moze Pan poswiecic swoja energie na to, zeby
te "bzdury" zniknely z wikipedii, bo ona niestety promieniuje,
stajac sie tym klamstwem, ktore zostaje powtorzone dostatecznie
wiele razy.

Co do tematu polimorfizmu, to wikipedia wydaje sie calkowicie
zgadzac z tym, co napisalem: "polymorphism is the provision
of a single interface to entities of different types". Nie
widze istotnej roznicy pomiedzy tym sformulowaniem, a moim.

> >> Tak na marginesie, interfejs nei okrecla calkowicie zachowanai modulu;
> >> moduly o identycznych interfejsach nie musza byc identyczne
> >
> >To chyba dosc oczywiste?
>
> No, nie sie wydawalo ze Pan postuluje wlasnei to. Nei chce mi sie
> szukac ytatu

Od dluzszego czasu odnosze wrazenie, ze odnosi sie Pan raczej
do tego, co sie Panu wydaje, ze napisalem, niz do tego, co
rzeczywiscie napisalem. Byc moze w jakiejs mierze wynika to
z mojej nieudolnosci w wypowiadaniu sie, jednak przyznam,
ze prezentowana przez Pana postawa, polegajaca na tym,
ze raczej jest Pan sklonny wyrazic oderwane od wszelkiej
merytoryki lekcewazenie wobec jakiejs wlasnej interpretacji
moich slow, niz wypytac, o co rzeczywiscie moglo mi chodzic,
nie ulatwia porozumienia.

(Wczesniejszym razem z jakichs niepojetych dla mnie wzgledow
uznal Pan, ze jestem przeciwnikiem statycznej kontroli typow,
a pozniej uznal moje wyjasnienie heurystyki budowania
programow w logice w oparciu o programy funkcyjne za
"kompletna bzdure", choc nadal nie dowiedzialem sie, dlaczego)

do góry

W dniu czwartek, 20 lutego 2014 22:39:38 UTC+1 użytkownik A. L. napisał:
> On Thu, 20 Feb 2014 01:27:57 -0800 (PST), g...@g...com
> wrote:
> >Produkowanie cyfrowej makulatura wydaje sie rzeczywiscie ciekawym
> >zjawiskiem, jednak trudno mi pojac, jak odnosi sie to do
> >poruszanego wczesniej tematu.
> >
> Hm... papier Szyperskiego to "makulatora"?... Ten akurat jest dosyc
> czesto cytowany w kontekscie dyskusji o tym ze hermetyzacja i
> obiektowosc to zupelnie niezalezne koncepcje. Proponuje jednak
> przeczytac

Po pierwsze, nigdy nie twierdzilem, ze hermetyzacja i obiektowosc
to sa koncepcje, ktore w jakis sposob od siebie zaleza. Twierdzilem
raczej (gwoli scislosci), ze hermetyzacja jest w jakims sensie
skladnikiem pewnej idei, ktora wiele osob nazywa "programowaniem
zorientowanym obiektowo". Pan zas w swojej postawie przypomina
angielskiego turyste, ktory bedac w USA zwraca wszystkim uwage,
ze na apteke nie powinno sie mowic "drugstore", tylko "pharmacy",
zas bedac w Holandii twierdzi, ze nie powinno sie mowic "coffee shop",
tylko "drug store". I teraz probuje Pan przekonac tych nieszczesnych
Amerykaninow i Holendrow, jakoby twierdzili, ze rutinoscorbin ma
dzialanie psychoaktywne, a marihuana jest rodzajem kawy.

Jezeli zas idzie o Szyperskiego, to przejrzalem go dosc pobieznie
i choc moze mial nawet bardzo duze znaczenie historyczne, to
jednak jest dosc mocno uwiklany w kontekst swojego powstawania
(tj. brak systemu modulow w jezykach Eiffel i Smalltalk), zas
kwestie, ktore podejmuje, podejmuje w sposob jednostronny.
Mianowicie postuluje koniecznosc dodania systemu modulow
do jezykow wspierajacych klasy, lecz w ogole nie rozwaza
sytuacji przeciwnej, tj. koniecznosci rozszerzania jezykow
wspierajacych moduly o system klas. To, co by mnie interesowalo,
to kwestia, czy jezeli moduly maja w jakims jezyku status
"first-class", to czy bylby to dostateczny srodek wyrazu
do tego, zeby zbudowac w oparciu o nie system klas.

> >> SICP jest dsyc zlezala i trudnia ja dzis traktwoac jako solidne
> >> zrodlo.
> >
> >Ma Pan oczywiscie prawo do wlasnej opinii. Jest to jednak
> >najlepsza ksiazka dotyczaca programowania, z jaka mialem
> >kiedykolwiek stycznosc -- a dzieki temu, ze ujmuje zjawisko
> >programowania w ogolnosci, trudno mi sobie wyobrazic, zeby
> >mogla sie kiedykolwiek zdezaktualizowac.
>
> Ksiazka byla opubilkowana 30 lat temu; troche to i owo sie zmienilo od
> tego czasu. Bardzo jest ciekawa, i owszem, w kontekscie historycznym.

Co na przyklad sie zmienilo?
(Jedyna rzecz, ktora przychodzi mi do glowy, to popularyzacja
pattern-matcherow, dzieki ktorej nie trzeba juz uzywac tych
nieszczesnych "car-ow" i "cdr-ow". Jednak dla przedstawianych
przez ksiazke koncepcji mogloby to miec jedynie znaczenie
kosmetyczne)

> Jakis czas temu MIT zrezygnowalo z uzywania tej ksiazki jako
> podrecznika i Scheme jako pierwszego jezyka programwoania; pzresadzili
> sie na Pythona.

Pozwoli Pan, ze sie posluze Panskimi slowami: a co to ma do rzeczy?

do góry

W dniu piątek, 21 lutego 2014 13:41:49 UTC+1 użytkownik g...@g...com napisał:
[...]
> tylko "drug store". I teraz probuje Pan przekonac tych nieszczesnych
> Amerykaninow i Holendrow, jakoby twierdzili [...]

Errata: Amerykanow

Kajam sie

do góry

W dniu piątek, 21 lutego 2014 13:41:49 UTC+1 użytkownik g...@g...com napisał:
> W dniu czwartek, 20 lutego 2014 22:39:38 UTC+1 użytkownik A. L. napisał:
>
> > On Thu, 20 Feb 2014 01:27:57 -0800 (PST), g...@g...com
>
> > wrote:
>
> > >Produkowanie cyfrowej makulatura wydaje sie rzeczywiscie ciekawym
>
> > >zjawiskiem, jednak trudno mi pojac, jak odnosi sie to do
>
> > >poruszanego wczesniej tematu.
>
> > >
>
> > Hm... papier Szyperskiego to "makulatora"?... Ten akurat jest dosyc
>
> > czesto cytowany w kontekscie dyskusji o tym ze hermetyzacja i
>
> > obiektowosc to zupelnie niezalezne koncepcje. Proponuje jednak
>
> > przeczytac
>
>
>
> Po pierwsze, nigdy nie twierdzilem, ze hermetyzacja i obiektowosc
>
> to sa koncepcje, ktore w jakis sposob od siebie zaleza. Twierdzilem
>
> raczej (gwoli scislosci), ze hermetyzacja jest w jakims sensie
>
> skladnikiem pewnej idei, ktora wiele osob nazywa "programowaniem
>
> zorientowanym obiektowo". Pan zas w swojej postawie przypomina
>
> angielskiego turyste, ktory bedac w USA zwraca wszystkim uwage,
>
> ze na apteke nie powinno sie mowic "drugstore", tylko "pharmacy",
>
> zas bedac w Holandii twierdzi, ze nie powinno sie mowic "coffee shop",
>
> tylko "drug store". I teraz probuje Pan przekonac tych nieszczesnych
>
> Amerykaninow i Holendrow, jakoby twierdzili, ze rutinoscorbin ma
>
> dzialanie psychoaktywne, a marihuana jest rodzajem kawy.
>
>
>
> Jezeli zas idzie o Szyperskiego, to przejrzalem go dosc pobieznie
>
> i choc moze mial nawet bardzo duze znaczenie historyczne, to
>
> jednak jest dosc mocno uwiklany w kontekst swojego powstawania
>
> (tj. brak systemu modulow w jezykach Eiffel i Smalltalk), zas
>
> kwestie, ktore podejmuje, podejmuje w sposob jednostronny.
>
> Mianowicie postuluje koniecznosc dodania systemu modulow
>
> do jezykow wspierajacych klasy, lecz w ogole nie rozwaza
>
> sytuacji przeciwnej, tj. koniecznosci rozszerzania jezykow
>
> wspierajacych moduly o system klas. To, co by mnie interesowalo,
>
> to kwestia, czy jezeli moduly maja w jakims jezyku status
>
> "first-class", to czy bylby to dostateczny srodek wyrazu
>
> do tego, zeby zbudowac w oparciu o nie system klas.
>

mozna własnie instancjonowac moduły (o czym pisalem wiele razy ), (chocby wczoraj, bo
na takich instoncjonowanych modulach mozne zrobic rozna ciekaw rzeczy np jesli gra ma
wiele screenów (np przygodówka) to napisac moduł Screen,
wyinstancjonowac go tyle razy ile screenow
ma miec gra po czym zalozyc wyrazic polaczenia
w runtime itp

do góry

W dniu czwartek, 20 lutego 2014 22:47:53 UTC+1 użytkownik A. L. napisał:
> On Wed, 19 Feb 2014 22:58:54 -0800 (PST), g...@g...com
> wrote:
>
> >W dniu czwartek, 20 lutego 2014 04:30:11 UTC+1 użytkownik A. L. napisał:
> >> 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
> >
> >*Szczegolnie* dobrze sie ten postulat realizuje, gdy w grupie jest 1100+
> >programistow, a system ma 15 milionow linii kodu
> >
> >http://news.cnet.com/8301-1035_3-57603216-94/linux-
development-by-the-numbers-big-and-getting-bigger/
>
> A co to ma wspolnego z tym co napisalem i o czym szla dyskusja?

Duzo. Na samym poziomie leksykalnym ma to wspolnych 17 z 19 slow,
zas ich kolejnosc w obu zdaniach -- Panskim i moim -- jest identyczna,
co wskazywaloby, ze odniesienie moich slow do Panskich jest bezposrednie.
(zrodlo podalem tylko po to, zeby uwydatnic kontekst).

Jezeli zas idzie o odniesienie merytoryczne, to ono zalezy wylacznie
od Panskiej pierwotnej intencji. Jezeli miala ona byc sarkastyczna
(tak jak mi sie zdalo), to jest to kontrargument na rzecz owego sarkazmu.
Jezeli zas byla prosta, to jest to wyraz tego, ze sie zgadzamy co do tego,
ze jakosc i dostepnosc kodu zrodlowego jest wazniejsza od tego, zeby
interfejsy aplikacji byly od razu dobrze zaprojektowane.

do góry

>
>
> mozna własnie instancjonowac moduły (o czym pisalem wiele razy ), (chocby wczoraj,
bo na takich instoncjonowanych modulach mozne zrobic rozna ciekaw rzeczy np jesli gra
ma wiele screenów (np przygodówka) to napisac moduł Screen,
>
> wyinstancjonowac go tyle razy ile screenow
>
> ma miec gra po czym zalozyc wyrazic polaczenia
>
> w runtime itp

przy okazji pytanie czy 'dziedziczenie' takich modułów miałoby jakis sens - np jak
sie robi moduł/encje screenu/okna/kontrolki i chce sie
z tego zrobic jakas nadbudowana wersje screenu/okna/kontrolki.. moim zdaniem raczej
widac
ze splatanie nadbudowanej wersji z jakimis wywolaniami tej poprzedniej wersji (tak
jak sie
robi czesto w dziedziczeniu) moze byc
glupie i ograniczajace, moze byc lepiej napisac
odzielnie, a jesli juz chce sie splatac te
wywolania (przyjmujemy ze chcemy zrobic grupe modulów robiacych podobne rzeczy) to
mozna te
zaleznosci zapewne zaprojektowac zaiste lepiej
niz z ta sztuczka z dziedziczeniem (jak w mfc, ui iphona, androida, winform czy
innych tam licznych
tego typu bezsensach) - choc powiedzenie jak ja bym to zrobil w systemie modulowym
wymagaloby ode mnie troche praktyki bo nie robilem poki co nigdy zestawu podobnych
modułow)

do góry

On Wed, 19 Feb 2014 21:27:59 -0600, A.L. <a...@a...com> wrote:
> 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

Może sie mylę, ale chyba serializacja nie wymaga stosowania
relacyjnej bazy danych?

RW

do góry