Strategy In Strategy

[Sosarian]

nevím jestli takový design pattern existuje, ten název mě napadl jen tak. kazdopadne mam nasledujici problem:

class Model
* hodnota Vertex[] poleVertexu
class StaticModel : Model
class DynamiModel : Model



class GraphicEngine
* metoda void VykresliVertex(int x, int y)
class OpenGL : GraphicEngine
class DirectX : GraphicEngine



je potřeba vykreslit List<Model> list modelu,
Statický model se vykresluje jinak nez dynamický model
(na tohle by se vyuzil klasicky strategy pattern s IDrawable metoda Draw(GraphicEngine g) a kazdy by mel jinou implementaci vykreslovani)

jenomze kazdy model se vykresluje i jinak v zavyslosti na pouzitem grafickem enginu, tzn dohromady existuji 4 ruzne "metody" ktere nejak vykresluji ruzne modely v ruznych enginech. vsechny ovsem berou hodnoty z poleVertexu (a nejak je transformuji na dva inty) a nejakym zpusobem je vykresluji prez VykresliVertex(x, y)

jde mi o to jestli se tohle da vyresit objektove (tzn bez nejaky IFu jako if this is staticmodel, nebo duplicity) kam dat jake metody, jak se maji jmenovat, jake maji mit parametry


