Programátoři ve funkcionálních jazycích nepoužívají terminologii návrhových vzorů. Používají stejné mechanismy, ale mají pro ně jiné názvy. Jednomu by se pak mohlo zdát, že design patterns jsou zbytečné, ono to tak není. Spíš funkcionální jazyky, tím, že jsou expresivnější, než jazyky objektové, můžou takový dojem pouze vytvářet.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
Zajímavé postřehy
Díky za článek, jsou v něm zajímavé postřehy, které mě při přechodu k FP ani nenapadly – prostě v FP jsem jaksi ztratil důvod hledat a používat návrhové vzory. Ty tam samozřejmě jsou, ale asi je nikdo neměl potřebu pojmenovat :-)
Tak mě napadlo – v mnoha FP jazycích se dost používají DSL, to je asi taky „mapovatelné“ na pár návrhových vzorů ne?
Re: Zajímavé postřehy
Potřebu pojmenovat samozřejmě někdo měl – celý koncept design patternů byly navrženy právě k tomu, aby se sjednotila terminologie napříč jazyky a kulturami. Autoři si od toho slibovali překlenutí komunikačních problémů
Je zřejmé, že celý záměr fatálně ztroskotal. Stejně jako v reálné (mezinárodní) politice – znesvářené strany prostě domluvit nechtějí.
Trochu více návrhových vzorů, ale v Haskellu: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/
Přiznám se, že mě překvapilo, když jsem zjistil (*), kolik lidí pod návrhovým vzorem vidí jen konkrétní implementaci v konkrétním jazyce. Pro mě vždycky byly, alespoň většina z nich, čistě architektonickou záležitostí.
*) Už dřív, ne přímo ve spojitosti s tímto článkem
Re:
V návrhovém vzoru nevidím jen čistě implementaci. Spíš vidím v návrhovém vzoru pojmenování vzorového řešení.
A ta řešení pak můžou vypadat ve zdrojácích různě. Já jsem se snažil srovnat, jak se potom ty projekce do reality v jednotlivých paradigmatech liší.
Re:
Však to nebylo myšleno na vás, ale na autory různých výkřiků „Ve funkcionálním programování / Ruby / Pythonu / … návrhové vzory nepotřebujeme!“ – jako je třeba ten „kopanec“ uvedený na začátku článku.
Singleton
Dovolil by som si tvrdit, ze dependency injection kontajnery nezrusili dolezitost singletonu prave naopak.
Clovek si moze byt isty, ze dostane vzdy tu istu instanciu ked zavola bean s rovnakym id hocikde v aplikacii.
Re: Singleton
To je dost specificky pozadavek na to, co se ma injektovat. Vetsinou nic takoveho nechci. Proc taky?
Re: Singleton
A proc ne?
To je dost caste pouzitie, ze je vytvorena z triedy len jedna bean-a a autowiringom sa injektne.
Re: Singleton
Tak ono to tak, technicky vzato, vetsinou dopadne. Ale neni to nic, co bych extra chtel. Proc bych mel? Ve vetsine pripadu je mi to totalne jedno, i kdyby se pokazde udelala nejaka nova instance, tak by to nemelo na funkci vliv.
Singleton
No, ale už to není singleton. Je to jen ta samá instance.