Alıntıladığınız blog yazısı iddiasını biraz abartıyor. FP, tasarım desenlerine olan ihtiyacı ortadan kaldırmaz . "Tasarım modelleri" terimi FP dillerinde aynı şeyi tanımlamak için yaygın olarak kullanılmamaktadır. Ama varlar. İşlevsel diller, "sorun X ile karşılaştığınızda, Y'ye benzeyen bir kod kullanın" şeklindeki en iyi uygulama kurallarına sahiptir, bu da temel olarak bir tasarım modelidir.
Bununla birlikte, OOP'ye özgü tasarım modellerinin çoğunun işlevsel dillerde neredeyse alakasız olduğu doğrudur.
Ben o tasarım desenleri söylemek özellikle tartışmalı olması gerektiğini sanmıyorum genelde sadece dilde eksiklikleri yama bulunmaktadır. Ve eğer başka bir dil aynı sorunu önemsiz bir şekilde çözebiliyorsa, diğer dilin bunun için bir tasarım modeline ihtiyacı olmayacaktır. Bu dilin kullanıcıları sorunun var olduğunun farkında bile olmayabilir , çünkü bu dilde bir sorun değil.
Dörtlü Çetenin bu konuda söyledikleri:
Programlama dilinin seçimi önemlidir, çünkü kişinin bakış açısını etkiler. Kalıplarımız Smalltalk / C ++ düzeyinde dil özelliklerini varsayar ve bu seçim neyin kolayca uygulanıp neyin uygulanamayacağını belirler. Prosedür dillerini kabul edersek, "Miras", "Kapsülleme" ve "Çok Biçimlilik" adlı tasarım modellerini dahil etmiş olabiliriz. Benzer şekilde, bazı modellerimiz doğrudan daha az yaygın olan nesne yönelimli diller tarafından desteklenmektedir. CLOS, örneğin Ziyaretçi gibi bir desene olan ihtiyacı azaltan çoklu yöntemlere sahiptir. Aslında, Smalltalk ve C ++ arasında, bazı kalıpların bir dilde diğerinden daha kolay ifade edilebileceği anlamına gelen yeterli farklılıklar vardır. (Örneğin, yineleyiciye bakın.)
(Yukarıdaki, Tasarım Desenlerine Giriş kitabından bir alıntıdır, sayfa 4, paragraf 3)
Fonksiyonel programlamanın temel özellikleri arasında birinci sınıf değerler, körelme, değişmez değerler vb. Gibi fonksiyonlar bulunmaktadır. OO tasarım modellerinin bu özelliklerden herhangi birine yaklaştığı açık değildir.
Birinci sınıf işlevlerin bir yaklaşımı değilse, komut düzeni nedir? :) Bir FP dilinde, bir işlevi başka bir işleve argüman olarak iletmeniz yeterlidir. Bir OOP dilinde, işlevi bir sınıfta tamamlamanız ve bu nesneyi başlatabilir ve daha sonra bu nesneyi diğer işleve geçirmeniz gerekir. Etki aynıdır, ancak OOP'de tasarım deseni olarak adlandırılır ve çok daha fazla kod alır. Ve eğer curried değilse, soyut fabrika deseni nedir? Sonunda aradığınızda ne tür bir değer verdiğini yapılandırmak için parametreleri bir kerede bir işleve geçirin.
Bu nedenle evet, birkaç GoF tasarım deseni FP dillerinde gereksiz hale getirildi, çünkü daha güçlü ve kullanımı daha kolay alternatifler mevcut.
Ama tabii hala vardır desenleri orada tasarım edilir değil FP dillere tarafından çözüldü. Singleton'un FP eşdeğeri nedir? (Singletonların genellikle korkunç bir model olduğunu bir an için dikkate almayın.)
Ve her iki şekilde de çalışır. Dediğim gibi, FP'nin de tasarım desenleri var; insanlar genellikle onları böyle düşünmezler.
Ama monadlarla karşılaşmış olabilirsiniz. "Küresel devletle uğraşmak" için bir tasarım modeli olmasalar da ne bunlar? Bu, OOP dillerinde o kadar basit bir sorun ki orada eşdeğer bir tasarım deseni yok.
"Statik bir değişkeni artırmak" veya "bu soketten okumak" için bir tasarım modeline ihtiyacımız yok, çünkü bu sadece yaptığınız şey .
Bir monadın bir tasarım deseni olduğunu söylemek, Tamsayıların her zamanki işlemleri ve sıfır elementi ile bir tasarım deseni olduğunu söylemek saçmadır. Hayır, bir monad tasarım deseni değil, matematiksel bir modeldir.
(Saf) işlevsel dilde, "tasarım deseni" monadıyla veya aynı şeye izin vermek için diğer yöntemlerden herhangi biri ile çalışmadıkça, yan etkiler ve değişebilir durum mümkün değildir.
Ayrıca, OOP'yi destekleyen işlevsel dillerde (F # ve OCaml gibi), bu dilleri kullanan programcıların diğer tüm OOP dillerinde bulunan tasarım desenlerini kullanacağı açıktır. Aslında, şu anda her gün F # ve OCaml kullanıyorum ve bu dillerde kullandığım kalıplarla Java'da yazarken kullandığım kalıplar arasında çarpıcı bir fark yok.
Belki de hala zorla düşündüğünüz için? Birçok insan, tüm yaşamları boyunca zorunlu dillerle uğraştıktan sonra, işlevsel bir dil denediğinde bu alışkanlıktan vazgeçmekte zorlanıyor. (F # 'da oldukça komik girişimler gördüm, burada her fonksiyon tam anlamıyla bir C programı almış ve tüm noktalı virgülleri' let 'ile değiştirmiş gibi bir dizi' let 'deyimiydi. :))
Ancak başka bir olasılık, OOP dilinde tasarım kalıpları gerektiren sorunları önemsiz bir şekilde çözdüğünüzü fark etmemiş olabilirsiniz.
Currying kullandığınızda veya bir işlevi diğerine argüman olarak aktardığınızda, durun ve bunu OOP dilinde nasıl yapacağınızı düşünün.
İşlevsel programlamanın OOP tasarım modellerine olan ihtiyacı ortadan kaldırdığı iddiasına dair herhangi bir gerçek var mı?
Evet. :) Bir FP dilinde çalışırken, artık OOP'a özgü tasarım modellerine ihtiyacınız yoktur. Ancak yine de MVC veya OOP olmayan diğer spesifik öğeler gibi bazı genel tasarım desenlerine ihtiyacınız var ve bunun yerine birkaç yeni FP'ye özgü "tasarım desenine" ihtiyacınız var. Tüm dillerin eksiklikleri vardır ve tasarım kalıpları genellikle onların etrafında nasıl çalıştığımızdır.
Her neyse, elinizi ML (en azından öğrenme amacıyla kişisel favorim) veya Haskell gibi "daha temiz" FP dillerinde denemek ilginç olabilir , burada OOP koltuk değerine sahip değilseniz yeni bir şeyle karşı karşıyasınız.
Beklendiği gibi, birkaç kişi tasarım desenleri tanımımı "bir dilde eksiklikleri düzeltmek" olarak itiraz etti, bu yüzden burada benim gerekçem:
Daha önce de belirtildiği gibi, çoğu tasarım deseni bir programlama paradigmasına, hatta bazen belirli bir dile özgüdür. Genellikle, sadece bu paradigmada var olan problemleri çözerler (bkz. FP için monadlar veya OOP için soyut fabrikalar).
FP'de soyut fabrika deseni neden mevcut değil? Çünkü çözmeye çalıştığı sorun orada yok.
Dolayısıyla, FP dillerinde bulunmayan OOP dillerinde bir sorun varsa, bu açıkça OOP dillerinin eksikliğidir. Sorun çözülebilir, ancak diliniz bunu yapmaz, ancak etrafınızda çalışmak için bir grup demirbaş kodu gerektirir. İdeal olarak, programlama dilimizin tüm sorunları sihirli bir şekilde ortadan kaldırmasını istiyoruz. Hala var olan herhangi bir sorun prensip olarak dilin eksikliğidir. ;)