Fonksiyonel programlama için bir yazılım mühendisliği metodolojisi var mı? [kapalı]

Yazılım Mühendisliği bugün öğretildiği şekliyle, tamamen nesne yönelimli programlamaya ve dünyanın 'doğal' nesne yönelimli görünümüne odaklanmaktadır. Bir etki alanı modelinin çeşitli adımlarla bir sınıf modeline nasıl dönüştürüleceğini ve kullanım-durum diyagramları veya sınıf diyagramları gibi çok sayıda (UML) yapay nesneyi nasıl açıklayacağınızı açıklayan ayrıntılı bir yöntem vardır. Birçok programcı bu yaklaşımı içselleştirmiştir ve sıfırdan nesne yönelimli bir uygulamanın nasıl tasarlanacağı konusunda iyi bir fikre sahiptir.

Yeni hype, birçok kitap ve öğreticide öğretilen fonksiyonel programlamadır. Peki ya fonksiyonel yazılım mühendisliği? Lisp ve Clojure hakkında okurken, iki ilginç ifade geldi:

1. Fonksiyonel programlar genellikle yukarıdan aşağıya yerine aşağıdan yukarıya doğru geliştirilir ('On Lisp', Paul Graham)

2. Fonksiyonel Programcılar, OO-Programmerlerin nesneleri / sınıfları ('Java Programcılar için Clojure', Rich Hickley tarafından konuşulur) kullandığı Haritalar'ı kullanır.

Peki işlevsel bir uygulamanın sistematik (model tabanlı?) Tasarımının metodolojisi nedir, örneğin Lisp veya Clojure? Ortak adımlar nelerdir, hangi eserleri kullanıyorum, bunları problem alanından çözüm alanına nasıl eşlerim?

Şükürler olsun ki, yazılım mühendisliği insanları henüz fonksiyonel programlamayı keşfetmediler. İşte bazı paralellikler:

• Birçok OO "tasarım deseni" daha üst düzey işlevler olarak yakalanır. Örneğin, Ziyaretçi modeli işlevsel dünyada "kıvrım" olarak bilinir (ya da sivri başlı bir teorisyenseniz, bir "katamorfizm"). İşlevsel dillerde, veri türleri çoğunlukla ağaç veya tuple'dir ve her ağaç türünün kendisiyle ilişkili doğal bir katamorfizması vardır.

  Bu üst düzey işlevler genellikle "serbest teoremler" gibi belirli programlama yasalarıyla birlikte gelir.

• Fonksiyonel programcılar diyagramları OO programcılarına göre çok daha az kullanırlar. OO diyagramlarında ifade edilenlerin çoğu bunun yerine türlerde veya "modül türleri" olarak düşünmeniz gereken "imzalarda" ifade edilir . Haskell ayrıca bir arayüz tipine benzeyen "tip sınıflarına" sahiptir.

  Türleri kullanan işlevsel programcılar genellikle "türler doğru olduğunda; kod pratikte kendini yazar" diye düşünür.

  Tüm işlevsel diller açık türleri kullanmaz, ancak Scheme / Lisp / Clojure öğrenmek için mükemmel bir kitap olan Nasıl Yapılır Programları kitabı, türlerle yakından ilişkili olan "veri açıklamalarına" dayanır.

Peki işlevsel bir uygulamanın sistematik (model tabanlı?) Tasarımının metodolojisi nedir, örneğin Lisp veya Clojure?

Veri soyutlamaya dayanan herhangi bir tasarım yöntemi iyi çalışır. Dilin açık türleri olduğunda bunun daha kolay olduğunu düşünüyorum, ama onsuz da çalışıyor. Fonksiyonel programlamaya kolayca adapte edilebilen soyut veri türleri için tasarım yöntemleri hakkında iyi bir kitap , ilk baskı Barbara Liskov ve John Guttag tarafından Program Geliştirmede Soyutlama ve Spesifikasyon'dur . Liskov kısmen bu iş için Turing ödülünü kazandı.

Lisp'e özgü bir başka tasarım metodolojisi, çalıştığınız sorun alanında hangi dil uzantılarının yararlı olacağına karar vermek ve daha sonra bu yapıları dilinize eklemek için hijyenik makrolar kullanmaktır. Bu tür bir tasarım hakkında okumak için iyi bir yer, Matthew Flatt'un Rakette Dil Oluşturma makalesidir . Makale bir ödeme duvarının arkasında olabilir. "Etki alanına özgü gömülü dil" terimini arayarak bu tür tasarım hakkında daha genel materyaller de bulabilirsiniz; Matthew Flatt'un kapsadığı şeyin ötesinde özel tavsiyeler ve örnekler için, muhtemelen Graham'ın On Lisp veya belki de ANSI Ortak Lisp ile başlayacağım .

Ortak adımlar nelerdir, hangi eserleri kullanıyorum?

Ortak adımlar:

1. Programınızdaki verileri ve üzerindeki işlemleri belirleyin ve bu verileri temsil eden soyut bir veri türü tanımlayın.

2. Sık kullanılan eylemleri veya hesaplama modellerini tanımlayın ve bunları üst düzey işlevler veya makrolar olarak ifade edin. Yeniden düzenleme sürecinin bir parçası olarak bu adımı atmayı bekleyin.

3. Yazılı bir işlevsel dil kullanıyorsanız, tür denetleyicisini erken ve sık kullanın. Lisp veya Clojure kullanıyorsanız, en iyi uygulama önce birim testleri de dahil olmak üzere işlev sözleşmeleri yazmaktır - bu test maks. Ve QuickCheck'in platformunuza taşınan herhangi bir sürümünü kullanmak isteyeceksiniz, ki bu durumda ClojureCheck olarak adlandırılıyor . Üst düzey işlevleri kullanan rastgele kod testleri oluşturmak için son derece güçlü bir kitaplıktır.

Clojure için eski iyi ilişkisel modellemeye geri dönmenizi tavsiye ederim. Tarpit dışında ilham verici bir okuma.

Kişisel olarak, OO geliştirmenin tüm olağan iyi uygulamalarının fonksiyonel programlamada da geçerli olduğunu görüyorum - sadece fonksiyonel dünya görüşünü dikkate almak için birkaç küçük değişiklikle. Metodoloji açısından bakıldığında, temelde farklı bir şey yapmanıza gerek yoktur.

Deneyimlerim son yıllarda Java'dan Clojure'a geçmekten geliyor.

Bazı örnekler:

• İş etki alanınızı / veri modelinizi anlayın - bir nesne modeli tasarlayacak veya iç içe haritalarla işlevsel bir veri yapısı oluşturacak olmanız aynı derecede önemlidir. Bazı açılardan, FP daha kolay olabilir çünkü veri modelini fonksiyonlardan / süreçlerden ayrı düşünmeye teşvik eder, ancak yine de her ikisini de yapmanız gerekir.

• Tasarımda servis yönelimi - aslında bir FP perspektifinden çok iyi çalışır, çünkü tipik bir hizmet gerçekten sadece bazı yan etkilere sahip bir işlevdir. Ben Lisp dünyasında bazen benimsenen yazılım geliştirme "aşağıdan yukarıya" görüş aslında başka bir kisvede sadece iyi hizmet odaklı API tasarım ilkeleri olduğunu düşünüyorum.

• Test Odaklı Geliştirme - FP dillerinde iyi çalışır, aslında bazen daha da iyidir, çünkü saf işlevler, durumlu bir ortam kurmaya gerek kalmadan net, tekrarlanabilir testler yazmak için kendilerini çok iyi bir şekilde verir. Ayrıca veri bütünlüğünü kontrol etmek için ayrı testler de yapmak isteyebilirsiniz (örneğin, bu haritada beklediğim tüm anahtarlar var mı, OO dilinde sınıf tanımının bunu derleme zamanında sizin için zorlayacağı gerçeğini dengelemek için).

