Thread View: pl.comp.objects
2 messages
2 total messages
Started by quas... Robert Perlinski
Thu, 23 Nov 1995 00:00
Re: Czy nasze systemy OO sa naprawde OO?
Author: quas... Robert Perlinski
Date: Thu, 23 Nov 1995 00:00
Date: Thu, 23 Nov 1995 00:00
95 lines
4115 bytes
4115 bytes
Odpowiadajac na list Rafal Posmyka > [w tm miejscu znadowalo sie rozwiazanie Rafala problemu] > [zapisu obiektow w RBD] > > Spodziewam sie, ze uznasz to za przerarzajaco > nieeleganckie :-) ... Tak jest to nieeleganckie. Nie jest to jednak ocena Twojego rozwiazania. Po prostu nie da sie tego zrobic lepiej. Z tym, ze rozwiazanie jest nieeleganckie moglbym jednak zyc, gorsze jest to, ze jest niesamowicie czasochlonne. Zwroc uwage, ze nasz przyklad byl prosciutki, a mimo to rozwiazanie wcale proste nie jest. Co sie dzieje w przypadku, gdy nasz projekt zamiast trzech klas posiada ich 100, a zaleznosci pomiedzy nimi sa o wiele bardziej skomplikowane niz w naszym zadaniu? To bylo pytanie, retoryczne. Mysle, ze kazdy kto przezyl to choc raz, zna odpowiedz. > ...Ma to jednak sporo zalet, np. mieszanie w obrebie > jednego duzego systemu elementow relacyjnach i > objektowych... Nazywasz to zaleta? Dla mnie to zlo konieczne. > ...Albo mozliwosc tworzenia aplikacji (frontend) > nieobjektowych. Tego nie zrozumialem > 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 :-) Wierze Ci. Sam przezylem to kilkakrotnie. Nie kazda jednak praktyka zasluguje na nasladownie. Tej, o ktorej piszesz, nie polecalbym w szczegolosci. > > 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". Tutaj przebiles nawet Microsoft. Nawet oni nie probuja mowic, ze VB jest obiektowy. > > 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? ... > > 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, ... Zle mnie zrozumiales. Jesli pisze, ze dzieki bibliotece chcialbym zapomniec o API, to oczywiscie chodzi mi o zakres zadan, ktorym sie dana biblioteka zajmuje. Jesli np. obiektowa biblioteka X zajmuje sie OLE to uzywajac jej chcialbym zapomniec o OLE API. Poza tym nieprawda jest, ze MFC i OWL to tylko GUI. > 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). Jescze raz sie z Toba niezgodze. Podam ci przyklad: wyobraz sobie, ze nasz program ma wyslwietlac okienko z 3 przyciskami w srodku (zakladam, ze takie klasy jak Okienko i Przycisk mamy juz zdefiniowane) Mozna to zrobic na nieskonczona ilosc sposobow np. 1. Utworzyc 4 klasy (1 dla okienka, 3 dla przyciskow) 2. Utworzyc 1 klase (worek) 3. Utworzyc 99 klas (jesli mam taki kaprys) Moj oryginaly przyklad z TTabbedNotebook, od ktorego watek "Delphi i OO" sie rozpoczal (i do ktorego posrednio sie odwolujesz), byl troche bardziej skomplikowany, ale idea byla dokladnie taka sama - Delphi zawsze wybierze sposob numer 2 (co niestety nie zawsze jest najszczesliwsze) Czy w swietle powyzszego przykladu, nadal uwazasz, ze Windows w jakikolwiek sposob narzuca sposob podzialu mojego programu na klasy? Jesli nadal tak, to chetnie zobacze przyklad. I to by bylo na tyle Robert
Re: Czy nasze systemy OO sa naprawde OO?
Author: raphael... Rafal Posmyk
Date: Mon, 27 Nov 1995 00:00
Date: Mon, 27 Nov 1995 00:00
100 lines
4715 bytes
4715 bytes
In article <9511231...@cig.com>
from 23 Nov 95 20:48:45 GMT
quas...@cig.com (Robert Perlinski) wrote:
> Z tym, ze rozwiazanie jest nieeleganckie moglbym jednak
> zyc, gorsze jest to, ze jest niesamowicie czasochlonne. Zwroc
> uwage, ze nasz przyklad byl prosciutki, a mimo to rozwiazanie
> wcale proste nie jest. Co sie dzieje w przypadku, gdy nasz
> projekt zamiast trzech klas posiada ich 100, a zaleznosci
> pomiedzy nimi sa o wiele bardziej skomplikowane niz w naszym
> zadaniu? To bylo pytanie, retoryczne. Mysle, ze kazdy kto
> przezyl to choc raz, zna odpowiedz.
Zgadzam sie, ze prostsze jest odwzorowanie modelu relacyjnego
na model OO niz odwrotnie. Zauwaz jednak, ze w praktyce
bedziesz sie spotykal prawie wylacznie z pierwszym przypadkiem
(integracja w istniejace srodowisko RDBMS).
Takze w momencie kiedy jestes skazany na uzywanie RDBMS,
od poczatku, nie bedziesz za wszelka cene tworzyl hierarchji
klas, ktora nie da sie odwzorowac w RDBMS. Pomimo iz, uzycie
ich (obiekty) po stronie clent'a daje wiele zalet. To poprostu
rzecz kompromisu :-|
> > ...Ma to jednak sporo zalet, np. mieszanie w obrebie
> > jednego duzego systemu elementow relacyjnach i
> > objektowych...
> Nazywasz to zaleta? Dla mnie to zlo konieczne.
Nazywam to zaleta, poniewaz latwiej jest odwzorowac
model relacyjny na OO niz odwrotnie (z punktu widzenia
modelu danych, a nie architektury aplikacji)
> > ...Albo mozliwosc tworzenia aplikacji (frontend)
> > nieobjektowych.
> Tego nie zrozumialem
Do RDBMS mozesz tworzyc zarowno aplikacje proceduralne
jak i obiektowe (choc nieeleganckie jak stwierdziles).
Przy OODBMS jestes zmuszony trzymac sie konstruktow OO
(przynajmniej do czasu kiedy definicja OODBMS jest
zwiazana z danym jez. programowania). Chociaz istnieja
juz teraz interfejsy ODBC do OODBMS (np. POET).
> > 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".
> Tutaj przebiles nawet Microsoft. Nawet oni nie probuja mowic,
> ze VB jest obiektowy.
Czytaj dokladnie - "objektowy interfejs do Windows API"
> Zle mnie zrozumiales. Jesli pisze, ze dzieki bibliotece
> chcialbym zapomniec o API, to oczywiscie chodzi mi o zakres
> zadan, ktorym sie dana biblioteka zajmuje. Jesli np.
> obiektowa biblioteka X zajmuje sie OLE to uzywajac jej
> chcialbym zapomniec o OLE API. Poza tym nieprawda jest, ze
> MFC i OWL to tylko GUI.
Moj Boze, nie ma rzeczy doskonalych ! Zawsze znajdzie sie
ktos, kto chce zaimplementowac cos rewolucynego, do czego
droga prowadzi tylko przez nativ API. Mozesz jednakze
zawsze rozszerzyc dana biblioteke o wlasne objekty.
W takim ukladzie trafiasz na API tylko raz (w trakcie
implementacji rozszerzen), pozniej widzisz juz tylko
obiekty :-)
> > 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).
> Jescze raz sie z Toba niezgodze. Podam ci przyklad:
> [ tu przyklad ]
> Czy w swietle powyzszego przykladu, nadal uwazasz, ze Windows
> w jakikolwiek sposob narzuca sposob podzialu mojego programu
> na klasy? Jesli nadal tak, to chetnie zobacze przyklad.
To racja, ze w programowaniu dany problem mozna rozwiazac na 99
roznych sposobow, ale... Wezmy na ten przyklad "windows messaging
system". Jezeli stworzysz obiekt przycisku (TButton) nie zwiazany z
zadnym dialogiem, a nastepnie uzyjesz tego samego obiektu w dwu
roznych okienkach dialogowych, jak mozesz miec pewnosc, do ktorego
dialogu zostana przeslane "notification messages" ? To wlasnie
jest windows'owski model aplikacji !
Rafal
P.S. Pomimo wielu niezgodnosci, przyznaje ze przyjemnie sie
z Toba dyskutuje :-)
o-------------------------------------------------------------------o
| Raphael Posmyk (Hamburg, Germany) |
| "... carpe diem, quam minimum credula postero..." (Horatius) |
| Please send/reply all to raphael...@hamburg.netsurf.de |
o-------------------------------------------------------------------o
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads