W dniu 2014-02-17 22:09, A.L. pisze:
> On Mon, 17 Feb 2014 17:39:16 +0000, Mateusz Łoskot
> <m...@l...net> wrote:
>
>> On 12/02/2014 15:23, A.L. wrote:
>>> Ogolne "OOP is dead" to jeden z najwiejszych idiotyzmow jakei
>>> spotkalem.
>>
>> No ale jak OOP nie jest dead, jak na pl.comp.objects dzieje się
>> jak w polskim filmie...
>> To tak zaczepnie na koniec dnia, z przymróżeniem oka oczywiście.
>>
>> Pozdrawiam,
>
> Ostatni merytoryzny post byl w roku 2009. Widicznei wszyscy juz
> wszystko wiedza :)
>

Pare lat temu zadalem tam wlasnie takie pytanie... Czy praca Cardelliego
to ostatnie slowo w OO i czy cos nowego sie dzieje. Nikt nie odpowiedzial :)

--
Michal

do góry

firr <p...@g...com>:
> nie jestes gotów na rozmowe, moglbym pogadac ale
> musialaby to byc powazna rozmowa dot techniki, no ale mozemy sprobowac
przedmiotowo, napisz mi jak napisałbyś obiektowo taki program: (tj skladajacy sie z
takich elementów)
>
> 1) okno (typowo winapowskie, setup okna)
> 2) pixelbufor (kontener z pixelami)
> 3) blitter (funkcja do blitniecia pixelbufora do obszaru klienta okna)
> 4) jakies elementarne handlery dla myszy i klawiatury (powiedzmy ze kod podpiety
pod eventy myszy miałby robic rysowanie pixeli w oknie, tj
> w pixelbuforze ktory jest pozniej blitowany do okna)
>
> nie chodzi mi o sam kod, mozesz wykropkowac //...
> ale o obiektową formę, (mozesz podzielic na dowolne
> obiekty wg uznania alechailbym zobaczyc jak to by wygladalo (najlepiej w postaci
kodu oop w jawie) ))

Nie jestem specem od OOP, ale może jakoś tak?

#v+
class Pixelbuffer {
// klasa zawierajaca bufor obrazu.
};

class Window {
private:
MouseHandler& m;
KeyboardHandler& k;

public:
// wspolne funkcje, istniejace dla kazdego okna

// dodaje handler do okna
void addMouseHandler(Handler& h);
void addKeyboardHandler(Handler& h);
void draw(Costam& cos);
};

class Blitter {
// interfejs
};

class HardwareBlitter: public Blitter {
void blit(Window& win, Pixelbuffer& buf) {
// rysowanie na oknie przy pomocy hardware, OpenGL?
}
};

class SoftwareBlitter: public Blitter {
void blit(Window& win, Pixelbuffer& buf) {
// rysowanie na oknie przy pomocy software, putPixel?
}
};

class QuickBlitter: public Blitter {
void blit(...) { // jak wyżej
// rysowanie w oknie tylko zmienionych obszarów
}
};

// niekoniecznie podział na hardware/software blitter, może być np.
// DebugBlitter, zbierający info o prędkości blitowania, czy coś takiego

class Handler {
// wspolne funkcje dla roznych implementacji konkretnych handlerow
// moze byc tez interfejs ;)
};

class MouseHandler: public Handler {
void onClicked(Slot& callback, Point& position) {
callback.emit(position);
}

// onLeftDown, onLeftUp, etc
};

class KeyboardHandler: public Handler {
void onKeyPressed(Slot& callback, Key& key) {
callback.emit(key);
}

// onKeyDown, onKeyUp, etc
}:

class Game {
private:
Pixelbuffer p;

Blitter& blit;
Window& w;

public:
Pixelbuffer& getBuffer() { return p; }

void blit() {
// dla każdego obiektu w grze, renderuje pixelbuffer dla tego obiektu
// też może być wprowadzony podział na klasy software/hardware rendering
blit.blit(w, p);
}

void run() {
while(! done) {
doGame();
blit();
}
}
};

----

int main() {
Pixelbuffer p;
Game game(p);
HardwareBlitter blit; // lub: SoftwareBlitter, QuickBlitter, lub inne blittery
Window gameWindow;

game.addWindow(gameWindow);
game.setBlitter(blit);

MouseHandler m;
KeyboardHandler k;

gameWindow.addMouseHandler(m);
gameWindow.addKeyboardHandler(k);

m.onClicked([&] (Point& mousePos) {
game.addSomeObject(mousePos);
});

gameWindow.show();
game.run(); // działa, np. dopóki gameWindow istnieje
return 0;
}
#v-

Sorry, że nie Java, nie pamiętam jej składni ;)

do góry