• Prototipleme / yineleme - FP ile de çalışır. Araçlar / DSL oluşturma ve bunları REPL'de kullanma konusunda son derece iyi olursanız, kullanıcılarla canlı prototip oluşturabilirsiniz.

OO programlama, verileri davranışla sıkıca birleştirir. Fonksiyonel programlama ikisini birbirinden ayırır. Sınıf diyagramlarınız yok, ancak veri yapılarınız var ve özellikle cebirsel veri türleriniz var. Bu türler, inşaat yoluyla imkansız değerlerin ortadan kaldırılması da dahil olmak üzere alan adınıza çok sıkı uyması için yazılabilir.

Yani üzerinde kitap ve kitap yok, ama deyişle, imkansız değerleri temsil edilemez kılmak için iyi kurulmuş bir yaklaşım var.

Bunu yaparken, belirli veri türlerini işlevler olarak temsil etme ve bunun yerine belirli işlevleri veri türleri birliği olarak temsil etme hakkında bir dizi seçenek yapabilirsiniz, böylece seri hale getirme, daha sıkı belirtim, optimizasyon vb. .

Daha sonra, bir tür cebir oluşturacak şekilde reklamlarınız üzerine işlevler yazarsınız - yani bu işlevler için sabit yasalar vardır. Bazıları belki idempotenttir - birden fazla uygulamadan sonra aynı. Bazıları çağrışımsaldır. Bazıları geçişlidir, vb.

Artık, üzerinde iyi davranmış yasalara göre oluşturulan işlevlere sahip olduğunuz bir alanınız var. Basit bir gömülü DSL!

Oh, ve verilen özellikler, elbette bunların otomatik rastgele testlerini yazabilirsiniz (ala QuickCheck) .. ve bu sadece başlangıç.

Nesneye Dayalı tasarım, yazılım mühendisliğiyle aynı şey değildir. Yazılım mühendisliği, gereksinimlerden çalışan bir sisteme zamanında ve düşük hata oranına nasıl geçtiğimizle ilgili tüm süreçle ilgilidir. İşlevsel programlama OO'dan farklı olabilir, ancak gereksinimler, üst düzey ve ayrıntılı tasarımlar, doğrulama ve test, yazılım metrikleri, tahmin ve diğer tüm "yazılım mühendisliği" leri ortadan kaldırmaz.

Ayrıca, fonksiyonel programlar modülerlik ve diğer yapılar sergiler. Detaylı tasarımlarınız bu yapıdaki kavramlar cinsinden ifade edilmelidir.

Bir yaklaşım, seçilen işlevsel programlama dilinde dahili bir DSL oluşturmaktır. Bu durumda "model" DSL'de ifade edilen iş kuralları kümesidir.

Başka bir gönderiye verdiğim cevaba bakın:

Clojure Endişelerin Ayrılmasını Nasıl Yaklaştırıyor?

Bir FP yaklaşımı kullanan büyük uygulamaların nasıl yapılandırılacağı konusunda daha fazla konu yazılması gerektiğine katılıyorum.

Bu naif ve basit kabul edilebilir olsa da, "tasarım tarifleri" (Felleisen ve arkadaşları tarafından HtDP kitabında savunulduğu gibi programlamaya uygulanan problem çözme için sistematik bir yaklaşım ) aradığınıza yakın olacaktır.

İşte birkaç bağlantı:

http://www.northeastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371

Bu kitabı yakın zamanda buldum: Fonksiyonel ve Reaktif Alan Modellemesi

Sorunuzla mükemmel bir şekilde uyumlu olduğunu düşünüyorum.

Kitap açıklamasından:

