🚀 go-pugleaf

Odpowiadam Mackowi Pilichowskiemu, ktory napisal:

> : czy tworzenie prawdziwych systemow obiektowych jest
> : mozliwe w praktyce?
 
> Wg mnie tak, tyle, ze zalezy to od OS. Przeciez tylko
> OS limituje Ci takie, a nie inne zachowanie. Reszta to 
> wnetrze Twojego programu, a tam to juz wedle zasady 
> "jak sobie poscielesz tak sie wyspisz".

Nie zgadzam sie z Toba Maciek. Praktyka pokazuje, ze
im bardziej program jest niezalezny od systemu 
operacyjnego tym lepiej (przenosnosc). Idealnym 
rozwiazaniem jest uzycie dobrej, wieloplatformowej 
biblioteki obiektowej. Problem w tym, ze takich 
bibliotek jest na rynku malo i z reguly sa niezbyt
popularne. 

Gdyby nawet jednak przyznac Ci racje i zalozyc, ze 
"obiektowosc" naszych programow, zalezy od SO, to 
jest to tylko dowod na to, ze moja teza jest prawdziwa.
Dlaczego? Dlatego, ze systemy operacyjne, ktorych 
uzywamy na codzien wcale obiektowe nie sa.

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

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

Nie wiem jak ty, ale ja odkad zaczalem "zyc z 
programowania", niezbyt czesto mam mozliwosc wyboru 
narzedzi. Z reguly firma, dla ktorej zaczynam pracowac 
ma z gory ustalone preferencje. Swoja droga, powiedz mi
ile znasz bibliotek "czysto" obiektowych (tylko prosze
nie wymieniaj MFC)

> : - uzywamy narzedzi programistycznych, ktore w znikomym
> :   stopniu wspomagaja tworzenie systemow OO (niech
> :   przykladem bedzie Visual C++, Borland C++,
> :   Power Builder, Delphi)
 
> A tego to kompletnie nie rozumiem. VC++ nie wspomaga? 
> Delphi? A w ogole to po co mam masochistycznie uzywac 
> narzedzi, ktore mi nie ulatwiaja pracy???

Jesli chodzi o mozliwosci wyboru, to moje zdanie juz
znasz - w praktyce nieczesto ma sie ten komfort. Co do
wspomagania ze strony ww. narzedzi - uwazam, ze robia
to w znikomym stopniu. Kod wygenerowany przez roznego
rodzaju "wizards" jest dalece niedoskonaly (naprawde
uwazasz, ze jest to dobry kod obiektowy?) Tylko znowu -
w praktyce prawie kazdy z tego korzysta (czas). Nawet
Delphi, uwazane za super-obiektowe nie jest pod tym 
wzgledem doskonale - zeby Cie przekonac proponuje maly
eksperyment. Otworz nowa forme i umiesc na niej 
TabbedNotebook (jest to cos w rodzaju notatnika z wieloma 
niezaleznymi stronami, wyposazonego w zakladki, dzieki 
ktorym mozna dokonac wyboru strony - znane np. z Excela)
Zalozmy, ze nasz TabbedNotebook ma trzy strony. 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. Delphi nie bierze pod uwage tego, ze 
trzy strony w naszym TabbedNotebook beda prawdopodobnie
odpowiadac za zupelnie rozne zadania, mogace nie miec 
ze soba nic wspolnego. O wiele sensowniejsze byloby 
utworzenie trzech niezaleznych od siebie klas. Pol biedy
jesli mamy do czynienia z trzema stronami, co bedzie 
jesli bedzie ich dziesiec?


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.

I to by bylo na tyle


Robert