Funksional proqramlaşdırma GoF dizayn nümunələrini əvəz edirmi?

Ötən il F # və OCaml öyrənməyə başladığımdan bəri, dizayn nümunələrini (xüsusilə Java) iti dillərdə itkin funksiyalara görə əvəzolunmaz bir çox məqalə oxudum. Mən tapdığım bir məqalə olduqca güclü şikayətlər verir :

Tanışdığım insanların çoxu Şablon Dizayn kitabını Gan 4-dən oxumuşdur. Hər hansı bir özünə hörmət edən proqramçı sizə hansı dili istifadə etməyinizə baxmayaraq kitabın dil agnostik və ümumiyyətlə proqram inkişafına tətbiq olunan nümunələr olduğunu bildirəcəkdir. Bu nəcib bir tələbdir. Təəssüf ki, o, həqiqətdən uzaqdır.

Funksional dillər son dərəcə ifadəlidir. Funksional bir dildə desen naxışları lazım deyil, çünki dil, yəqin ki, yüksək səviyyədədir, çünki dizayn tərzini bütünlüklə aradan qaldıran konsepsiyalarda proqramlaşdırma işidir.

Funksional proqramlaşdırmanın əsas funksiyaları birinci dərəcəli dəyərlər, currying, sabit dəyərlər və s. Kimi funksiyaları daxil edir. OO dizayn nümunələri bu funksiyalardan hər hansı birinə təxmin edildiyi mənə aydın görünmür.

Əlavə olaraq, OOP-ni dəstəkləyən funksional dillərdə (məsələn, F # və OCaml) mənə elə gəlir ki, bu dillərdən istifadə edən proqramçılar bütün digər OOP dillərində mövcud olan eyni dizayn nümunələrini istifadə edəcəklər. Əslində, hər gün F # və OCaml istifadə edirəm və Java'da yazarkən istifadə etdiyim nümunələrə qarşı bu dillərdə istifadə etdiyim nümunələr arasında fərqli bir fərq yoxdur.

Funksional proqramlaşdırma OOP dizayn nümunələrinə olan ehtiyacı aradan qaldıracağına dair bir həqiqət varmı? Əgər belədirsə, tipik bir OOP dizayn deseninin və onun funksional ekvivalentinin nümunəsini dərc edə və ya bağlaya bilərsiniz?

863
29 нояб. 29 noyabr tarixində Juliet tərəfindən təyin olundu 2008-11-29 23:08 '08 at 23:08 2008-11-29 23:08
@ 23 cavab

Sitat gətirən blog yazısı çoxdur. FP dizayn nümunələrinə olan ehtiyacları aradan qaldırmaz. "Dizayn nümunələri" termini sadəcə FP dillərində eyni şeyi təsvir etmək üçün geniş istifadə edilmir. Lakin onlar var. Funksional dillər əsasən bir dizayn nümunəsi olan "X problemi ilə qarşılaşdığınızda, Y kimi görünən kodu istifadə edin" şəklində ən yaxşı təcrübənin bir çox qaydasına malikdir.

Bununla yanaşı, OOP-ə uyğun dizayn nümunələrinin çoxu funksional dillərlə əlaqədardır.

Modellərin dizaynı yalnız dilin qüsurlarını bağlamaq üçün mövcud olduğunu söyləmək xüsusilə mübahisəlidir. Və əgər başqa bir dil eyni problemi həll edə bilərsə, bu başqa bir dil üçün bir dizayn desenine ehtiyac yoxdur. Bu dili istifadə edənlər hətta bir problem olmadığını bilmirlər, çünki bu, bu dildə problem deyil.

Bu problemdən dördün bir dəstəsi budur:

Proqramlaşdırma dilinin seçilməsi vacibdir, çünki bir baxımdan təsir göstərir. Bizim şablonlarımız Smalltalk / C ++ dilinin xüsusiyyətlərini götürür və bu seçim asanlıqla tətbiq edilə bilən və asanlıqla həyata keçirilə bilməyəcək. Prosessual dilləri qəbul etsək, biz Miras, Kapsülləşdirmə və Polimorfizm adlı dizayn nümunələrini ehtiva edə bilərik. Eynilə, nümunələrimizdən bəziləri daha az ümumi obyekt yönümlü dillər tərəfindən dəstəklənir. CLOS, məsələn, Visitor kimi bir nümunə ehtiyacını azaldacaq bir çox üsula malikdir. Əslində, Smalltalk və C ++ arasında olduqca az fərq vardır, yəni bəzi nümunələri başqa birinə görə bir dildən daha asan ifadə edilə bilər. (Bax: məsələn, "İterator").

("Şablonların dizaynına giriş" kitabının yuxarıdakı cədvəli, 4-cü bənd, 3-cü bənd)

Funksional proqramlaşdırmanın əsas funksiyaları birinci dərəcəli dəyərlər, köri, sabit dəyərlər və s. Kimi funksiyaları əhatə edir. OO dizayn nümunələri bu xüsusiyyətlərdən hər hansı birinə yaxınlaşdığına bənzəmir.

Bir komanda nümunəsi nədir, əgər birinci sinif funksiyalarının yaxınlaşması yoxsa?) FP-də sadəcə funksiyanı başqa bir funksiyaya istinad edir. OOP'da, yarada biləcək bir sinifdə bir funksiyanı tamamlamalı və sonra bu obyekti başqa funksiyaya keçirməlisiniz. Təsiri eynidır, ancaq OOP-da bu dizayn deseni deyilir və daha çox kod tələb olunur. Və kölgə deyilsə, mücərrəd fabrik naxışları nədir? Nəhayət onu çağırdığınız zaman hansı dəyərdən çıxdığını tənzimləmək üçün funksiya parametrlərini bir neçə dəfə keçin.