İşlevsel ve Reaktif Etki Alanı Modellemesi, etki alanı modelini saf işlevler açısından nasıl düşüneceğinizi ve daha büyük soyutlamalar oluşturmak için bunları nasıl oluşturacağınızı öğretir. Fonksiyonel programlamanın temelleri ile başlayacak ve karmaşık etki alanı modellerini uygulamak için bilmeniz gereken gelişmiş kavramlara ve kalıplara yavaş yavaş ilerleyeceksiniz. Kitap, cebirsel veri türleri, tip sınıfı tabanlı tasarım ve yan etkilerin izolasyonu gibi gelişmiş FP modellerinin modelinizi okunabilirlik ve doğrulanabilirlik için nasıl oluşturabileceğini göstermektedir.

Oxford Üniversitesi'nde (İngiltere) Prof. Richard Bird ve Programlama Cebiri grubuyla ilişkili "program hesaplaması" / "hesaplamaya göre tasarım" tarzı vardır, bunun bir metodoloji olduğunu düşünmek için çok fazla getirilmiş olduğunu düşünmüyorum.

Şahsen, AoP grubunun ürettiği işi sevdiğimde, tasarımı bu şekilde kendim uygulayacak disiplini yok. Ancak bu benim eksikliğim ve program hesaplamalarından biri değil.

Davranış Odaklı Geliştirme, Clojure ve SBCL'de hızla gelişen kod için doğal bir uyum olarak buldum. BDD'yi işlevsel bir dille kullanmanın asıl tersi, prosedürel dilleri kullanırken genellikle yaptığımdan çok daha ince tane birimi testleri yazma eğiliminde olduğumdur, çünkü problemi daha küçük işlevsellik parçalarına ayırmak için çok daha iyi bir iş yapıyorum.

Dürüst olmak gerekirse, işlevsel programlar için tasarım tarifleri istiyorsanız, Haskell'in Prelude gibi standart işlev kitaplıklarına bakın. FP'de modeller genellikle daha yüksek dereceli prosedürlerle (işlevler üzerinde çalışan işlevler) kendileri tarafından yakalanır. Dolayısıyla, bir desen görülürse, genellikle bu deseni yakalamak için daha yüksek bir sıra işlevi oluşturulur.

İyi bir örnek fmap. Bu işlev bir işlevi bağımsız değişken olarak alır ve ikinci bağımsız değişkenin tüm "öğelerine" uygular. Functor türü sınıfının bir parçası olduğu için, herhangi bir Functor örneği (liste, grafik vb.) Bu işleve ikinci bir argüman olarak iletilebilir. Bir fonksiyonun ikinci argümanının her elemanına uygulanmasının genel davranışını yakalar.

İyi,

Genellikle birçok Fonksiyonel Programlama Dili üniversitelerde "küçük oyuncak problemleri" için uzun süre kullanılmaktadır.

OOP, "durum" nedeniyle "paralel programlama" ile ilgili zorluklar yaşadığı için artık daha popüler hale geliyor ve Google MapReduce gibi sorun için bazen işlevsel tarz daha iyi.

Ben functioanl adamlar [1.000.000 satır kodundan daha büyük sistemleri uygulamaya çalışın] duvara çarptığında, bazılarının vızıltı kelimelerle yeni yazılım mühendisliği metodolojileri ile geleceğinden eminim :-). Eski soruyu cevaplamalıdırlar: Her bir parçayı birer birer "ısırmak" için sistemi parçalara nasıl bölebiliriz? İşlevsel Stili kullanarak [yinelemeli, inceremental ve evrimsel yolla çalışma].

Fonksiyonel Tarzın Nesneye Dayalı Tarzımızı etkileyeceğinden eminiz. Fonksiyonel Sistemlerden pek çok kavramı “hala” ve OOP dilimize uyarladık.

Ancak bu kadar büyük sistemler için fonksiyonel programlar kullanılacak mı? Soru bu .

Ve kimse böyle büyük sistemleri uygulamadan gerçekçi yöntemlerle gelemez, ellerini kirletmez. Önce ellerinizi kirletmeli sonra çözüm önermelisiniz. "Gerçek ağrı ve kir" olmadan Çözümler-Öneriler "fantezi" olacaktır.