Monadlar miras hiyerarşilerine uygulanabilir (belki tercih edilebilir) bir alternatif midir?

Bir dil-agnostik kullanmak için gidiyorum açıklamasına ilk Monoids anlatan böyle monad'ların:

Bir monoid parametre olarak bir tür almak ve aynı tür dönmek fonksiyonların (kabaca) kümesidir.

Bir tek hücreli bir alan işlevler (kabaca) bir dizi sarma bir parametre olarak türüne ve aynı ambalaj tipini verir.

Bunların tanım değil, açıklama olduğunu unutmayın. Bu açıklamaya saldırmaktan çekinmeyin!

Yani bir OO dilinde, bir monad aşağıdaki gibi operasyon kompozisyonlarına izin verir:

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

Monad'ın içerdiği sınıftan ziyade bu işlemlerin anlambilimini tanımladığını ve kontrol ettiğini unutmayın.

Geleneksel olarak, bir OO dilinde, bu semantiği sağlamak için bir sınıf hiyerarşisi ve miras kullanırdık. Yani bir olurdu Birdyöntemlerle sınıfı takeOff(), flyAround()ve land(), ve Ördek olanlar miras olacaktır.

Ama sonra uçamayan kuşlarla başımız belaya girer, çünkü penguin.takeOff()başarısız olur. İstisna atma ve işleme başvurmak zorundayız.

Ayrıca, Penguin'in bir olduğunu söyledikten sonra Bird, örneğin bir hiyerarşisine sahipsek, çoklu kalıtımla ilgili sorunlarla karşılaşırız Swimmer.

Esasen sınıfları kategorilere ayırmaya çalışıyoruz (Kategori Teorisi adamlarından özür dileriz) ve tek tek sınıflardan ziyade semantiği kategoriye göre tanımlamaya çalışıyoruz. Fakat monadlar bunu yapmak için hiyerarşilerden çok daha açık bir mekanizma gibi görünüyorlar.

Bu durumda, Flier<T>yukarıdaki örnek gibi bir monadımız olacaktı:

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

... ve asla a Flier<Penguin>. Bunun bir işaretleyici arayüzü ile olmasını önlemek için statik yazmayı bile kullanabiliriz. Veya kefalet için çalışma zamanı yetenek kontrolü. Ama gerçekten, bir programcı asla bir Pengueni Flier'e koymamalı, aynı anlamda asla sıfırla bölmemelidir.

Ayrıca, daha genel olarak uygulanabilir. Bir pilotun Kuş olması gerekmez. Örneğin Flier<Pterodactyl>, veya Flier<Squirrel>bu bireysel türlerin anlambilimlerini değiştirmeden.

Anlambilimi, bir kaptaki, tür hiyerarşileri yerine, birleştirilebilir işlevlere göre sınıflandırdığımızda, "tür bir tür, belirli tür bir hiyerarşiye uymayan" sınıflarla ilgili eski sorunları çözer. Aynı zamanda kolayca ve açıkça gibi bir sınıf için birden semantiğini verir Flier<Duck>hem de Swimmer<Duck>. Görünüşe göre davranışı sınıf hiyerarşileri ile sınıflandırarak bir empedans uyumsuzluğu ile mücadele ediyoruz. Monadlar zarif bir şekilde idare eder.

Öyleyse sorum şu: Aynı şekilde miras üzerine kompozisyonu tercih etmeye geldiğimiz gibi, miras üzerine monadları da tercih etmek mantıklı mı?