Belə ki, FP dillərində bir neçə GoF dizayn nümunəsi lazımsızdır, çünki daha güclü və asan istifadə alternativləri var.

Ancaq əlbəttə ki, hələ PHP dilləri ilə həll olunmayan dizayn nümunələri var. FP-nin ekvivalenti nədir? (Singltonların ümumiyyətlə qorxudan bir nümunə olması faktını nəzərə almadan)

Və hər iki istiqamətdə də işləyir. Dediğim kimi, PHP öz dizayn nümunələrinə malikdir, insanlar adətən bunlar kimi düşünmürlər.

Amma siz monadlarla qarşılaşa bilərdiniz. "Qlobal dövlətlə mübarizə" üçün bir dizayn desə, onlar nədir? OOP dillərində bu qədər sadə bir problem var ki, heç bir uyğun dizayn tərzi yoxdur.

Biz "statik bir dəyişən artım" və ya "bu yuvadan oxumaq" üçün bir dizayn desenine ehtiyac duymuyoruz, çünki bu tam olaraq etdiyiniz şeydir.

Monadın "dizayn nümunəsi" və ya eyni şəkildə həll edilməsi üçün hər hansı bir metoddan istifadə etmədiyiniz təqdirdə, (təmiz) funksional dillərdə, yan təsirləri və dəyişkən dövlətlər mümkün deyildir.

Bundan əlavə, OOP-ni (F # və OCaml kimi) dəstəkləyən funksional dillərdə mənə elə gəlir ki, bu dilləri istifadə edən proqramçılar bütün digər OOP dillərində olan eyni dizayn nümunələrini istifadə edəcəklər. Əslində indi hər gün F # və OCaml istifadə edirəm və bu dillərdə istifadə etdiyim şablonlar və Java yazarkən istifadə etdiyim şablonlar arasında heç bir fərq yoxdur.

Yəqin ki, vacib hesab etdiyiniz üçün bəlkə? Bir çox insanlar, bütün ömürləri vacib dilləri tətbiq edərkən, funksional bir dil cəhd edərkən bu vərdişi vermirlər. (F # -də olduqca gülməli cəhdlər gördüm, burada hər bir funksiyanı tam olaraq "let" xətti idi, əsasən, C proqramını götürdünüz və "nöqtə" ilə nöqtəli nöqtələri əvəz etdim :))

Ancaq başqa bir ehtimal ola bilər: sadəcə problemlərin həlli çətin olduğunu başa düşmədiniz, OOP dilində dizayn nümunələri tələb olunur.

Qarışdırdıqda və ya funksiyanı başqa bir arqument kimi istifadə edərkən, OOP-da bunu necə etdiyini düşünün.

Funksional proqramlaşdırma OOP dizayn nümunələrinə olan ehtiyacı aradan qaldıracağına dair bir həqiqət varmı?

Bəli, FP dilində işləyərkən, OOP-a əsaslanan dizayn nümunələrinə artıq ehtiyacınız yoxdur. Ancaq hələ MVC və ya qeyri-OOP kimi bəzi ümumi dizayn nümunələrinə ehtiyacınız var və FP üçün yeni "dizayn nümunələri" lazımdır. Bütün dillərdə onların çatışmazlığı var və dizayn nümunələri ümumiyyətlə ətrafımıza necə gedəcəyik.

Hər halda, özünüzü ML (mənim şəxsi sevdiyim, ən azı təlim məqsədləri üçün) və ya bir şeylə qarşılaşdığınız zaman geri qayıtmaq üçün bir OOP qolta malik olmayan "təmiz" FP dillərində özünüzü sınamaq maraqlı ola bilər. yeni bir şey.


Gözlənildiyi kimi, bəzi insanlar mənim müəyyən dizayn nümunələrinə "bir dildə qüsurları təyinat" kimi etiraz etdilər, buna görə mənim haqqımdır: Daha çox qeyd edildiyi kimi, əksər dizayn nümunələri bir proqramlaşdırma paradiqmasına, bəzən də müəyyən bir dilə aiddir. Tez-tez onlar bu paradiqmada mövcud olan problemləri həll edirlər (FP üçün monadlar və ya OOP üçün mücərrəd fabriklər bax). Niyə FP-də mücərrəd fabrik şablonu yoxdur? Çünki həll etməyə çalışan problem yoxdur. Belə ki, FP dillərində mövcud olmayan OOP dillərində bir problem varsa, bu, OOP dillərinin olmamasıdır. Bu problem həll edilə bilər, amma diliniz bunu etmir, amma şablon kodunun bir qrupuna ehtiyacınız var. İdeal olaraq, proqramlaşdırma dilimizin sehrli şəkildə bütün problemləri aradan qaldırmasını istəyirik. Hələ mövcud olan hər hansı bir problem, əsasən bir dil qüsurudur;;)

878
30 нояб. Cavab cümə axşamı 30 noyadır. 2008-11-30 02:06 '08 at 2:06 2008-11-30 02:06

Funksional proqramlaşdırma OOP dizayn nümunələrinə olan ehtiyacı aradan qaldıracağına dair bir həqiqət varmı?

Funksional proqramlaşdırma obyektə yönələn proqramlaşdırma ilə eyni deyildir. Obyekt yönümlü dizayn nümunələri funksional proqramlaşdırma üçün tətbiq edilmir. Əvəzində, funksional proqramlaşdırma üçün dizayn nümunələri var.

Funksional proqramlaşdırma üçün OO dizayn nümunələrinin kitablarını oxumazsınız, FP dizayn nümunələri üzrə digər kitabları oxuyacaqsınız.

dil agnostik

Həqiqətən deyil. OO dilləri ilə bağlı yalnız dili agnostik. Dizayn nümunələri prosessual dillərdə tətbiq edilmir. İlişkisel verilənlər bazası dizaynı kontekstində çətinlik çəkirlər. Bir masa dizaynında tətbiq edilmir.

tipik OOP dizayn deseni və onun funksional ekvivalenti?

border=0

Yuxarıda mövcud olmalıyıq. Bu bir OO kodu kimi təkrar yazılan bir prosessual kodun bir hissəsini soruşmaq kimi. Umm ... Orijinal Fortran'ı (və ya C) Java'ya tərcümə etsəm, onu tərcümə etməkdən başqa bir şey etmədim. Mən tamamilə OO paradiqmasına yazsam, artıq orijinal Fortran və ya C kimi görünməyəcək - bu tanınmayacaq.

OO Dizaynından Funksional Dizayna qədər sadə bir xəritəçəkmə yoxdur. Problemə baxmaq üçün çox fərqli yollar var.

Funksional proqramlaşdırma (bütün proqramlaşdırma üslubları kimi) dizayn nümunələrinə malikdir. İlişkisel veritabanlarının dizayn nümunələri var, OO dizayn nümunələrinə malikdir, prosessual proqramlaşdırma dizayn nümunələrinə malikdir. Hər kəsin dizayn nümunələri var, hətta memarlıq qurur.

Dizayn nümunələri - konsepsiya kimi - texnologiyadan və ya problem domenindən asılı olmayaraq qurmaq üçün zamansız bir yoldur. Bununla belə, spesifik dizayn nümunələri xüsusi problem sahələrinə və texnologiyalarına tətbiq edilir.

Nəyi etdiklərini düşünən hər kəs dizayn nümunələrini ortaya qoyacaq.

125
29 нояб. cavab Nov. 29-da S.Lott tərəfindən verilir 2008-11-29 23:15 '08 at 11:15 pm 2008-11-29 23:15

Brian, dil ilə desək arasındakı sıx əlaqələrə bağlı şərh edir

Bu mübahisənin yanlış hissəsi deyim konsepsiyasıdır. Coplienin "Advanced C ++" adlı kitabı böyük bir təsir etdi. Kristofer İskəndər və Untitled Column'u aşkarlamadan çox keçməmişdən əvvəl (və Aleksandr oxuymadan nümunələri haqqında ağıllı danışa bilməyəcəksiniz), o, həqiqət dilinin öyrənilməsində idiomun mənimsənilməsinin vacibliyindən danışıb. Məsələn, C-də bir simli kopyasını istifadə etdi və (* + + = + - ++); Siz itkin dil funksiyası (və ya kitabxana funksiyası) üçün quldur kimi görürsünüz, ancaq həqiqətən vacib olan şey onun hər hansı bir hissəsinə nisbətən düşüncə və ya ifadəin daha böyük bir hissəsidir.

Şablonları və dilləri niyyətlərimizi daha dəqiq ifadə edə bilmək üçün bunu etməyə çalışır. Zəngin düşüncələr, düşüncələrinizi daha mürəkkəb ifadə edə bilərsiniz. Müxtəlif tərəzələrdə zəngin, bölünmüş bir leksikanın olması - sistemin arxitekturasından bit-bükülməsinə qədər - bizə nə etməli olduğumuz barədə daha ağıllı söhbətlər və fikirlər verməyə imkan verir.

İnsanlar kimi öyrənə bilərik. Bütün məşq nöqtəsi hansıdır? Hər birimiz özümüz haqqında düşünməyəcəyimiz şeyi anlaya və istifadə edə bilərik. Dillər, çərçivələr, kitabxanalar, naxışlar, deyimlər və s. İntellektual sərvət mübadiləsi içində hamısının yeri var.

36
01 янв. cavab grahamsw 01 jan verilir . 2009-01-01 23:59 '09 at 11:59 PM 2009-01-01 23:59

GOF kitabı özünü OOP ilə birləşdirir - adı - bunlar dizayn nümunələri - təkrar obyektlərə yönəlmiş proqramın elementləri (mənim diqqətim).

33
24 нояб. cavab parlaq 24 gün verilir . 2009-11-24 18:49 '09 at 06:49 PM 2009-11-24 18:49

Peter Norviqin Dinamik Proqramlaşdırma Dizayn Nümunələri bu ümumi mövzunu əhatə edir, baxmayaraq ki, "funksional" yerinə (onlar orada çakışır) "dinamik" dillər haqqında.

30
29 нояб. Cavab Darius Bacon tərəfindən 29 noyabrda verilir. 2008-11-29 23:23 '08 at 11:23 2008-11-29 23:23

Bu mövzunu müzakirə edən başqa bir link: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

Blogda Edvard, Haskell baxımından orijinal GoF şablonlarının 23'ünü təsvir edir.

20
19 окт. Cavab 19 oktyabrda folyona verilir . 2012-10-19 11:15 '12 saat 11:15 'da 2012-10-19 11:15

"Dizayn nümunələri" (ümumiyyətlə) və "FP ilə OOP" səviyyələrinə baxmağa çalışdığınız zaman tapdığınız cavablar ən yaxşı çamur olacaqdır.

Hər iki baltada daha dərin səviyyəyə çıxın və xüsusi dizayn nümunələri və xüsusi dil funksiyalarını nəzərdən keçirin və hər şey daha aydın olacaq.

Məsələn, Visitor , Strategy , TeamObserver kimi bəzi xüsusi şablonlar, cəbri məlumat növləri və desen uyğunluğu , bağlanması , birinci sinif funksiyaları və s. İlə dil istifadə edərkən mütləq dəyişə və ya yox ola bilər . GoF kitabından bəzi digər şablonlar hələ də "saxlanılır".

Ümumiyyətlə, demək olar ki, zaman keçdikcə, yeni nümunələr (və ya sadəcə artan) dil funksiyaları ilə aradan qaldırılır. Dil tərtibinin təbii yoludur; dillər daha yüksək səviyyədə olsalar da, əvvəllər nümunələri istifadə edərək yalnız kitabda istifadə edilə bilən abstraklamalar indi xüsusi bir dil funksiyası və ya kitabxananın tətbiqləri olur.

(Həmçinin: burada yazdığım yeni bir blogdur ki, FP və dizayn nümunələrinin daha çox müzakirəsi üçün digər əlaqələr var).

15
30 нояб. Cavab Brian 30 noyabrda verilir. 2008-11-30 02:15 '08 saat 02:15 'da 2008-11-30 02:15

Norviq təqdimatı, bütün GoF şablonları üçün etdikləri təhlillərə istinad edir və 23 şablondan 16-u funksional dildə daha asan tətbiq olunduğunu və ya dilin bir hissəsi olduğunu söyləyirlər. Ona görə də, ehtimal ki, ən azı yeddi və ya eyni dərəcədə mürəkkəb idi və ya b) bu ​​dildə olmadı. Təəssüf ki, bizim üçün onlar siyahıda deyil!

