🚀 go-pugleaf

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

> > : - dane skladujemy w relacyjnej bazie danych
> > 
> > To duzy problem?
>  
> Tak, uwazam, ze jest to ogromny problem. Jak bowiem przy
> pomocy relacji odzwierciedlic chociazby takie koncepcje 
> jak dziedziczenie (wielodziedziczenie) i poliformizm.
> Ja wiem od biedy mozna to zrobic, ale wszystkie 
> rozwiazania jakie widzialem do tej pory sa na tyle
> nieeleganckie i nieefektywne, ze stawiaja pod znakiem 
> zapytania sens calego przedsiewziecia. Jesli chodzi o
> mnie to uwazam, ze wlasnie relacyjne bazy danych stanowia 
> najwieksza 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 sa gotowe.

> > : - uzywamy proceduralnych lub quasi-obiektowych 
> > :   bibliotek
> > 
> > No chyba obiektowych, jesli projekt ma byc OO.

>                            ... Swoja droga, powiedz mi
> ile znasz bibliotek "czysto" obiektowych (tylko prosze
> nie wymieniaj MFC)

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

Ale z punktu widzenia purrystow ...

> [... Delphi ...]
>                                             ... Na kazdej
> z nich umiesc pare dowolnych obiektow (przyciski, teksty)
> Rzuc okiem na kod wygenerowany przez Delphi - jedna klasa
> do ktorej jak do worka wrzucone jest wszystko co do tej
> pory zrobiles ...

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.

> Reasumujac to wszystko, nadal uwazam, ze na dzien 
> dzisiejszy, najbardziej oplacalne, jest tworzenie systemow,
> ktore wykorzystuja techniki obiektowe - obiektowe jedanak
> wcale nie sa. Wszelkie bardziej ortodoksyjne podejscia
> przypominaja walke z wiatrakami i bardzo czesto, skazane
> sa na niepowodzenie.

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

class Rafal : public Posmyk {/*...*/}

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