Fonksiyonel tarzda programlama yaparken, uygulama mantığından geçtiğiniz tek bir uygulama durumunuz var mı?

Aşağıdakilerin tümüne sahip bir sistemi nasıl kurarım :

1. Değişmez nesnelerle saf fonksiyonların kullanılması.
2. Sadece ihtiyaç duyduğu işlevin bir işlev verilerine aktarın, daha fazla değil (yani büyük uygulama durumu nesnesi yok)
3. İşlevler için çok fazla argüman bulundurmaktan kaçının.
4. Fonksiyonlara çok fazla parametrenin aktarılmasını önlemek için, sadece işlevlere parametrelerin paketlenmesi ve paketlerinin açılması amacıyla yeni nesneler oluşturmaktan kaçının. Bir işleve tek bir nesne olarak birden çok öğe paketleyeceğim, bu nesnenin geçici olarak oluşturulmuş bir şey değil, söz konusu verilerin sahibi olmasını istiyorum

Bana öyle geliyor ki, Devlet monad kuralı 2 numaralı kuralı ihlal ediyor, ancak bu açık olmasa da, monad boyunca dokunmuş.

Lensleri bir şekilde kullanmam gerektiğini hissediyorum, ancak İşlevsel olmayan diller için çok az şey yazıldı.

Arka fon

Bir alıştırma olarak, var olan uygulamalarımdan birini nesne yönelimli bir stilden işlevsel bir stile dönüştürüyorum. Yapmaya çalıştığım ilk şey, uygulamanın iç çekirdeğini olabildiğince yapmak.

Duyduğum bir şey, "Devlet" i tamamen işlevsel bir dilde nasıl yöneteceğimi ve Devlet monadsları tarafından yapıldığına inandığım şey, mantıksal olarak, saf bir işlev olarak adlandırdığınız, dünya olduğu gibi ", sonra işlev geri döndüğünde, değiştikçe dünyanın durumuna geri döner.

Örnek olarak, "merhaba bir dünya" yı tamamen işlevsel bir şekilde yapma şekliniz, sanki ekranınızın bu durumunu programınıza aktarır ve üzerine "merhaba dünya" yazılı ekranın durumunu geri alırsınız. Yani teknik olarak, saf bir işlevi çağırıyorsunuz ve hiçbir yan etkisi yok.

Buna dayanarak başvurumu inceledim ve: 1. İlk olarak tüm uygulama durumumu tek bir global nesneye (GameState) koy 2. İkinci olarak GameState'i değişmez hale getirdim. Değiştiremezsiniz. Bir değişikliğe ihtiyacınız varsa, yeni bir değişiklik yapmanız gerekir. Bunu, isteğe bağlı olarak değişen bir veya daha fazla alanı alan bir kopya oluşturucu ekleyerek yaptım. 3. Her uygulamaya GameState'i parametre olarak iletiyorum. İşlev içinde, ne yapacağını yaptıktan sonra, yeni bir GameState oluşturur ve geri döndürür.

Nasıl saf bir fonksiyonel çekirdek ve dış GameState uygulamanın ana iş akışı döngü besleyen bir döngü var.

Benim sorum:

Şimdi, benim sorunum, GameState'in yaklaşık 15 farklı değişmez nesneye sahip olmasıdır. En düşük seviyedeki işlevlerin çoğu, puan tutma gibi bu nesnelerin yalnızca birkaçında çalışır. Diyelim ki skoru hesaplayan bir fonksiyonum var. Bugün, GameState yeni bir skorla yeni GameState oluşturarak skoru değiştiren bu fonksiyona aktarılıyor.

Bununla ilgili bir şeyler yanlış görünüyor. İşlev için GameState'in tamamı gerekmez. Sadece Score nesnesine ihtiyacı var. Bu yüzden Skoru geçmek ve sadece Skoru döndürmek için güncelledim.

Bu mantıklı görünüyordu, bu yüzden diğer işlevlerle daha ileri gittim. Bazı işlevler GameState'ten 2, 3 veya 4 parametre geçirmemi gerektiriyor, ancak deseni uygulamanın dış çekirdeğine kadar kullandığım için, uygulama durumunu giderek daha fazla geçiyorum. İş akışı döngüsünün en üstünde, bir yöntemi çağırırdım, bu yöntemi bir yöntemi çağıracak yöntemi çağırırdı, puanın hesaplandığı yere kadar. Bu, en alttaki bir fonksiyonun skoru hesaplayacağı için mevcut skorun tüm bu katmanlardan geçtiği anlamına gelir.

Şimdi bazen onlarca parametreyle fonksiyonum var. Parametrelerin sayısını azaltmak için bu parametreleri bir nesneye koyabilirim, ancak daha sonra, sadece geçmemek için sadece çağrı sırasında inşa edilen bir nesne yerine, bu sınıfın durum uygulama durumunun ana konumu olmasını isterim. birden çok parametrede ve ardından paketinden çıkarın.

Şimdi merak ediyorum, sorunum fonksiyonlarımın çok derin yuvalanmış mı? Bu, küçük işlevlere sahip olmak istemenin sonucudur, bu nedenle bir işlev büyüdüğünde yeniden düzenler ve birden çok küçük işleve bölerim. Ancak bunu yapmak daha derin bir hiyerarşi üretir ve dış işlev doğrudan bu nesneler üzerinde çalışmasa bile iç işlevlere iletilen herhangi bir şeyin dış işleve iletilmesi gerekir.

Bu sorundan kaçınan yol boyunca GameState'i geçmek gibi görünüyordu. Ama işleve ihtiyaç duyduğundan daha fazla bilgi aktarma konusundaki asıl probleme geri döndüm.