Hesab edirəm ki, GoF-dəki "yaradıcı" və ya "struktur" naxışların əksəriyyəti ibtidai Java və ya C ++ tipli sistemlərin istədiklərini yerinə yetirmək üçün yalnız fəndlərdir. Qalan dil isə proqramlaşdırma olduğunuza baxmayaraq, diqqətinizə layiqdir.

Biri prototip ola bilər; bu isə javascript əsas konsepsiyasıdır, digər dillərdə sıfırdan həyata keçirilməlidir.

Sevdiyim şablonlardan biri Null Obyekt şablonudır: bir şey kimi görünməmiş bir görünüş verən bir obyektin olmamasını təmsil edir. Funksional bir dildə modelləşdirmək daha asan ola bilər. Lakin real nailiyyət perspektivdə dəyişiklikdir.

14
30 нояб. Neil Kandalgaonkar tərəfindən verilmiş cavab 30 noyabr 2008-11-30 10:11 '08 at 10:11 2008-11-30 10:11

Lisp kimi bir dil olduğunuzda makrolara dəstək verdiyiniz zaman, ümumiyyətlə, ümumiyyətlə idxal həllərdən daha yaxşı olan öz abstractions, domenə özünəməxsus abstractions yarada bilərsiniz.

13
16 дек. Cavab 16 dekabrda Anders Rune Jensen tərəfindən verilir. 2008-12-16 22:44 '08 at 22:44 pm 2008-12-16 22:44