>
> Nie jestem specem od OOP, ale może jakoś tak?

troche pozniej zobacze i odpowiem

do góry

>
> troche pozniej zobacze i odpowiem

ok, rzucilem pobieżnie okiem, pozniej spojrze jeszcze raz i odpowiem (ten podział na
blittery bym wykasował,
(dla uproszczenia) mozesz moze w miedzyczasie

1) wyciac te inne blitery i zostawic tylko jeden i jeszcze raz wkleic zrodło w
uproszczonej wersji ?
2) upewnic sie ze to w sensie runtime dzialalo by
poprawnie, tj ze wszystkie obiekty sie w tym kodzie potworza i ze te referencje midzy
nimi beda tez poprawnie ustawione ? [na tym mi glownie zalezy by to odwzorowanie
obiektowe bylo napisane tak ze jest
na pewno _poprawne_w_runtime_],

do góry

firr <p...@g...com>:
> >
> > troche pozniej zobacze i odpowiem
>
> ok, rzucilem pobieżnie okiem, pozniej spojrze jeszcze raz i odpowiem (ten
> podział na blittery bym wykasował, (dla uproszczenia) mozesz moze w
> miedzyczasie
>
> 1) wyciac te inne blitery i zostawic tylko jeden i jeszcze raz wkleic zrodło
> w uproszczonej wersji ?

Chcesz powiedzieć, że nie chce Ci się usunąć kilku linijek?

> 2) upewnic sie ze to w sensie runtime dzialalo by poprawnie, tj ze wszystkie
> obiekty sie w tym kodzie potworza i ze te referencje midzy nimi beda tez
> poprawnie ustawione ? [na tym mi glownie zalezy by to odwzorowanie obiektowe
> bylo napisane tak ze jest na pewno _poprawne_w_runtime_],

Ale miało być schematycznie, czy "poprawnie w runtime"? Programowac prostego
proof-of-concept niestety nie mam czasu, a nawet jakbym miał, to szczerze
powiem, by mi się nie chciało ;)

Nie rozumiem też "powtarzania się wszystkich obiektów" i poprawnie ustawionych
referencji. Gdy referencja nie będzie ustawiona, to kompilator już zgłosi
problem, więc nie ma się co martwić o runtime. Inna sprawa, że można ustawić
referencję obiektu na adres 0, ale raczej tylko wtedy, gdy zrobi się
dereferencję wskaźnika danego obiektu, który aktualnie przyjmuje adres 0. Ale w
przykładzie wskaźników nie ma, więc tym też nie ma się co martwić ;)

Obiekt blittera właściwie też bym wykasował, ale miało być z blitterem. Sam
podział na wiele blitterów ma odblokować możliwość dostarczenia do programu
opcji wykorzystania software lub hardware (lub innych stylów blittera), za
pomocą prostej podmiany aktualnego obiektu blittera.

do góry

W dniu wtorek, 18 lutego 2014 13:18:56 UTC+1 użytkownik toslaw napisał:
> firr <p...@g...com>:
>
> > >
>
> > > troche pozniej zobacze i odpowiem
>
> >
>
> > ok, rzucilem pobieżnie okiem, pozniej spojrze jeszcze raz i odpowiem (ten
>
> > podział na blittery bym wykasował, (dla uproszczenia) mozesz moze w
>
> > miedzyczasie
>
> >
>
> > 1) wyciac te inne blitery i zostawic tylko jeden i jeszcze raz wkleic zrodło
>
> > w uproszczonej wersji ?
>
>
>
> Chcesz powiedzieć, że nie chce Ci się usunąć kilku linijek?
>
>
>
> > 2) upewnic sie ze to w sensie runtime dzialalo by poprawnie, tj ze wszystkie
>
> > obiekty sie w tym kodzie potworza i ze te referencje midzy nimi beda tez
>
> > poprawnie ustawione ? [na tym mi glownie zalezy by to odwzorowanie obiektowe
>
> > bylo napisane tak ze jest na pewno _poprawne_w_runtime_],
>
>
>
> Ale miało być schematycznie, czy "poprawnie w runtime"? Programowac prostego
>
> proof-of-concept niestety nie mam czasu, a nawet jakbym miał, to szczerze
>
> powiem, by mi się nie chciało ;)
>
>
>
> Nie rozumiem też "powtarzania się wszystkich obiektów" i poprawnie ustawionych
>
> referencji. Gdy referencja nie będzie ustawiona, to kompilator już zgłosi
>
> problem, więc nie ma się co martwić o runtime. Inna sprawa, że można ustawić
>
> referencję obiektu na adres 0, ale raczej tylko wtedy, gdy zrobi się
>
> dereferencję wskaźnika danego obiektu, który aktualnie przyjmuje adres 0. Ale w
>
> przykładzie wskaźników nie ma, więc tym też nie ma się co martwić ;)
>
>
>
> Obiekt blittera właściwie też bym wykasował, ale miało być z blitterem. Sam
>
> podział na wiele blitterów ma odblokować możliwość dostarczenia do programu
>
> opcji wykorzystania software lub hardware (lub innych stylów blittera), za
>
> pomocą prostej podmiany aktualnego obiektu blittera.