İyi bir çözüm olup olmadığından emin değilim. Bu bir cevap olabilir veya olmayabilir, ancak bir yorum yapmak için çok uzun. Benzer bir şey yapıyordum ve aşağıdaki hileler yardımcı oldu:

• GameStateHiyerarşik olarak bölün , böylece 15 yerine 3-5 daha küçük parça elde edersiniz.
• Arayüzleri uygulamasına izin verin, böylece yöntemleriniz sadece gerekli parçaları görür. Gerçek tür hakkında kendinize yalan söyleyeceğiniz gibi onları asla geri atmayın.
• Ayrıca parçaların arayüzleri uygulamasına izin verin, böylece ne geçtiğinizi iyi kontrol edebilirsiniz.
• Parametre nesnelerini kullanın, ancak bunu dikkatli bir şekilde yapın ve bunları kendi davranışlarıyla gerçek nesnelere dönüştürmeye çalışın.
• Bazen gerekenden biraz daha fazla geçmek uzun bir parametre listesinden daha iyidir.

Şimdi merak ediyorum, sorunum fonksiyonlarımın çok derin yuvalanmış mı?

Ben öyle düşünmüyorum. Küçük işlevlere yeniden bakmak doğru, ancak belki onları daha iyi yeniden gruplandırabilirsiniz. Bazen mümkün değildir, bazen soruna ikinci (veya üçüncü) bir bakış gerekir.

Tasarımınızı değiştirilebilir tasarımla karşılaştırın. Yeniden yazmada kötüleşen şeyler var mı? Eğer öyleyse, onları ilk yaptığınız gibi daha iyi hale getiremez misiniz?

C # ile konuşamam, ama Haskell'de bütün devleti geçeceksin. Bunu açık bir şekilde veya bir Devlet monad ile yapabilirsiniz. İhtiyaç duydukları zaman daha fazla bilgi alan fonksiyonlar sorununu çözmek için yapabileceğiniz bir şey Has karakter sınıflarını kullanmaktır. (Eğer alışık değilseniz, Haskell karakteristikleri C # arayüzlerine benzer.) E-devletin her elemanı için, E değerini döndüren getE işlevi gerektiren bir tipeclass HasE tanımlayabilirsiniz. bütün bu tip örneklerin bir örneğini oluşturdu. Daha sonra gerçek işlevlerinizde, Devlet monad'ınızı açıkça istemek yerine, ihtiyacınız olan öğeler için Has tip sınıflarına ait herhangi bir monad'a ihtiyacınız vardır; bu fonksiyonun kullandığı monad ile yapabileceklerini kısıtlar. Bu yaklaşım hakkında daha fazla bilgi için, bkz. Michael SnoymanReaderT tasarım deseni üzerine yazı .

Etrafta geçirilen durumu nasıl tanımladığınıza bağlı olarak, muhtemelen böyle bir şeyi C # 'da çoğaltabilirsiniz. Gibi bir şeyin varsa

public class MyState
{
    public int MyInt {get; set; }
    public string MyString {get; set; }
}

Eğer arabirimleri tanımlayabilir IHasMyIntve IHasMyStringyöntemlerle GetMyIntve GetMyStringsırasıyla. Devlet sınıfı daha sonra şöyle görünür:

public class MyState : IHasMyInt, IHasMyString
{
    public int MyInt {get; set; }
    public string MyString {get; set; }
    public double MyDouble {get; set; }

    public int GetMyInt () 
    {
        return MyInt;
    }

    public string GetMyString ()
    {
        return MyString;
    }

    public double GetMyDouble ()
    {
        return MyDouble;
    }
}

yöntemleriniz için uygun şekilde IHasMyInt, IHasMyString veya tüm MyState gerekebilir.

Daha sonra, durum nesnesini iletebilmeniz için işlev tanımındaki where kısıtlamasını kullanabilirsiniz, ancak çift değil, yalnızca string ve int'e ulaşabilir.

public static T DoSomething<T>(T state) where T : IHasMyString, IHasMyInt
{
    var s = state.GetMyString();
    var i = state.GetMyInt();
    return state;
}

Sanırım Redux veya Elm ve bu soruyu nasıl ele aldıkları hakkında bilgi edinmeniz iyi olur.

Temel olarak, tüm durumu ve kullanıcının gerçekleştirdiği eylemi alan ve yeni durumu döndüren bir saf fonksiyonunuz vardır.

Bu işlev daha sonra her biri belirli bir devlet parçasını işleyen diğer saf işlevleri çağırır. Eyleme bağlı olarak, bu işlevlerin çoğu orijinal durumunu değiştirmeden başka bir şey yapamaz.

Daha fazla bilgi edinmek için Google Karaağaç Mimarisi veya Redux.js.org.

Bence yapmaya çalıştığınız şey nesneye yönelik bir dili, sanki saf işlevsel bir dilmiş gibi kullanılmaması gereken bir şekilde kullanmaktır. OO dilleri tüm kötülükler gibi değil. Her iki yaklaşımın da avantajları vardır, bu yüzden şimdi OO stilini işlevsel stille karıştırabilir ve bazı kod parçalarını işlevsel hale getirme şansına sahip olurken, diğerleri yeniden kullanılabilirlik, kalıtım veya polimofizmin avantajlarından yararlanabilmemiz için nesne odaklı kalır. Neyse ki artık sadece iki yaklaşıma da bağlı değiliz, o zaman neden kendinizi bunlardan biriyle sınırlamaya çalışıyorsunuz?

Sorunuzu cevaplama: hayır, uygulama mantığı yoluyla belirli bir durumu örmem, ancak mevcut kullanım durumu için uygun olanı kullanmam ve mevcut teknikleri en uygun şekilde uygulama.

C # (henüz) istediğiniz gibi işlevsel olarak kullanılmaya hazır değil.