Və hətta OO Design Pattern həlləri dildən asılıdır. Dizayn nümunələri, proqramlaşdırma dilinizin sizin üçün həll etmədiyi ümumi problemlərə həll edir. Java'da, Singleton naxışları bir şeylə əlaqəli bir problemi (sadələşdirilmiş) həll edir. Scala'da, sinifə əlavə olaraq obyekt olaraq adlandırılan üst səviyyəli bir quruluşunuz var. Buradakı tövsiyələr bir-birinə örnəkdir və yalnız birdir. Bir Singleton almaq Singleton model istifadə etmək lazım deyil. Bu dilin bir hissəsidir.

8
30 нояб. Cavab Dan Sickles Noyabr 30 2008-11-30 21:02 '08 at 21:02 2008-11-30 21:02

Nümunələr təkrar görülən və sonra təsvir edilmiş və sənədləşdirilmiş olan bu problemləri həll etmək yollarıdır. Beləliklə, FP nümunələri əvəz etməyəcək; FP, yeni şablonları yarada və bəzi "ən yaxşı təcrübələr" şablonlarını "köhnəlmiş" hala gətirə bilər.

7
26 авг. Cavab Edwin Buck tərəfindən verilir 26 av. 2013-08-26 05:10 '13 saat 05:10 'da 2013-08-26 05:10

