Ayrımcı sendikalar neden işlevsel programlama ile ilişkilendiriliyor?

OO programlamasının yıllarında, ayrımcı sendikaların ne olduğunu anladım, ancak onları gerçekten çok özlemedim. Son zamanlarda C # 'da bazı fonksiyonel programlama yapıyorum ve şimdi onlara sahip olmayı dilediğimi anlıyorum. Bu beni şaşırtıyor çünkü bunun karşısında, ayrımcı sendikalar kavramı işlevsel / OO ikilemesinden oldukça bağımsız görünüyor.

Ayrımcı sendikaları OO'da olacağından daha faydalı kılan işlevsel programlamanın doğasında var olan bir şey var mı, yoksa kendimi sorunu “daha ​​iyi” bir şekilde analiz etmeye zorlayarak, standartlarımı yükseltip şimdi daha iyi bir talepte bulunmamı sağladı mı? modellemek?

Ayrımcı sendikalar, vakalara bağlı olarak farklı davranışlar seçtiğiniz, desen eşleştirme ile birlikte parlar. Ancak bu model temelde antitetiktir saf OO prensiplerine aykırıdır.

Saf OO'da davranıştaki farklılıklar kendileri (nesneler) tarafından tanımlanmalı ve kapsüllenmelidir. Bu nedenle, desen eşleştirmeye eşdeğerlik, nesnenin kendisinde tek bir yöntem çağırmak olacaktır, bu daha sonra farklı davranışları tanımlamak için söz konusu alt türler tarafından aşırı yüklenir. Bir nesnenin tipini dışarıdan incelemek (örüntü eşleme yapan şeydir) antipattern olarak kabul edilir.

Temel fark, işlevsel programlamada veri ve davranışın ayrı olduğu ve veri ve davranışların OO'da kapsüllenmesidir.

Bu tarihsel sebep. C # gibi bir dil, daha fazla işlev özelliği ekleyerek klasik bir OO dilden çoklu paradigma diline doğru gelişiyor.

Fonksiyonel programlamayı öğrenmeden önce Pascal ve Ada'da programlanmış, ayrımcı sendikaları işlevsel programlama ile ilişkilendirmiyorum.

Ayrımcı sendikalar bir şekilde mirasın ikilisidir. Birincisi, sabit bir tür kümesinde (sendikadakiler) işlemleri kolayca eklemenize izin verir ve kalıtım, sabit bir işlem kümesine sahip türleri kolayca eklemenizi sağlar. (Her ikisinin de kolayca eklenmesi , ifade problemi olarak adlandırılır ; bu, statik tip sistemli diller için özellikle zor bir problemdir.)

OO'nun türler üzerindeki vurgusu ve işlevler üzerine fonksiyonel programlamanın ikili vurgusu nedeniyle, işlevsel programlama dilleri sendika tipleri için doğal bir afiniteye sahiptir ve kullanımlarını kolaylaştırmak için sözdizimsel yapılar sunar.

OO'da sıkça kullanıldığı gibi emperyal programlama teknikleri genellikle iki formata dayanır:

1. Başarılı ol veya istisna at,
2. null"Değersiz" olduğunu veya başarısız olduğunu göstermek için geri dönün .

İşlevsel paradigma tipik olarak her ikisinden de kaçınır, başarı / başarısızlık sebebi veya değer / değer içermeyen bir bileşik türü döndürmeyi tercih eder.

Ayrımcı sendikalar bu bileşik türler için faturaya uyuyor. Örneğin, ilk örnekte, geri döndürebilirsiniz trueveya arızayı tanımlayan bazı veri yapıları olabilir. İkinci durumda, bir değeri içeren ya da bir birlik içinde none, nilvb ikinci durumda birçok fonksiyonel diller yerleşik bu değer / hiçbiri birliği temsil edecek bir "belki" veya "seçeneği" türüne sahip olduğunu, bu nedenle sık görülür.

Örneğin, C # ile işlevsel bir stile geçerken, bu bileşik türlerine hızlı bir şekilde gereksinim duyacaksınız. void/throwve nullsadece böyle bir kod ile doğru hissetmiyorum. Ayrımcı sendikalar (DU) tasarıya iyi uyuyor. Böylece kendin de onları istediğin gibi buldunuz, tıpkı çoğumuz gibi.

İyi haber şu ki, örneğin C # modelindeki DU'ları modelleyen pek çok kütüphane var (örneğin kendi Succinc <T> kütüphaneme bakın).

Toplam türler, genel OO dillerinde, OO alt tiplemesine benzer bir problemi çözdükleri için genellikle daha az faydalı olacaktır. Onlara bakmanın bir yolu, her ikisinin de alt tiplemeyi ele almasıdır, ancak OO, openbir tanesi bir ebeveyn tipine isteğe bağlı alt tipler ekleyebilir ve toplam tipler, closedyani bir alt tipin hangi alt tiplerin geçerli olduğuna karar vermesidir.

Şimdi, birçok OO dili alt tiplemeyi, kalıtsal yapılar, polimorfizm, referans yazma vb. Gibi diğer kavramlarla birleştirerek bunları daha kullanışlı hale getiriyor. Bunun bir sonucu, (sınıflar ve kurucularla ve ne olursa olsun) kurmak için daha fazla çalışma eğiliminde olmalarıdır, bu yüzden Results ve Options gibi şeyler için kullanılmaya meyilli değillerdi, genel yazım yaygınlaşana kadar.

Ayrıca, çoğu insanın OO programlamaya başladıklarında öğrendikleri gerçek-dünya ilişkilerine odaklanmanın, örneğin Dog isa Animal, yani Integer'ın Sonuç ya da Hata ve sonuç olarak biraz yabancı göründüğünü söyleyebilirim. Fikirler oldukça benzer olsa da.

İşlevsel dillerin neden açık yazı yazmak için kapalı yazmayı tercih edebileceğine gelince, olası bir neden, kalıp eşleştirmeyi tercih etme eğiliminde olmalarıdır. Bu, işlev polimorfizmi için kullanışlıdır, ancak derleyici tüm alt tiplerin örtülüp örtülmediğini statik olarak kontrol edebildiği için kapalı tiplerle de iyi çalışır. Bu, dili daha tutarlı hissettirebilir, ancak herhangi bir içsel fayda olduğuna inanmıyorum (yanılıyor olabilirim).

Swift mutlu bir şekilde ayrımcı sendikalar kullanıyor, ancak onlara "enums" diyor. Enums, Swift'de sınıf, yapı, enum, tuple ve kapatma olan beş temel nesne kategorisinden biridir. Swift opsiyonları, sendikaları ayıran numaralardır ve herhangi bir Swift kodu için kesinlikle gereklidir.

Bu nedenle, "ayrımcı sendikaların işlevsel programlama ile ilişkilendirildiği" önceliği yanlıştır.