(BTW Bunun burada mı yoksa Comp Sci'de mi olduğundan emin değildim, ancak bu daha pratik bir modelleme problemi gibi görünüyor. Ama belki orada daha iyi.)

Kısa cevap hayır , monadlar miras hiyerarşilerine (alt tip polimorfizm olarak da bilinir) bir alternatif değildir. Monadların yararlandığı ancak bunu yapacak tek şey olmayan parametrik polimorfizmi tarif ediyor gibi görünüyorsunuz .

Onları anladığım kadarıyla, monadların aslında kalıtımla hiçbir ilgisi yok. İki şeyin az çok dik olduğunu söyleyebilirim: farklı problemleri ele almaları amaçlanıyor ve bu yüzden:

1. En az iki anlamda sinerjik olarak kullanılabilirler:
   • Haskell'in tip sınıflarının çoğunu kapsayan Typeclassopedia'ya göz atın . Aralarında kalıtım benzeri ilişkiler olduğunu fark edeceksiniz. Örneğin, Monad, kendisi Functor'dan gelen Uygulayıcı'dan alınmıştır.
   • Monad örnekleri olan veri türleri sınıf hiyerarşilerine katılabilir. Unutmayın, Monad daha çok bir arayüz gibidir - belirli bir tür için uygulamak size veri türü hakkında bazı şeyler söyler, ancak her şeyi değil.
2. Birini diğerini yapmak için kullanmaya çalışmak zor ve çirkin olacaktır.

Son olarak, bu sorunuza teğet olmakla birlikte, monad'ların bestelemek için inanılmaz güçlü bazı yolları olduğunu öğrenmek isteyebilirsiniz; daha fazla bilgi edinmek için monad transformatörlerini okuyun. Bununla birlikte, bu hala aktif bir araştırma alanıdır, çünkü biz (ve biz, benden 100000x daha akıllı insanlar) monadlar oluşturmak için harika yollar bulmadık ve bazı monadlar keyfi olarak bestelenmiyor gibi görünüyor.

Şimdi sorunuzu nit-pick (üzgünüm, bunun yardımcı olması ve sizi kötü hissetmemesi için niyet ediyorum): Biraz ışık tutmaya çalışacağım birçok tartışmalı bina olduğunu hissediyorum.

1. Monad, kapsayıcı türünü parametre olarak alan ve aynı kapsayıcı türünü döndüren bir işlevler kümesidir.

   Hayır, bu bir MonadHaskell: Bir parametreli tip m abir uygulama ile return :: a -> m ave (>>=) :: m a -> (a -> m b) -> m başağıdaki yasaları tatmin:

   return a >>= k  ==  k a
   m >>= return  ==  m
   m >>= (\x -> k x >>= h)  ==  (m >>= k) >>= h
   

   Kaplar ( (->) b) olmayan bazı Monad örnekleri vardır ve Monad örnekleri olmayan (ve yapılamayan) bazı kaplar vardır ( Settip sınıfı kısıtlaması nedeniyle). Yani "konteyner" sezgisi kötüdür. Bkz bu fazla örnek için.

2. Yani bir OO dilinde, bir monad aşağıdaki gibi operasyon kompozisyonlarına izin verir:

     Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()
   

   Hayır, hiç de değil. Bu örnek bir Monad gerektirmez. İhtiyaç duyduğu tek şey, eşleşen giriş ve çıkış türlerine sahip işlevlerdir. İşte sadece fonksiyon uygulaması olduğunu vurgulayan başka bir yazma yolu:

   Flier<Duck> m = land(flyAround(takeOff(new Flier<Duck>(duck))));
   

   Bu bir "akıcı arayüz" veya "yöntem zincirleme" olarak bilinen bir desen olduğuna inanıyorum (ama emin değilim).

3. Monad'ın içerdiği sınıftan ziyade bu işlemlerin anlambilimini tanımladığını ve kontrol ettiğini unutmayın.

   Aynı zamanda monad olan veri türlerinin, monadlarla ilgisi olmayan işlemleri olabilir (ve neredeyse her zaman yapar!). İşte monadlarla []ilgisi olmayan üç fonksiyondan oluşan bir Haskell örneği : []"operasyonun semantiğini tanımlar ve kontrol eder" ve "içerilen sınıf" yoktur, ancak bu bir monad yapmak için yeterli değildir:

   \predicate -> length . filter predicate . reverse
   

4. Bir şeyleri modellemek için sınıf hiyerarşilerini kullanmada sorunlar olduğunu doğru bir şekilde not ettiniz. Bununla birlikte, örnekleriniz monadların yapabileceğine dair herhangi bir kanıt sunmuyor:

   • Mirasın iyi olduğu şeylerde iyi bir iş çıkar
   • Mirasın kötü olduğu şeylerde iyi bir iş çıkar

Öyleyse sorum şu: Aynı şekilde miras üzerine kompozisyonu tercih etmeye geldiğimiz gibi, miras üzerine monadları da tercih etmek mantıklı mı?

OO olmayan dillerde, evet. Daha geleneksel OO dillerinde hayır derim.

Sorun büyük diller yapamazsınız anlamına tip ihtisas sahibi kalmamasıdır Flier<Squirrel>ve Flier<Bird>farklı uygulamaları var. Böyle bir şey static Flier Flier::Create(Squirrel)(ve sonra her tür için aşırı yükleme) yapmanız gerekir . Bu da, yeni bir hayvan eklediğinizde bu türü değiştirmeniz ve muhtemelen çalışması için biraz kod çoğaltmanız gerektiği anlamına gelir.

Oh, ve Birkaç dilde (örneğin C #) public class Flier<T> : T {}yasadışı. İnşa etmeyecek bile. Çoğu, eğer tüm OO programcıları Flier<Bird>hala bir olmasını beklerdi Bird.