firr <p...@g...com>:
> > dla przykladu czy nie lepiej osadzic pixelbufora
> > blittera i window od razu w Game, lub jeszcze
> > inaczej na przyklad window w game a pixelbufor w
> > window z kolei blitter w pixelbufor lub jeszcze inaczej? Co o tym decyduje?
> w systemie modułowym cały ten 'setup' i 'konfiguracja' wzajemnej
> widzialnosci miedzy tymi obiektami ktora tutaj jest wypączkowywana w runtime
> (dla mnie brzydka i ograniczona, choc jestem chetny uslyszec jak ktos chce
> tego braonic) jest po prostu statycznie dany w bardzo ładnej i czystej
> formie w systemie modułowym , gdzie u mnie wygladołoby to mw tak (nie
> mialbym modulu game ale zamiast niego moduł ramka, kod updatujacy i rysujacy
> dana ramke
[bzzz]

Aby zrozumieć, że OOP nie ogranicza w żaden sposób programowania, może
powinieneś wyobrazić sobie nie sam akt pisania programu, ale jego przyszły
rozwój.

To znaczy: napisałeś program, który w 100% wypełnia zachcianki klienta, czyli
rysuje piksel na ekranie. Potem natomiast przychodzi drugi klient, i zamawia u
ciebie program, który rysuje nie piksel, ale prostokąt. Teraz, aby nie kopiować
projektu A do katalogu B, i nie posiadać dwóch wersji dość podobnego kodu
źródłowego, mógłbyś kombinować tak, żeby tylko dopisać do kodu A funkcję
rysowania prostokątów, ale tak, aby funkcja rysowania pikseli nie została
usunięta. Czyli, aby program był w stanie rysować i piksele i prostokąty, ale
nie obydwa na raz.

Twój kod modułowy może osiągnąć to np. tak:

1) W funkcji rysującej piksel możesz dodać warunek:

if(pierwszyKlient) { rysujPiksel(); } else { rysujProstokąt(); }

Jednak, gdy przyjdzie trzeci klient, i zechce program, który blituje od tyłu do
przodu, a nie tak, jak pierwszych dwóch klientów, od przodu do tyłu, sytuacja
może się skomplikować (szczególnie jak przyjdzie kolejnych 10 klientów z
kolejnymi zachciankami).

2) Możesz wyrzucić funkcję rysującą do oddzielnego pliku cpp, dopisać nowy plik
cpp, który implementuje tą samą funkcję, ale zamiast piksela rysuje prostokąt.

Jednak, gdy przyjdzie klient, który zechce, by na ekranie został narysowany
prostokąt, a na nim piksel, nie będziesz mógł wykorzystać obu plików cpp
jednocześnie. Będziesz zmuszony stworzyć trzeci plik, który rysuje prostokąt i
piksel, będzie on jednak powielał kod i z pierwszego pliku cpp, i z drugiego.

3) Masz jakiś inny pomysł? ;)

Mój kod obiektowy wymaga stworzenia nowego interfejsu logiki rysowania i dwóch
klas:

class RysujPiksel: public LogikaRysowania { };

class RysujProstokąt: public LogikaRysowania { };

Sama funkcja rysująca wykorzystuje klasę LogikaRysowania, więc automatycznie
akceptuje wszystkie klasy, które ją dziedziczą. Wybór, która klasa ma zostać
użyta, może być dokonany podczas działania programu. Może być to jedna klasa,
albo obie i nie trzeba wybierać, które pliki skompilować, a których nie ;)