Başqalarının dediyi kimi, funksional proqramlaşdırma üçün xüsusi nümunələr var. Hesab edirəm ki, dizayn nümunələrindən xilas olmaq problemi funksional bir keçiddə deyil, dil xüsusiyyətləri məsələsində deyil.

Scala "tək nümunə nümunəsini" necə aradan qaldıracağına baxın: sadəcə bir sinif yerinə bir obyekt elan edirsiniz. Başqa bir xüsusiyyət, desen eşleme, ziyarətçi modelinin soxulmasından çəkinməyə kömək edir. Burada müqayisə bax: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

Və Scala, F # kimi, OO-funksional bir fusion edir. F # haqqında bilmirəm, lakin ehtimal ki, belə imkanlar var.

Əlaqələr funksional bir dildə mövcuddur, lakin məhdudlaşdırılmasına ehtiyac yoxdur. Heyət heyətinə kömək edirlər.

Digər bir müşahidə. Bu kod parçası bir nümunə tətbiq edir: bu, klassikdir və bu elementar bir şeydir ki, biz bunu "üslub" kimi düşünmürük, amma əmindir:

 for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); } 

Java və C # kimi imperativ dillər bu problemi həll etmək üçün əsasən funksional bir quruluşa malikdirlər: "foreach".

6
30 нояб. cavab noyabrın 30-da verilir 2008-11-30 00:43 '08 at 0:43 2008-11-30 00:43

GoF dizayn nümunələri Java və C ++ kimi Simula 67-nin nəslindən olan OO dilləri üçün bypass tariflərini kodlaşdırır.

Dizayn nümunələri ilə işlənilən "xəstəliklərin" əksəriyyəti aşağıdakılardan ibarətdir:

  • obyektləri müəyyən edən statik tipli dərslər, lakin obyektlərin özləri deyil;
  • ограничение на единую диспетчеризацию (для выбора метода используется только самый левый аргумент, остальные аргументы рассматриваются только как статические типы: если у них есть динамические типы, это зависит от метода сортировки с помощью специальных подходов);
  • различие между регулярными вызовами функций и объектно-ориентированными вызовами функций, что означает, что объектно-ориентированные функции не могут передаваться как функциональные аргументы, где ожидаются регулярные функции и наоборот; və
  • различие между "базовыми типами" и "типами классов".

Ни один из этих шаблонов проектирования не исчезает в Common Lisp Object System, хотя решение структурировано по существу так же, как в соответствующем шаблоне проектирования. (Более того, эта объектная система предшествует книге GoF уже более десяти лет. Общий Lisp стал стандартом ANSI в том же году, когда эта книга была впервые опубликована.)

Что касается функционального программирования, зависит от того, применяются ли к нему шаблоны, зависит от того, имеет ли данный язык функционального программирования какую-то систему объектов и моделируется ли он после объектных систем, которые извлекают выгоду из шаблонов. Этот тип объектной ориентации не очень хорошо сочетается с функциональным программированием, поскольку мутация состояния находится спереди и в центре.

Конструктивный и не мутирующий доступ совместим с функциональным программированием, и поэтому могут быть применимы шаблоны, которые связаны с абстрагированием доступа или построения: такие шаблоны, как Factory, фасад, прокси, декоратор, посетитель.

С другой стороны, поведенческие модели, такие как State и Strategy, вероятно, напрямую не применяются в функциональном ООП, поскольку в их основе лежит мутация государства. Это не означает, что они не применяются; возможно, они каким-то образом применяются в сочетании с любыми трюками, доступными для имитации изменчивого состояния.

6
ответ дан Kaz 09 дек. '13 в 20:45 2013-12-09 20:45

