Ááá

Komentářů už je 7. :-) to “Co mám proti MVC”

1. David Grudl Posted: Kvě 24th, 2009 at 20.16

   1 > Já bych mluvil o soustavě stránek, na kterých jsou odkazy a formuláře, jejichž odkliknutím lze vykonat nějakou akci a případně přejít na jinou stránku. Taky tak o stránkách uvažuju. Jen místo stránka v poslední době používám „presenter“, ve slově „akce“ se shodujeme.

2. v6ak Posted: Kvě 25th, 2009 at 6.22

   2 Čekal jsem pod tímto titulkem mnoho věcí, ale toto teda ne. Zkus nechat BFU navrhnout web. (Vím, trochu složitá představa…) A pak zkus ho nechat udělat nějakou v MVC jednoduchou změnu… Nejsem si jist, že účel abstrakcí je přístupnost každému blbovi. Hlavní účel je možnost velkých změn s malými náklady. Pokud přijmeš tento účel MVC, bude se ti IMHO hned zdát lepším – tento účel už v rámci možností plní, ne? Koneckonců, zákazník taky možná bude chtít „změnit jen toto“ – něco, co bez MVC znamená překopání. A nebude ho moc zajímat použitá architektura. Prostě programování asi nebude pro každého blba, nebo bude, ale projeví se to na kvalitě.

3. LLook Posted: Kvě 26th, 2009 at 19.46

   3 Author Comment Podle mě hlavní účel abstrakcí je zpřístupnění. Aby (ideálně) každému bylo rychleji jasné, co daný kód/diagram/kon­figurák/ikonka/kdo­víco vlastně dělá. Přístupnost každému blbovi je nedostižný cíl, který ale udává směr. Programátor slouží jako překladatel mezi zadáním a implementací. Čím podobnější si jazyk zadavatele (třeba toho BFU) bude s jazykem implementace, tím snazší ten překlad bude. Úspěšné programovací jazyky vycházejí do vysoké míry z lidské řeči, kód lze kolikrát číst skoro jako román (od hodně trhlého autora, ovšem). To samé dotazovací jazyky – SQL vytlačilo ostatní řešení, protože mu bylo lépe rozumět. Já přijímám MVC/MVP jako nepříliš vhodnou architekturu, jejíž nedostatky jsou ale vykoupeny existencí perfektních nástrojů, jako je Nette nebo ASP.NET MVC. Kdyby někdo podobným způsobem vymazlil řešení na vzoru Page Controller, to by byla bomba. Kdyby tu frameworky nebyly a já bych si musel psát vlastní, MVC by to nejspíš nebylo. Taky tak o stránkách uvažuju. Jen místo stránka v poslední době používám „presenter“, ve slově „akce“ se shodujeme. Já bych řekl, že v Nette se místo „stránka“ říká „Presenter:ak­ce“, ne?

4. v6ak Posted: Kvě 27th, 2009 at 12.43

   4 > Podle mě hlavní účel abstrakcí je zpřístupnění. Kde's na tom byl? Hlavní účel abstrakce je obecnější použitelnost. Naopak, srozumitelnost tím pro některé lidi klesá. To už není chyba, ale vlastnost. Můžeme si to ukázat na vaření čaje na sporáku. Naleju do konvice vodu. Postavím konev na hořák. Pustím plyn a zápálím oheň pod konvicí. Čekám, dokud voda nevaří. Vypnu plyn. Dám do hrnku pytlíky na čaj. // gurmánům se za ty pytlíky omlouvám Počkám daný čas a pak vytáhnu pytlíky na čaj. Myslím, že tento návod je srozumitelný zhruba tolika lidem, kolik jich umí česky. Jenže, ačkoli to lze napsat ještě konkrétněji, je to napsané už příliš konkrétně. (To, že neřeším, kde vezmu konev, pytlíky apod. nebo že plynový sporák odkrývá implementační detaily, takže jej nelze tak snadno vyměnit za elektrický, teď neřeším.) Ale mám tu kandidáty na znovupoužitelnost: Můžu oddělit vaření vody. Ale proč to specializovat na vodu? Podobně můžu zacházet s víceméně jakoukoli kapalinou (detaily neřeším a odmítám zodpovědnost za škody vzniklé jakýmkoli pokusem toto demonstrovat). Asi se mu zde bude hodit továrna na ? extends Kapalina Pokud bychom zapouzdřili sporák, pak by toto taky šlo parametrizovat a mohl bych vařit i třeba v rychlovarné konvici. I tím lze uvařit vodu na čaj. Zodpovědnost za registraci handleru pro uvařenou kapalinu bych přenechal Ohřívači. Potřebuji zde strategii na to, zda je kapalina dostatečně ohřátá. Vidíš, nemusím ani vařit, můžu jen chtít ohřát kapalinu podle nějakých pravidel. // Za aktivní čekání se omlouvám. Musím pracovat s pytlíky? Nestačí mi, že jde o něco uchopitelného a ponořitelného do dané kapaliny a za těch podmínek ohřívání to půjde opět vytáhnout? … Zatím to asi bude stačit. Tomuto říkám abstrakce. Určitě to zlepšuje znovupoužitelnost. Ale, zkus takovýto návod (po abstrakci) sepsat a někomu (neprogramátorovi) ukázat. (Opět odmítám nést zodpovědnost za následky – zvlášť v případě, že je nablízku psychiatrická klinika