mialo byc schematycznie ale na 100% poprawnie w runtime (tj schematycznie o tyle ze
nie trzeba wypelniac wnetrze funkcji poprawnym kodem ale
pozatym chcialbym by bylo ok)

moge wywalic te blittery ale to przeciez ty robisz
ten schemat nie ja, ja moge doprecyzowac tylko o co mi chodzi

do góry

firr <p...@g...com>:
> mialo byc schematycznie ale na 100% poprawnie w runtime (tj schematycznie o tyle
ze nie trzeba wypelniac wnetrze funkcji poprawnym kodem ale
> pozatym chcialbym by bylo ok)
>
> moge wywalic te blittery ale to przeciez ty robisz
> ten schemat nie ja, ja moge doprecyzowac tylko o co mi chodzi

Zignorowałeś więszkość mojego ostatniego posta, więc napiszę inaczej:

Jest 100% poprawnie w runtime :)

do góry

W dniu wtorek, 18 lutego 2014 15:27:41 UTC+1 użytkownik toslaw napisał:
> firr <p...@g...com>:
>
> > mialo byc schematycznie ale na 100% poprawnie w runtime (tj schematycznie o tyle
ze nie trzeba wypelniac wnetrze funkcji poprawnym kodem ale
>
> > pozatym chcialbym by bylo ok)
>
> >
>
> > moge wywalic te blittery ale to przeciez ty robisz
>
> > ten schemat nie ja, ja moge doprecyzowac tylko o co mi chodzi
>
>
>
> Zignorowałeś więszkość mojego ostatniego posta, więc napiszę inaczej:
>
>
>
> Jest 100% poprawnie w runtime :)

spoko, nie ma sprawy, chodzi mi tylko o to by to byl 'funkcjonalny' przyklad - chyba
jest funkcjonalny, nie mialem jeszcze czasu dokladniej spojrzec ale niedlugo (przed
wieczorem) zobacze

ew ktos jeszcze z tej grupy moze skrytykowac czy to jest poprawny op i wniesc jakies
poprawki

do góry

#v+
////////////////////////////////

class Pixelbuffer {
// klasa zawierajaca bufor obrazu.
};

/////////////////////////////////////

class Window {
private:
MouseHandler& m;
KeyboardHandler& k;

public:
// wspolne funkcje, istniejace dla kazdego okna

// dodaje handler do okna
void addMouseHandler(Handler& h);
void addKeyboardHandler(Handler& h);
void draw(Costam& cos);
};

////////////////////////////////////////

class Blitter {
void blit(Window& win, Pixelbuffer& buf)
{
///...
}
};

////////////////////////////

class MouseHandler: public Handler {
void onClicked(Slot& callback, Point& position) {
callback.emit(position);
}
};

/////////////////////////////////

class Game {
private:
Pixelbuffer p;

Blitter& blit;
Window& w;

public:
Pixelbuffer& getBuffer() { return p; }

void blit() {
// dla każdego obiektu w grze, renderuje pixelbuffer dla tego obiektu

// też może być wprowadzony podział na klasy software/hardware
rendering
blit.blit(w, p);
}

void run() {
while(! done) {
doGame();
blit();
}
}
};

/////////////////////----

int main() {
Pixelbuffer p;
Game game(p);
HardwareBlitter blit; // lub: SoftwareBlitter, QuickBlitter, lub inne
blittery
Window gameWindow;

game.addWindow(gameWindow);
game.setBlitter(blit);

MouseHandler m;
KeyboardHandler k;

gameWindow.addMouseHandler(m);
gameWindow.addKeyboardHandler(k);

m.onClicked([&] (Point& mousePos) {
game.addSomeObject(mousePos);
});

gameWindow.show();
game.run(); // działa, np. dopóki gameWindow istnieje
return 0;
}
#v-

wycialem by bylo drobinke prosciej, wiadomo ze mozna rozbudowywac

do góry

najdziwniejszy wydaje mi sie tu ten kawałek z mouse handlerem - objekt ktory dodajesz
do objektu okna (by w nim samym ustawic wybrana metode z obiektu game)

czy tak sie normalnie robi? (w .netcie czy gdzies ?)

pozniej mam pare innych uwag co do tego przykładu

do góry