Я хотел бы подключить несколько отличных, но несколько плотных бумаг Джереми Гиббонса: "Модели дизайна как более высокоуровневые типы данных" и "Сущность шаблона итератора" (оба доступны здесь: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Они описывают, как идиоматические функциональные конструкции покрывают ландшафт, который покрывается конкретными шаблонами проектирования в других (объектно-ориентированных) настройках.

6
ответ дан sclv 17 сент. '10 в 3:30 2010-09-17 03:30

У вас не может быть этого обсуждения без создания систем типов.

Основные функции функционального программирования включают функции как первоклассные значения, каррирование, неизменные значения и т.д. Мне не кажется очевидным, что шаблоны проектирования OO аппроксимируют любые из этих функций.

Это потому, что эти функции не затрагивают те же проблемы, что и ООП... они являются альтернативами императивному программированию. Ответ FP на ООП лежит в системах типов ML и Haskell... в частности, типы сумм, абстрактные типы данных, модули ML, классные классы Haskell.

Но, конечно, есть еще шаблоны проектирования, которые не решаются языками FP. Что такое эквивалент FP синглтона? (Не обращая внимания на то, что синглтоны, как правило, страшный шаблон для использования)

Первое, что делают стили, - это устранение необходимости в одиночных играх.

Вы можете перечислить список из 23 и устранить больше, но у меня нет времени прямо сейчас.

5
ответ дан jganetsk 01 дек. '08 в 1:20 2008-12-01 01:20

OOP и шаблоны GoF относятся к состояниям. ООП моделирует реальность, чтобы поддерживать базу кода как можно ближе к данным требованиям реальности. Шаблоны проектирования GoF - это шаблоны, которые были идентифицированы для решения проблем атомного мира. Они рассматривают проблему состояния семантическим образом.

Как и в реальном функциональном программировании, никакого состояния не существует, нет смысла применять шаблоны GoF. Нет функциональных шаблонов проектирования, так же как и шаблоны дизайна GoF. Каждая функциональная схема дизайна является искусственной, в отличие от реальности, поскольку функции представляют собой конструкции математики, а не реальности.

В функциях отсутствует концепция времени, так как они всегда возвращают одно и то же значение независимо от текущего времени, если время не является частью параметров функции, из-за чего очень сложно обрабатывать "будущие запросы". Гибридные языки смешивают эти концепции, делая языки не реальными функциональными языками программирования.

Функциональные языки растут только из-за одного: текущие естественные ограничения физики. Сегодняшние процессоры ограничены в скорости обработки инструкций из-за физических законов. Вы видите застой в тактовой частоте, но расширение в процессорных ядрах. Вот почему parallelism инструкций становится все более важным для увеличения скорости современных приложений. Поскольку функциональное программирование по определению не имеет состояния и поэтому не имеет побочных эффектов, безопасно обрабатывать функции безопасно параллельно.

Шаблоны GoF не устарели. Они, по крайней мере, необходимы для моделирования требований реального мира. Но если вы используете функциональный язык программирования, вы должны преобразовать их в свои гибридные эквиваленты. Наконец, вы не можете создавать только функциональные программы, если используете упорство. Для гибридных элементов вашей программы остается необходимость использовать шаблоны GoF. Любой другой элемент, который является чисто функциональным, не является необходимостью использовать шаблоны GoF, потому что нет состояния.

Поскольку шаблон GoF не нужен для реального функционального программирования, это не означает, что принципы SOLID не должны применяться. Принципы SOLID не соответствуют какой-либо языковой парадигме.

3
ответ дан oopexpert 29 июня '16 в 1:11 2016-06-29 01:11

Я думаю, что только два шаблона дизайна GoF предназначены для введения логики функционального программирования в естественный язык OO. Я думаю о Стратегии и Команде. Некоторые из других шаблонов дизайна GoF могут быть изменены функциональным программированием, чтобы упростить дизайн и сохранить цель.

3
ответ дан CyaNnOrangeHead 01 окт. '12 в 13:51 2012-10-01 13:51

По существу, да !

  • Когда шаблон обходит отсутствующие функции (функции высокого порядка, обработку потока...), < состав.
  • Необходимость повторной записи реализации шаблонов снова и снова может сама по себе восприниматься как языковой запах .

Кроме того, эта страница (AreDesignPatternsMissing> предоставляет таблицу перевода "шаблон/функция" и некоторые приятные обсуждения, если вы готовы копать.

ответ дан YvesgereY 19 окт. '12 в 22:44 2012-10-19 22:44

В новой книге 2013 года под названием "Функциональные шаблоны программирования - в Scala и Clojure" автор Майкл Б.. Линн проводит достойную работу по сравнению и обеспечивает замену во многих случаях для шаблонов GoF, а также обсуждает новые функциональные шаблоны, такие как "хвостовая рекурсия", "memoization", "ленивая последовательность" и т.д.

Эта книга доступна на Amazon. Я сочла его очень информативным и обнадеживающим, когда я исходил из фона OO в течение нескольких десятилетий.

2
ответ дан manish 20 мая '14 в 15:04 2014-05-20 15:04

Функциональное программирование не заменяет шаблоны проектирования. Образцы дизайна не могут быть заменены.

Шаблоны просто существуют; они появились со временем. Книга GoF официально оформила некоторые из них. Если появятся новые шаблоны, так как разработчики используют функциональные языки программирования, которые являются интересными вещами, и, возможно, там будут и книги, написанные о них.

2
ответ дан ktingle 01 дек. '08 в 1:00 2008-12-01 01:00

OOP и FP имеют разные цели, ООП стремится инкапсулировать сложности/движущиеся части программных компонентов, а FP направлена ​​на минимизацию сложности и зависимостей программных компонентов, однако эти 2 парадигмы не обязательно на 100% противоречат друг другу и могут применяться вместе получить выгоду от обоих миров. Даже с языком, который не поддерживает функциональное программирование, например, С#, вы можете написать функциональный код, если вы понимаете принципы FP, также вы можете применять принципы ООП с использованием F #, если вы понимаете принципы, шаблоны и лучшие практики ООП. Вы бы сделали правильный выбор в зависимости от ситуации и проблемы, которые вы пытаетесь решить, независимо от языка программирования, который вы используете.

1
ответ дан Dogu Arslan 13 дек. '16 в 13:57 2016-12-13 13:57

Я думаю, что каждая парадигма служит другой цели и поэтому не может сравниться таким образом.

Я не слышал, чтобы шаблоны дизайна GoF применимы к каждому языку. Я слышал, что они применимы ко всем ООП-языкам . Если вы используете функциональное программирование, то область проблем, которые вы решаете, отличается от языков OO.

Я бы не использовал функциональный язык для написания пользовательского интерфейса, но один из языков OO, таких как С# или Java, облегчил бы эту работу. Если бы я писал функциональный язык, я бы не стал рассматривать шаблоны проектирования OO.

1
ответ дан Vincent Ramdhanie 29 нояб. '08 в 23:18 2008-11-29 23:18

Как сказал принятый ответ, OOP и FP имеют свои специфические шаблоны.

Однако существуют некоторые шаблоны, которые настолько распространены, что все платформы программирования, о которых я могу думать, должны иметь. Вот список (неполный):

  • Adapter. Я едва ли могу придумать полезную платформу программирования, которая является настолько всеобъемлющей (и самореализованной), что ей не нужно говорить с миром. Если это будет сделано, необходим адаптер.

  • Фасадная. Любые платформы программирования, которые могут обрабатывать большой исходный код, должны иметь возможность модульности. Если вы хотите создать модуль для других частей программы, вам нужно будет скрыть "грязные" части кода и дать ему приятный интерфейс.

  • Интерпретатор. В общем, любая программа просто выполняет две функции: синтаксический ввод и вывод на печать. Входные данные мыши должны быть проанализированы, а виджеты окон должны быть распечатаны. Поэтому наличие встроенного интерпретатора дает программе дополнительную мощность для настройки вещей.

Кроме того, я заметил, что на типичном языке FP, Haskell, есть что-то похожее на шаблоны GoF, но с разными именами. По-моему, это говорит о том, что они были там, потому что есть некоторые общие проблемы для решения как на языках FP, так и на ООП.

  • Монад-трансформатор и декоратор. Первый использовал для добавления дополнительной способности в существующую монаду, последний добавляет дополнительную способность к существующему объекту.
0
ответ дан Earth Engine 12 июня '14 в 15:28 2014-06-12 15:28

Другие вопросы по меткам или Задайте вопрос