(muj problem je veskutecnosti s jiným programem (takze mi prosim nerikejte at pouzivam jen directx ), ale se stejným problémem v architekture, proto me zajima jen jestli je takovyto design pattern v objektovem programovani vubec mozny (mam k dispozici C#))

[Luke]

Pokud se nepletu a dobre jsem te pochopil, tak budes chtit asi neco takovyho:

Model bude mit virtualni metodu Draw(GraphicsEngine), kterou overridnes ve StaticModel a DynamicModel. Podobne GraphicsEngine bude mit virtualni metodu DrawElement (nebo cokoliv jineho), kterou zase overridnes v OpenGL a DirectX tridach.

Predpokladam ze ve StaticModel i DynamicModel budes volat DrawElement nezavisle na tom, jak moc se metody Draw navzajem lisi. A podle toho jaky graficky engine to prave je, tak podle toho se pouzije prave dana implementace metody DrawElement.

Pak kdyz budes vykreslovat list instanci tridy Model, tak se pouzije prave implementace StaticModel nebo DynamicModel podle toho, jak jsi ji vytvoril

[Quiark]

Není na tohle náhodou určen vzor Most?
_________________
Mám strach

[Luke]

Aha, je, sry, nejak jsem to prehlidl, kdyz jsem to tu podruhe cetl. Zapomel jsem na to.

[Sosarian]

jo ten bridge pattern je tomu asi nejbliz, diky


neco podobnyho me napadlo taky ale nechtel sem to tak delat kvuli te naprosto zbytecne radce v
StaticModel::Draw(Graphics graphics)
{
graphics.DrawStaticModel();
}
to stejny bude totiz v DynamicModel, a prakticky to jen "spojuje" ty tridy (proto mozna bridge ze )


nejlepsi by bylo kdyby slo neco jako
Model::Draw(Graphics graphics)
{
graphics.Draw(Model)
}
a tohle by se rozhodlo jestli zavola
Graphics::Draw(StaticModel model)
nebo
Graphics::Draw(DynamicModel model)

ale v C# nejak nefunguje polymorfismus metod (samozrejme vim ze to jde resit reflexi, ale to by nebylo tak viditelny co se vola)

a taky to ma tu nevýhodu ze je pak vykresleni vsech modelu nacpaný v jendé třídě, a v jednom souboru (i kdyz tohle jde taky resit prez partial classy ale to uz muze by trochu divny)

[posila]

Sosarian: Co presne myslis tim polymorfismem metod? Nejvic by mi pomohl nejspis nejaky priklad. Diky

[Sosarian]

[Marek]

Fuj, hnus. Tady ti nezbude nic jinýho, než použít přetypování.

Mimochodem, vykašli se na vzory, když netušíš, jak je použít, přitom všude po netu jsou hotové class diagramy, které to jasně ilustrují, jenom tam dosadit vlastní třídy. Samozřejmě je třeba nejdřív umět OOP, to samo poskytuje dostatečné prostředky pro rozumný objektový návrh a není potřeba vymýšlet blbosti jako polymorfismus metod. Pro OOP i vzory doporučuju přečíst knihu Design Patterns Explained, jsou 2 vydání - to první (z roku 1995 myslím) mi připadá systematičtější, to druhý (z roku 2004) je rozvláčnější, ale možná může být pro začátečníka stravitelnější. Dokud si tuto knihu (nebo ekvivalentní literaturu) nepřečteš, doporučil bych dát od vzorů ruce pryč, budou víc škodit než pomáhat (a jak vidím, už škodí).
_________________
AMD Open Source Graphics Driver Developer

[Sosarian]

2Eosie: nechapu co te vede k tomu ze bych snad neumel OOP nebo pouzivat navrhove vzory, nebo k tomu "Fuj, hnus." ale jestli mas lepsi navrh jak to napsat klidne me porad

[Marek]

Bridge nemá nic přemosťovat, ale jen oddělit od sebe abstrakci od implementace, díky čemuž se zabrání nekontrolovatelnému narustání počtu tříd a nabývání redundantního kódu. Nicméně každý ho dnes automaticky používá ve správných situacích bez toho, aniž by tušil, že se to tak jmenuje. Je to přirozené. Kdyby tento vzor nepoužil, znamenalo by to spíš, že neumí dobře OOP. Vzory beru spíš jako takovou pomůcku právě k výuce OOP a podle mě by neměly být použity způsobem "kterej vzor vyřeší můj problém jednou provždy?" V praxi si myslím, že už se ani moc neřeší, které vzory jsou v návrhu použity. Každej by si měl intuitivně bez vzorů zdůvodnit, proč je danej návrh zrovna vhodný pro ten a ten případ. Tolik k OOP a vzorům. Nevím, jak moc umíš OOP nebo co všechno si pod touto zkratkou představuješ, prostě mi to z těch příspěvku tak nějak vyplynulo.

Poradil bych ti, ale nechápu, o co se snažíš. Co je dynamický model? To je animovaný model? Všechny modely se přece v 3D API dají kreslit stejným způsobem. Pokud se u dynamického modelu mění vertexy, stačí před kreslením aktualizovat obsah vertex bufferu.
_________________
AMD Open Source Graphics Driver Developer

[Ondras]

neni to takhle?

class StaticModel
{
draw();

}

class DynamicModel extends StaticModel
{
//prekryti
draw();
}

[Sosarian]

rikal sem ze nejde o tenhle problem, ze je to jen priklad (jde mi skutecne jen o to jak to navrhnout)
ale jestli chces muzu napsat skutecnej problem

mam seznam msil opkodu (Nop, Call, Stdloc : OpCode), kazdej se do assembleru prepisuje jinak, a mam dve moznosti kterej asm vybrat (masm, nasm : Assembler)

tzn kdyz to prevedu na bridge pattern tak

Imlpementor - Assembler
Abstraction - OpCode

kdyz pak udelam neco jako

[Marek]

Já tam žádnej problém nevidím. Tak se to prostě dělá.
_________________
AMD Open Source Graphics Driver Developer

[Sosarian]

[Marek]

Hm... Asi bych to dělal bez objektů. Udělal bych si pole konstant, kde bych měl vždy ID instrukce očíslováno od nuly. Dále bych si udělal pole, kde indexem by bylo ID instrukce a v tom by byla funkce vyvolávající danou instrukci. Při interpretaci bych pak procházel seznam obsahující ID instrukcí a volal poleFunkci[idInstrukce](); (pseudokód)

Dále bych měl bokem funkce, co by mi toto pole vygenerovalo pro různý assemblery.
_________________
AMD Open Source Graphics Driver Developer