Žere mi to příspěvky (než to dopíšu, tak mě to odhlásí a příspěvek je v čudu), tak nemám náladu to posiovat, tak krátce.
---
Blek:
právě, že myš je v 99% klasická myš. 3D myš je jiný objekt - slouží k něčemu jinému.
naopak většina myslivců má dva psy a myslivec s jedním psem se v účelu neliší.
(třeba otázka - když uživatel klikne současně do víc oken, má se event rozdvojit a doručit více oknům nebo se má doručit do okna kam kliknul dříve nebo do okna, které leží v těžišti těch všech kliknutí, nebo...?)
No právě, todle je problém právě, když žádné takové rozhraní není. Protože pak každý multitouch implementuje to jednoklikové rozhraní jinak. Takže nějaká konzistentnost UI je v háji.
Naopak, pokud mám rozhraní pro multitouch, tak není problém napsat jednoduchou emulační vrstvu pro onetouch. A ta jednoduchá emulace bude zpracovávat jak pravá onetouch device, tak i např. první klik z multitouch. A aplikace se může rozhodnout, jestli použije složitější rozhraní pro multitouch, nebo jednodušší rozhraní pro onetouch. Bude však všechno konzistentní a předvídatelné. A ani implementátři ovladačů ani kodéři aplikací nebudou muset napsat řádku navíc....
Pro Ondru: Je to ale opět rozdíl mezi onepsem a multipsem: zatímco myslivec zůstává myslivcem, ať už má jednoho nebo více psů, podstata myslivcovství není v tom mít jednoho nebo více psů, Podstata one/mulitouch device je ale v příjmání právě jednoho či více kliků.
Pokud by existovalo něco jako svébytný myslivec s jedním psem, pak by rozhraní pro něho mělo smysl. Nedovedu si ale v praxi představit situaci, kde by opravdu se vyskytoval právě jen myslivec s jedním psem....
---
Ondra:
Rozdíl je ten, že u 99% formulářů (takže zbylé mohu považovat za jinou entitu) je jasné, co znamená odešli se. Naopak polovina myslivců, když je požádám o psa, tak se zeptaj: a kterýho?
--
1) Pokud navrhnu rozhraní reusabilně, pak ten poměr není 1:n
2) Právě proto, že ten poměr je 1:n :-) tak je daleko lepší přizpůsobit clienta (ten co používá) než server (ten co implementuje). Protože u klienta ho musím upravit na jednom místě, zatímco u serveru budu muset upravit vždy každý nový objekt, který rozhraní bude používat.
Když budu mít objekt, který požaduje chrochtající sedminohé zvíře a budou k nim chodit pes, kočka, člověk, prase a roboprase, tak daleko jednodušší je u toho klienta počítat s tím, že přijde ISavec, než u každého zvířete implementovat, jak má kamuflovat sedm nohou a chrochtání.
Navíc tak získám užitečné rozhraní ISavec, které použiji daleko spíš než sedminožku a ještě navíc se v praxi ukazuje, že potřebuji-li obskurní rozhraní, něco jsem blbě navrhnul.
Rozhraní se proto podle mě mají navrhovat nikoli čistě podle potřeb klienta, ale podle předpokládaných serverů. Kdybych ještě přitvrdil, tak řeknu, že servery inherentně nesou kopy "abstraktních" rozhraní, podle toho, kdo jsou (např člověk je humanoid, savec, pojmenovávatelný, okradnutelný.....). Klient si pak pouze "vybírá" rozhraní ze všech dostupných. A má li vybráno, pak to abstraktní rozhraní jen programátor "konkretizuje" zapsáním do kódu. Tzn. ne že programátor rozhraní vytváří, ale akorát popisuje patřičné charakteristiky objektů. Asi jsem platónista.
Např. pořádám hon. Pokud bych použil čistě pragmatické navrhování (dle potřeb klienta), tak řeknu - ok, na honu potřebují pušku a psa. V půlce vývoje ale zjistím, že na vysokou se střílí kulovnicí, zatímco na kachny brokovnicí. A při předání mi řeknou, ale franta má dva psy a vždycky vystřelí z obou hlavní a pro každou kachnu pošle jednoho, to jsme Vám neřekli?
Naopak pokud navrhuji podle serverů, tak si řeknu. Kdo chodí na lovy? No myslivci. A co je důležitého na myslivci ve vztahu k honu: no flinta a pes. Jak je na tom myslivec s flintou a psem? No má jich X. Potřebuji je rozlišovat? No zákazník nic neříkal, tak zatím budu střílet z první flinty a posílat prvního psa....
Hmm, říkal jsem krátce :-( :-)
235 Odpovědí
82152 Zhlédnutí