W dniu wtorek, 18 lutego 2014 20:40:49 UTC+1 użytkownik toslaw napisał:
> 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 ;)

troche glupawe te przyklady (troche to malo
powiedziane)

Nie wiem czy mam cos istotnego do dodania pozatym
co powiedziane - jesli chodzi o wlasnie utrzymywanie programu to własnie (jak ktos w
tym watku zwrocil uwage) obawiam sie ze ta 'pasożytnicza struktura' setupu roznych
obiektów i ich konfiguracji raczej pogarsza sprawe niz ja polepszac (*)

z punktu widzenia obiektu ktory ma jako pola
referencje do innych obiektow to jeszcze moze nie jest takie złe, ale ten 'setup i
konfiguracja'
i utrzymywanie tego to raczej koszmar (pisze 'raczej 'bo naprawde dawno nie grzebalem
w obiektowym programie i o tyle nie kojarze na ile uciezliwe to by dla mnie obecnie
było, czy bardzo czy moze tylko pierwiastek z bardzo ) <i to chybabyloby wszystko na
ten temat>


(*) tymbardziej ze system modulowy dziala po prostu swietnie, choc w c dobrze bybylo
go poprawic

1) o typowanie symboli w binarnych modulach tak zeby nie trzebbylo pisac naglowków
funkcji

2) o slowo kluczowe jawnie wypisujace u gory modulu z jakimi innymi modulami go
linkowac (tak zeby linker nie linkowal wszystkiego z wszystkim i zeby byla tez
kontrola zabezpieczenie przed pomylkami
no i tez rodzaj komentarza itp)

3) o mozliwosc podania nazwy modulu przed funkcja tak zeby mozna bylo rozroznic w
razie konfliktów,
plut tez czasem mozna to wykorzystac jako rodzaj komentarza

( (4) ... mozliwe ze tez o inne daleko idace usprawnienia ale to juz rzecz z troche
innej paczki)