Büyük fonksiyonel programlama uygulamaları oluşturmak için yaygın olarak kullanılan belirli iş akışları veya tasarım modelleri var mı? [kapalı]


13

Önemsiz projelerde kullanmadığım halde Clojure'u bir süredir araştırıyorum. Temel olarak, sözdizimi ve bazı deyimlerle rahatça çalışıyorum. OOP arka planından gelince, Clojure çok fazla baktığım ilk fonksiyonel dil olduğu için, doğal olarak bir şeyler yapmanın fonksiyonel yolundan o kadar rahat değilim.

Bununla birlikte, büyük fonksiyonel uygulamalar oluşturmada ortak olan belirli iş akışları veya tasarım modelleri var mı? Gerçekten "gerçek" için fonksiyonel programlama kullanmaya başlamak istiyorum, ama şu anki uzmanlık eksikliğimde destansı bir başarısızlığa yol açacağından korkuyorum.

"Dörtlü Çete" OO programcıları için böyle bir standarttır, ancak fonksiyonel paradigmaya daha fazla yön veren benzer bir şey var mı? Bulduğum kaynakların çoğunda harika programlama külçeleri var, ancak daha geniş ve daha mimari bir görünüm vermek için geri adım atmıyorlar.


6
Bazı GOF modelleri, İşlevsel Programlamanın zaten sağladığı şeyler için OO dillerinde gerçekten geçici çözümlerdir. Bkz. Stackoverflow.com/q/327955
Robert Harvey



Bu tartışmada GoF / OOP'a özgü kalıplara biraz fazla odaklanıldığını düşünüyorum. Herkes gerçek işlevsel programlamaya özgü kalıplar yayınlayabilir mi (bunlar sadece işlevsel dillerde GoF'un önemsizliğini kanıtlamaya çalışmaz)?
Daniel B

Yanıtlar:


3

Bu tür desenler genellikle kırık, uygun olmayan bir modelin belirtileridir.

OOP tasarım tarafından kırılır, uygulamalarının çoğu için uygun değildir, bu nedenle "desen" olarak adlandırılan her şeyle patlar. İşlevsel model (sadece biraz) daha esnektir ve "kalıplara" duyulan ihtiyaç o kadar açık değildir.

(İşlevsel programcılar için doğal) dil odaklı bir yaklaşımı uygulamaya başladıktan, her bir sorun alanı için DSL'leri kullanmaya veya oluşturmaya başladıktan sonra, hiçbir desen gösterilmediğini göreceksiniz, çünkü her zaman için uygun bir model kullanıyorsunuz. bir sorunu tanımlamak.

Tabii ki, yinelenen yüksek seviyeli "desenler" veya "tarifler" çok soyut, temiz ve saf matematikte bile kaçınılmazdır, ancak bunlar GoF modellerinden farklı ve farklı bir soyutlama düzeyindedir. Örneğin, monad'ları faydalı bulacaksınız.


Son 2 paragraf için +1, sanırım bu nokta. OOP ile ilgili olarak, belirli sorunlara sıklıkla uygulanan genel bir araç olması (dolayısıyla GoF olanlar gibi düşük seviyeli modeller) gerçeği dışında, onu kırmanın arkasındaki mantığı merak ediyorum. Kısaca ayrıntı verebilir veya görüşünüzü özetleyen bir bağlantı yayınlayabilir misiniz?
Daniel B

@DanielB, OOP ile ilgili yanlış bir şey yoktur, ancak genellikle uygulanma şekli tamamen bozulur. Bu model gerçek dünya sorunlarından sadece birkaçına uyar (ve uygun şekilde uygulandığında gerçekten parlar), ancak geri kalanı için koltuk değneklerine ve koli bandına uyacak şekilde ihtiyacı vardır. Cevabımı örneğin programmers.stackexchange.com/questions/52608/… adresinden görebilirsiniz .
SK-logic

Tamam, sanırım aynı sayfadayım. Aslında, bu soruyu daha önce bir kez sormuş olabilirim, bunun için üzgünüm - bu satırı ifade etme şekliniz daha fazla ima ettiğiniz gibi görünüyor.
Daniel B

-3

Kişisel görüşüme göre, tasarım kalıpları semantik. Modelimi anladığımdan emin olduğumdan emin olmak için MVC kullanarak bazı eski uygulamalarımı yeniden yazmayı hatırlıyorum. Ama sonunda, orijinal kodum üzerinden MVC'den hiçbir şey kazanmadım.

Ancak, orijinal kodumu daha geniş bir geliştirme ortamına uygulayacak ve birisine bu belirli yöntemle ilgili bir sorun olduğunu söyleseydim ... geliştiricinin sorunu izlemesi zor olurdu. ANCAK, eğer ContractController'ın herhangi bir nedenden ötürü mucklendiğini söyleseydim, nereden başlayacağını tam olarak bilecektir.

Tasarım kalıpları harika ... ama dediğim gibi, semantik olduklarını düşünüyorum!

EDIT: Sen evangelist türleri beni parçalamak. MVC (veya başka bir tasarım modeli) olmadan bir şey nasıl geliştirildi!


2
anlamsal (sɪˈmæntɪk) - 1. farklı anlam veya sembollerin anlamları arasındaki farklardan kaynaklanan veya bunlardan kaynaklanan veya bunlarla ilgili olan 2. anlambilimin 2. anlamıyla ilgili veya anlam ile ilgili (anlam çalışması) 3. biçimsel bir teorinin yorumlanması ile ilgili mantık, duygusal bağların bir hesabı olarak doğruluk tabloları verildiğinde olduğu gibi
Robert Harvey

+1 - benim görüşüm tasarım desenlerinin sadece bir iletişim aracı olmasıydı!
aserwin

Tasarım kalıpları iletişim kurmanın bir yolundan daha fazlasıdır; bunlar, yaygın olarak karşılaşılan belirli sorunları çözmek için yazılımda uygulanabilen somut, iyi anlaşılmış tariflerdir.
Robert Harvey

Kitaplar böyle söylüyor. Ama ben asla problemi çözemediğim bir tasarım modeliyle hiçbir zaman çözemedim. Kendi deneyimimde fark ettiğim tek avantaj, kod hakkında birbirinizle konuşma yeteneğidir! ;)
aserwin

1
Düzenlemenizle ilgili olarak: Yani her yeni kod yazışınızda tekerleği yeniden icat etmeyi mi tercih edersiniz?
Robert Harvey
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.