JS, poprosim k Vasim tvrdeniam literaturu. Funkcionalne programovanie je momentalne moje hobby, a rad by som si teda precital.
Nejsem si jisty, zda k tomu existuje formalni literatura - je to trochu mimo oblast zajmu akademiku, hadat se o OOP. :-)
Ale klasika na tohle tema je Norvig
http://www.norvig.com/design-patterns/design-patterns.pdf a pak jsem nasel tenhle blogpost
http://blog.ezyang.com/2010/05/design-patterns-in-haskel/ (coz obcas pouziva trochu slozitejsi koncepty, ale vsechno jsou to v podstate zase jen kombinace funkci).
IMHO ale nejlepsi je trochu se naucit Haskell. Cloveka to trochu hodi do vody, a je z toho pomerne zrejme, proc se v FP veci delaji jak se delaji; v jinych jazycich, ktere jenom prejimaji prvky FP (treba Scala nebo Java) mohou nektere veci vypadat podivne. No a kdyz ziskas trochu zkusenost, uvidis sam, jak se ty veci, na ktere se ptas, daji realizovat pres skladani funkci, bude ti to proste pripadat prirozene a naopak pristup pres tridy a interfacy uvidis jako zbytecne tezkopadny. (Bohuzel se to tezko sdeluje..)
o tom, ako je enkapsulacia zbytocna
Uz jsem to trochu naznacil v jednom z predchozich prispevku, dalsi moznost v FP (ktera se taky casto praktikuje, jak uz jsem psal driv) je jista forma inversion of control. Napr. mam-li strukturu (objekt) s tremi poli A, B a C, a potrebuji neco provest jen s A a B. V OOP bych mohl napsat interface, ktery vystavuje A a B a predat ten objekt necemu, co zna ten interface - pak bude C skryte. V FP bych to mohl udelat obracene tak, ze dostanu funkci ktera pracuje s A a B, a te predam ta pole jako argument.. Jinak receno, co se nepredava neni potreba skryvat.
ako robi FP zo vzorov trivialne veci, co nemaju pomenovanie
Vezmi si treba funkci map, v Haskellu se signaturou:
map :: (a->b) -> ([a] -> [b])To je funkce, ktera bere funkci transformujici hodnoty typu a na hodnoty typu b, a vraci funkci, ktera aplikuje danou funkci nad kazdym prvkem seznamu (a vraci seznam). Pro nekoho, kdo trochu zna Haskell, je to velmi zrejma a bezna vec - funkce se chovaji jako kazda jina hodnota a lze je predavat jinym funkcim jako parametry. Take je to ovsem, z pohledu OOP, pouzity strategy pattern; protoze kazda funkce, ktera bere jako argument funkci, je v podstate strategy pattern. Ale neni duvod pro to zavadet novy termin, je to proste specialni pripad funkce, a to cim je specialni je dane jeji signaturou. Kdyz sdelis jeji signaturu, sdelil jsi i, ze jsi "pouzil strategy pattern", neni potreba to zminovat nejak navic. Z toho vyplyva, ze nepotrebujes ani ten termin, "strategy pattern". Staci proste rict - funkce se signaturou ... a je to dokonce vystiznejsi.
Predstav si analogickou situaci - kdybych misto "funkce, ktera bere za parametr pointer", rikal treba "pouzil jsem vzor neprimeho odkazu". Pusobilo by to smesne - je to mene deskriptivni a zbytecna terminologie. Tim chci ilustrovat, jak ten termin "strategy pattern" vidi nekdo, kdo zna FP.
Podobny rozbor je mozne udelat temer se vsemi design patterny (protoze, jak spravne rika ta prednaska, co poslal ava, vetsinou jde jen o triky, jak nekam predat funkci).
ako robia abstrakcie funkcionalneho programovania objektove abstrakcie zbytocnymi
Je to trochu naznacene v tech odkazech. Ale predevsim diky tomu, ze vsechno je jen nejake skladani funkci, dava ti to mnohem unifikovanejsi pohled na vec a nepotrebujes znat design patterns - stanou se z nich (a mnoha dalsich) proste zcela zrejme veci, ktere prirozene vyplynou ze situace.
Jinak existuji skutecne "design patterns" v FP. Jsou to veci jako treba funktor, nebo monada, nebo monoid, nebo traversable.. typicky (v Haskellu) definovany pres nejakou typovou tridu a zakony, ktere pro ne plati. Ale to uz je o necem trochu jinem, a v jistem smyslu je to mnohem zajimavejsi (protoze lepe definovane) nez design patterns z GoF book.
998 Odpovědí
233141 Zhlédnutí