Dotaz: Design Patterns

[iwtu]

Zdravím. Návrhových vzoroch je pomerne mnoho, no nepredpokladám, že sa všetky masívne používajú v praxi. Ktoré návrhové vzory používate v praxi?

Vďaka za odpovede.

---

---

Odpovědi

[rADOn]

Pochybuju ze to jde nejak pausalizovat, zalezi na tom co resis nejcasteji za ulohy a v jakem jazyce.

[Josef Kufner]

Na použitém jazyce celkem dost záleží. Mnohé návrhové vzory existují jen kvůli tomu, aby zalepily neschopnost jazyka (Javy) se vyjádřit.

Asi nejčastěji narazíš na Singleton, což je jen objektový obal na globální proměnnou (= zlo, vyhni se tomu).

Všelijaké Factory třídy a metody jsou vcelku oblíbené a užitečné, když není vhodné volat konstruktor přímo, třeba protože nevíš jaký nebo to je moc složité. Celkem dobré je s tím nahradit ten Singleton.

Observer potkáš všude možně, kde jsou události a jejich obsluhy (a nepoužívají se Callbacky).

Různé věci jsou skoro i samozřejmostí, jako třeba Iterator, jiné se prostě hodí jen na něco, ale bez nich se to něco řeší těžko, např. Proxy, Interpreter či Front controller.

Koukni na Wikipedii, tam je toho spousta o tomhle a taky celkem hezký seznam.

Pak také hodně užitečnou je dependency injection.

A v neposlední řadě se občas hodí i různé Service oriented architektury, jenž nemusí být nutně postavené na HTTP a XML. V jednom programu napsaném v C jsem měl tabulku (pole struktur) s názvy komponent (char) a pointery na funkce. Zpracování zpráv pak zajišťovala dvouřádková funkce, která podle názvu cílové komponenty předala zprávu ke zpracování (zavolala funkci přes pointer v tabulce).

[l4m4]

Asi nejčastěji narazíš na Singleton, což je jen objektový obal na globální proměnnou (= zlo, vyhni se tomu).

To je zase kec. Singleton je objektový obal na věc, která je globální a unikátní, i kdybys nechtěl. Například program sám: můžeš se stavět na hlavu, ale program bude mít jeden pid, jeden argv, etc.

[Josef Kufner]

... která je globální a unikátní ...

Jo ... globální proměnná. Prostě jen jiný název pro totéž. Sám to píšeš

Na jednu stranu se tomu nevyhneš úplně a ten jeden tam bude vždy. Ale na druhou, můžeš to postavit tak, že pid, argv a další věci (třeba i ten singleton samotný) si jen posbíráš na začátku a pak vyrobíš instanci třídy Application. Vše jí předáš a ta už pak nemusí singleton ani zahlédnout (ten předaný singleton už pro ni nebude singleton, ale obyčejný parametr).

[l4m4]

Třída Application (a) je singleton (b) reálně se používá jako singleton, akorát to programátor z ideologických důvodů není ochoten přiznat (c) je zcela chybně pojmenována, protože jí může jedna aplikace mít více instancí.

[Josef Kufner]

To, že existuje jen jedna instance té třídy neznamená, že to je singleton.

Původně se mi nechtělo psát s příkladem, ale asi není zbytí... (psáno ve skoro-C++)

class Application {
  Application(argv) {
    // nějaká ta inicializace, zpracování parametrů
  }
  int execute() {
    // tady je aplikace (mimo konstruktor, aby bylo
    // možné nastavit další parametry)
  }
}

// Zavaděč aplikace
int main (argv) {
  Application a = new Application(argv);
  return a.execute();
}

Jak vidíš, není tam žádný singleton. Funkce ::main() by ho mohla trošku připomínat, ale je to jen jednoduchý zavaděč, aby jádro mohlo někde začít se spuštěním.

Třída Application také není singleton, neboť není nijak zaručeno, že nemůže existovat více než jedna instance, ani není jak takovou instanci získat.

Application asi není příliš vhodný název, možná by se hodilo spíš něco jako MainWindow, ale to záleží na tom, k čemu Application je.

Také nám nic nebrání spustit více instancí, třeba otevřít více dokumentů najednou nebo provést paralelně několik výpočtů:

int main(arg) {
  ThreadPool tp;
  foreach (i in arg) {
    Application a = new Application(arg[i]);
    tp.executeInNewThread(a);   // tp zavolá a.execute()
  }
  return tp.waitForAllThreads();
}

[Radek Miček]

Sdílený stav (například globální stav nebo stav instance třídy) zhoršuje mj. testovatelnost a znovupoužitelnost kódu. Navíc ve většině programovacích jazyků nejste schopen na první pohled odlišit, jaké části kódu na něm závisí a jaké už ne.

Sdíleným stavem nemyslím data, jenž jsou konstantní po celý běh programu a přes všechny běhy programu.

[l4m4]

To že se vám to nelíbí, už jste jednou vysvětlili a jistě ochotně mnohokrát zopakujete. Jenže cokoli, co representuje/řídí zdroje/data, které jsou zvnějšku globálně omezeny pro program jako celek, bude fungovat jako singleton, ať už se vám to líbí, nebo ne, a to je to, o co tu jde.

[Radek Miček]

Singleton je špatný protože se fixujete na konkrétní věc. Pokud mám závislost na globálních datech, tak je tam mohu předat zvenčí aniž bych se na něco fixoval případně mohu použít proměnné s dynamickým rozsahem platnosti (např v CL).

[JS]

Osobne mi pripada, ze dynamicke promenne jsou lepsim resenim nez singleton. Bohuzel na jejich implementaci asi zadny pattern neni (podobne jako neni na jinou CL vychytavku, signaly a restarty). To naznacuje, ze videni sveta "v patternech" omezi cloveka jen na koncepty z urcitych jazyku.

[vogo]

Hodně záleží na tom, co řešíš, podle toho by jsi měl zvolit návrhový vzor. Já třeba v poslední době použil Abstract factory, Singleton, Wrapper, před nedávnem jsem se vrtal v nějakých záležitostech implementujících Observer.

Každopádně z toho neusuzuji, že ostatní návrhové vzory se nepoužívají, spíše nebyly vhodné (správné) pro řešený problém. A jen tak na okraj: poud se člověk (programátor) v návrhových vzorech nevyzná, neměl by je při řešení problému za každou cenu používat. Mnohdy nevhodný návrhový vzor znemožní zdárené vyřešení problému. Stejně tak není rozumné cpát návrhové zvory úplně všude, potom je z toho kanón na vrabce, který nikdy nevystřelí.