🚀 go-pugleaf

Odpowiedz na list Rafala Posmyka


1. Czy relacyjne bazy danych stanowia przeszkode przy
tworzeniu systemow obiektowych?

> Nie koniecznie. Zalezy od podejscia do sprawy. Niektore
> systemy baz danych, mam tu na mysli SQL-Servery, pozwalaja
> dzieki sposobowi odpytywania - ja tobie query, ty mi 
> resultset, na uniezaleznienie applikacji od modelu danych. 
> Nalezy wiec skonstruowac takie klasy, ktore sa w stanie 
> zapamietac SQL-statements (chetnie sparametryzowane) i 
> posiadaja "inteligentny" pojemnik, ktory potrafi przyjac 
> dowolny zbior wynikowy (resultset), tzn. o dowolnej 
> liczbie kolumn (dowolnego typu) i linijek. Chodzi mi o to,
> aby relacyjnie zapamietane dane przeniesc do objektu.
> Inaczej mowiac - dane nie sa (statycznie) reprezentowane
> przez "datamember" korespondujacej klasy; klasa posiada
> tylko przepis (SQL-statementa) jak sobie odpowiednie dane
> "zalatwic". W ten sposob mozna sie dosc elegancko odpiac
> od relacyjnego modelu danych. Z puktu widzenia programisty
> (uzytkownika takich klass) nie ma znaczenia jak dana klasa
> czyta, zapamietuje, zmienia czy kasuje dane. Jasne, ze 
> effekt ten jest osiagalny dopiero wtedy gdy takie klasy

Chyba mnie nie zrozumiales, Twoj sposob nie rozwiazuje 
niczego. Podam przyklad. 

Zalozenie: Mamy trzy klasy: Czlowiek <- Kobieta <- Matka 
(strzalki oznaczaja relacje dziedziczenia, gdzie Czlowiek 
jest klasa pierwotna). Zalozmy, ze istnieje trzecia klasa 
Organizacja, ktora jest dynamicznie tworzona kolekcja 
obiektow ww. klas. I tak np. w danej chwili Organizacja moze 
zawierac 3 obiekty typu Czlowiek, dziesiec typu Kobieta 
i sto typu Matka. Oczywiscie klasy Czlowiek, Kobieta i Matka 
posiadaja funkcje wirualne. 

Problem: Nalezy obiekt typu Ogranizacja zapisac w 
bazie danych.

Pytanie: Jak to zrobic przy pomocy relacyjnej bazy danych?

Oczywiscie ww. problem jest trywialny - w normalnej 
aplikacji mamy do czynienia ze znacznie bardziej zlozonymi 
zaleznosciami. Jednak nawet tak banalny problem, przysparza
wielu klopotow jesli probuje sie go rozwiazac przy pomocy
relacyjnych baz danch. Nie wierzysz? Sprobuj sam.

2. Czy MFC i OWL sa "czysto" obiektowe. 

> Osobiscie uwazam, ze MFC i OWL, sa barzo objektowe jezeli
> wziac pod uwage jakosc windowsowskiego API. Kolesie 
> poprostu zrobili co mogli i nawet im to wyszlo :-)

Rownie dobrze moglbym powiedziec, ze VisualBasic jest bardzo
obiektowy biorac "pod uwage jakosc windowsowkiego API" (VB
to tez przeciez programowanie w Windows). Chodzi mi o to, ze
uzywajac obiektowej biblioteki do programowania w Windows,
chcialbym zapomniec o tym, ze cos takiego jak Windows API 
wogole istnieje. Czy uzywajac MFC udalo ci sie to 
kiedykolwiek? Wedlug mnie MFC nie jest zla biblioteka, ale 
z pewnoscia nie jest to dobra biblioteka obiektowa. OWL jest
znacznie lepsze pod tym wzgledem - poziom abtsrakcji jest
tu o wiele wiekszy. Jeszcze lepszym przykladem jest VCL
(Delphi) - w tym przypadku naprawde mozna czasami zapomniec
o Windows. Nadal jednak uwazam, ze zadna z ww. bibliotek
nie jest "czysto" obiektowa.

3. Delphi i OO

> Tu znowu dochodzimy do punktu, gdzie widac jak na dloni,
> ze objektowosc applikacji zalezna jest od srodowiska
> (np. systemu operacyjnego), w ktorym bedzie ona pracowac.
> W tym konkretnym przypadku sa to windowsowskie zaleznosci
> okienek - parent/child.                                

Zupelnie sie z Toba nie zgadzam. To, ze w przytoczonym przeze
mnie przykladzie, kod wygenerowny przez Delphi jest taki a 
nie inny, to jedynie "zasluga" Delphi - Windows nie ma z tym 
kompletnie nic wspolnego (ani tez "windowsowskie zaleznosci
okienek - parent/child"). Efekt o ktory mi chodzilo, tzn.
kazda strona mojego notatnika - osobna klasa, mozna z 
powodzeniem osiagnac wklepujac recznie okreslona ilosc kodu.
Pozostaje tylko pytanie - dlaczego nie zrobil tego generator?

4. Dlaczego tworzenie "czystych" systemow obiektowych nie
jest oplacalne.  

> Jest tak dlatego, ze nasze objektowe podejscie do 
> problemow nie jest jeszcze "pelnoletnie". Podejzewam, ze 
> nasze wnuki bedo sobie z tym lepiej radzic :-)

Nie, jest tak dlatego, ze narzedzia, ktorymi posluguja sie 
programisci obiektowe wcale nie sa. Jesli na moim biurku
zamiast VC++, MFC i Sybase SQL Server beda lezec: 

- dobry kompilator ze zintegorowanym srodowiskiem, ktore 
wspomaga tworzenie systemu, poprzez wszystkie jego fazy 
(analiza, projektownie, programowanie), 
- biblioteka-naprawde-obiektowa,
- obiektowa baza danych (WARUNEK KONIECZNY)

to jest szansa, ze w logo moich programow bede mogl z duma
napisac: system obiektowy.

I to by bylo na tyle


Robert