🚀 go-pugleaf

In article <9511171...@cig.com>
from 17 Nov 95 21:12:16 GMT
quas...@cig.com (Robert Perlinski) wrote:

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

Po czesci masz racje. Moj sposob dotyczyl bardziej powiazania
_relacyjnego modelu danych_ z objektowym modelem aplikacji.
Rozwiazuje to napewno sposob komunikacji tych dwoch systemow,
lecz nie pozwala na jenoznaczne odzwierciedlenie objektow
aplikacji w relacyjnej bazie danych. 0,5 punkta dla Ciebie :-)

> Zalozenie: Mamy trzy klasy: Czlowiek <- Kobieta <- Matka 
> [...]
> Problem: Nalezy obiekt typu Ogranizacja zapisac w 
> bazie danych.

> Pytanie: Jak to zrobic przy pomocy relacyjnej bazy danych?

Relacyjnowato :-) Nie jest to z relacyjnego punktu widzenia
eleganckie ale i nie jest to takze naprawde relacyjne. 

Tworze tabele organizacja, kobiety, matka, student (zakladam,
ze czlowiek jako klasa abstrakcyjna nie bedzie instancjowana).
W tabeli organizacja definiuje atrybuty np. czlonek i rodzaj,
gdzie organizacja.czlonek jest "foreign key" relacji 1:n do tabel
kobieta, matka, student, ... w zaleznosci od stalej organi-
zacja.rodzaj (mozna by to nazwac tez "compound foreign key",
raczej zadko stosowany w modelu relacyjnym, jakkolwiek nie
bledny badz nieelegancki). Umozliwia to takze dynamiczne dodawanie
nawych tabel korespondujacych z modelem dziedziczenia:
czlowiek->kobieta->matka-> ... Problem przedstawiac moze
na pierwszy rzut oka mozliwosc stworzenia zbioru wynikowego
(SQL:resultset) zapytania o relacje (SQL: join) np.

              matka
            / 
organizacja
            \
              student

gdzie pola tabel matka i student nie sa kompatybilne. Da sie to
chyba jednak obejsc przez odpowiednia definicje pol i uzycie
unii (SQL: union), tzn. zbior wynikowy typu:

relacja organizacja -> matka
union
relacja organizacja -> student

Po stronie aplikacji, container przyjmujacy dane zbioru wynikowego
instancjuje w zaleznosci od wartosci pola organizacja.rodzaj,
objekty odpowiednich klas i przekazuje do nich reszte danych. 

Alternatywnie: container podczas odczytu zbioru wynikowego:

select organizacja.XX, organizacja.czlonek, organizacja.rodzaj
from organizacja
where organizacja.rodzaj = matka
   or organizacja.rodzak = student

dla kazdej jego linijki, instancjuje objekty odpowiednich klas
(organizacja.rodzaj). Kazdy taki objekt posiada "umiejetnosc"
zapytania o dodatkowe informacje na podstawie danych 
organizacja.rodzaj (= nazwa tabeli) i organizacja.czlonek
(= "primary key", np. Matki.ID, Studenci.ID).

Spodziewam sie, ze uznasz to za przerarzajaco nieeleganckie :-)
Ma to jednak sporo zalet, np. mieszanie w obrebie jednego 
duzego systemu elementow relacyjnach i objektowych. Albo 
mozliwosc tworzenia aplikacji (frontend) nieobjektowych.
Jest to o wiele prostsze niz laczenie danych z baz nativ
objekzowych i relacyjnych. Czy mi wierzysz czy nie - takie
praktyki stosuje sie na codzien, nie jest to calkowicie 
moj pomysl :-) 

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

Nie znam dobrze czystego VB, raczej "VB for apllikation"
ale w swietle mojej poprzedniej tezy. mozna by cos takiego
powiedziec. Moze troche dokladniej (takze w stosunku do
OWL i MFC): "objektowy interfejs do Windows API".

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

Moj drogi nie zapominaj, ze MFC i OWL sa bibliotekami do 
GUI !!! A gdzie reszta systemu, gdzie operacje na zbiorach,
gdzie I/O, gdzie siec, ...

Zobacz http://www.startdiv.de pod haslem StarView i Solar.
Sam tego jeszcze w lapach nie mialem, ale jezeli zrealizuja
to wszystko co obiecali to bedziesz/bedziemy mieli "idealna"
OO-Lib na Win, OS/2, X11/Motif, MAC

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

Pisalem juz o tym w innej czesci tej dyskusji (chyba inny
watek). 

Windows narzuca pewien styl programowania, a Delphi tylko
go przejmuje. Tak wiec krytyka tyczyc sie powinna Windows,
co do stylu i Delphi co do nowatorstwa (a nie stylu).

Fajnie by bylo, gdyby mozna takiemu "application builder"
przekazac wlasne upodobania co do stylu programowania.
Zna ktos co w tym stylu ?

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

> > Jest tak dlatego, ze nasze objektowe podejscie do 
> > [..]

> 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 
> [...]
  
> to jest szansa, ze w logo moich programow bede mogl z duma
> napisac: system obiektowy.

Ja natomiast wtedy, gdy rozszerzenie systemu np. archiwizacji
dokumentow o mozliwosc czytania danych z projektora do mikrofilmow
(obok dotychczasowych metod: scaner, dia-projektor, telefax) bedzie
sie ograniczalo do stworzenia nowej klasy pochodnej, zmiany
kilku funkcji wirtualnych i dodania kilku nowych, dla czytnika
mikrofilmow specyficznych, dialogow. Nie bedzie mi w takim ukladzie
zbyt przeszkadzac fakt, ze do komunikacji z ww. czytnikiem uzyje
wstretnego Win API, czy tez bede zmuszony uzywac nie w pelni
objektowego kompilatora/srodowiska albo bibliotek. Wystarczy mi,
ze mam swiadomosc, iz moj system posiada objektowa architekture :-)

A mojemu zleceniodawcy bede mogl zakomunikowac iz naklad czasowy
zamknie sie w granicach 15 osobodni :-)

Rafal

o-------------------------------------------------------------------o
| Raphael Posmyk (Hamburg, Germany)                                 |
| "... carpe diem, quam minimum credula postero..." (Horatius)      |
| Please send/reply all to raphael...@hamburg.netsurf.de        |
o-------------------------------------------------------------------o