5. David Grudl Posted: Čer 2nd, 2009 at 8.43

   5 V Nette se těsně před (nebo po?) prvním uvolnění přejmenovalo Page: na Presenter: a přidalo „akce“. Úprava terminologie jako vstřícný krok expertům, přidání akcí kvůli reptalům. S odstupem času jsem narazil na situace, kde se akce skutečně hodí a kde termín Presenter je vhodnější než Page. > Kdyby někdo podobným způsobem vymazlil řešení na vzoru Page Controller, to by byla bomba. Tomu celkem rozumím Viděl jsem to úplně stejně, jenže postupným mazlením Page Controlleru mi právě vznikl Presenter.

6. LLook Posted: Čer 2nd, 2009 at 21.29

   6 Author Comment [5] Kdyby se Presenter jmenoval Page, tak by to bylo dost zavádějící, protože stránkám spíše odpovídají ty akce. [4] Ten první návod je nízkoúrovňový (relativně) popis postupu. Lze využít generalizující abstrakce, zapouzdřit ho do metody a dál o tom mluvit jen jako o „uvařit čaj“. Pokud nemám/nechci jiné možnosti, tak tohle je ta nejvhodnější abstrakce. Pokud mám vedle sporáku ještě třeba mikrovlnku, můžu přidat metodu „uvařit čaj v mikrovlnce“. Nebo tyhle dvě metody abstrahovat do jedné rozvětvené („uvařit čaj na sporáku nebo v mikrovlnce“), pokud mi to přijde přirozenější. Ale také nemusím, pokud se rozhodnu, že vařit vodu budu vždy na sporáku, tak bych jenom přidával další zbytečné vrstvy. Tvoje rozšíření znovupoužitelnost určitě nezlepší. Sice dostaneš víc možností, ale mnohem hůř se s tím pracuje (špatně se to znovupoužívá). Potřebuje to pořádný refaktoring. Mimochodem si teď uvědomuju, že kuchařské knihy poskytují skvělé příklady různých návrhových vzorů. Například formulace typu „připravte vývar jako v receptu 123“ představují vyčlenění metody, formulace typu „přiveďte vodu k varu“ zase představují programování proti rozhranní, věta „místo cukru můžete použít med“ je aplikací Strategy… Ony i ty návrhové vzory vycházejí z toho, jak lidé běžně přemýšlí. Ale dost filozofování, to je trochu mimo můj záběr. Prostě jsem chtěl říct, že MVC/MVP nutí programátorovi dost nepřirozený pohled na webovou aplikaci a že je to podle mě špatně. Ale ne zas tak špatně, abych se s tím nesmířil.

7. v6ak Posted: Čer 23rd, 2009 at 11.58

   7 Tak jsem se k tomu komentáři konečně vrátil. "zapouzdřit ho do metody a dál o tom mluvit jen jako o "uvařit čaj"" Jasně, toto je popis té metody… „Nebo tyhle dvě metody abstrahovat do jedné rozvětvené (“uvařit čaj na sporáku nebo v mikrovlnce"), pokud mi to přijde přirozenější." O větvení metod si nemyslím moc dobrého. IMHO je lepší využít polymorfismus. Pokud nechci dát nikomu možnost udělat si vlastní implementaci, udělám private class s package private konstruktorem a ten bude tvořit předka implementacím. „Tvoje rozšíření znovupoužitelnost určitě nezlepší.“ Proč? Teď to můžu použít na ohřívání mléka (jiná detekce, že je hotovo, a jiná látka) bez opakování kódu (copy&paste programming). „Sice dostaneš víc možností, ale mnohem hůř se s tím pracuje“ Můžu udělat třeba něco ve stylu static factory method a pracuje se mi s tím úplně stejně jako před refaktoringem, pokud nepotřebuju jeho výhody (mléko, …). „Mimochodem si teď uvědomuju, že kuchařské knihy poskytují skvělé příklady různých návrhových vzorů.“ Zajímavý postřeh. Tady by byl i jiný možný příklad. Představ si vztah zákazník-tvůrce-tvůrcovy pomůcky. Zákazník je jasný, tvůrcem může být např. kuchař nebo programátor a do pomůcek patří vše, s čím pracují – od nástrojů (vařečka, počítač, …) přes suroviny (proud, voda, …) až po procesy, rady a zásady (design patterns, best practices, vlastní zkušenosti, …). A teď ten postřeh: zákazníka zajímá pouze komunikace s tvůrcem, ne však jeho pomůcky. Když tvůrce komunikuje se zákazníkem, nevystatuje mu zpravidla tyto detaily. Tak, jako kuchař nemluví se zákazníkem o tom, jestli použije med nebo cukr, případně o nějakých postupech apod., ale přesto to musí řešit, tak programátor se zákazníkem neřeší MVC ani jinou architekturu, ale musí něco použít. Jinak Strategy je někdy super, ale zde zavání větvením a radši bych použil např. Factory. MVC/MVP nutí programátorovi jiný pohled na věc, než má zákazník, ale na tom není nic zvláštního. Stejně tak by's mě asi nepustil k vaření, jako by's nepustil … k programování. Co je na tom špatného? Vždyť MVC se ujalo/ujímá právě kvůli výhodám v budoucnu při přepisování.