Geçenlerde C # 'da İşlevsel Programlama başlıklı bir kitap okudum ve bana göre işlevsel programlamanın değişmez ve vatansız doğası bağımlılık enjeksiyon modellerine benzer sonuçlar elde ediyor ve muhtemelen özellikle birim test konusunda daha iyi bir yaklaşım.

Her iki yaklaşımla da deneyimi olan birisinin, asıl soruya cevap vermek için düşüncelerini ve deneyimlerini paylaşması halinde minnettar olurum: İşlevsel Programlama bağımlılık enjeksiyon modellerine uygulanabilir bir alternatif midir?

Bağımlılık yönetimi, aşağıdaki iki nedenden ötürü OOP'ta büyük bir sorundur:

• Veri ve kodun sıkı eşleşmesi.
• Ubiquitous yan etkilerin kullanılması.

Çoğu OO programcısı, veri ve kodun sıkı bir şekilde birleştirilmesinin tamamen faydalı olduğunu düşünür, ancak bunun bir bedeli vardır. Veri akışını katmanlar arasında yönetmek, herhangi bir paradigmada programlamanın kaçınılmaz bir parçasıdır. Verilerinizi ve kodunuzu birleştirmek, bir işlevi belirli bir noktada kullanmak istiyorsanız , nesnesini bu noktaya getirmenin bir yolunu bulmanız gerekecek ek sorunu da ekler .

Yan etkilerin kullanılması da benzer zorluklar yaratır. Bazı işlevler için bir yan etki kullanıyorsanız, ancak uygulanmasını değiştirebilmek istiyorsanız, bu bağımlılığı enjekte etmekten başka seçeneğiniz yok.

Örnek olarak, e-posta adresleri için web sayfalarını kazıyan ve ardından e-postayla gönderen bir spamcı program olarak düşünün. Eğer bir DI zihniyetiniz varsa, şu anda arayüzlerin arkasına yerleştireceğiniz hizmetleri ve hangi servislerin nereye enjekte edileceğini düşünüyorsunuz. Bu tasarımı okuyucu için bir alıştırma olarak bırakacağım. Bir FP zihniyetiniz varsa, şu anda en düşük fonksiyon katmanının giriş ve çıkışlarını düşünüyorsunuz:

• Bir web sayfası adresi girin, o sayfanın metnini verin.
• Bir sayfanın metnini girin, o sayfanın bağlantılarının bir listesini alın.
• Bir sayfanın metnini girin, o sayfaya bir e-posta adresi listesi verin.
• Bir e-posta adresi listesi girin, yinelenenleri kaldırılmış bir e-posta adresi listesi verin.
• Bir e-posta adresi girin, bu adres için bir spam e-posta gönderin.
• Bir spam e-posta girin, bu e-postayı göndermek için SMTP komutlarını verin.

Giriş ve çıkışlar açısından düşündüğünüz zaman, fonksiyon bağımlılığı yoktur, sadece veri bağımlılığı vardır. Onları ünite testi için bu kadar kolay kılan şey budur. Bir sonraki katmanınız, bir işlevin çıktısının diğerinin girişine beslenmesini düzenler ve gerektiğinde çeşitli uygulamaları kolayca değiştirebilir.

Çok gerçek anlamda, fonksiyonel programlama doğal olarak, fonksiyon bağımlılıklarınızı her zaman tersine çevirmenizi sağlar ve bu nedenle genellikle bundan sonra yapmak için özel bir önlem almak zorunda kalmazsınız. Bunu yaptığınızda, daha yüksek dereceli fonksiyonlar, kapaklar ve kısmi uygulama gibi araçlar daha az boylerle elde etmeyi kolaylaştırır.

Kendisinin sorunlu olan bağımlılıklar olmadığını unutmayın. Yanlış yöne işaret eden bağımlılıklar . Bir sonraki katman yukarı gibi bir işlevi olabilir:

processText = spamToSMTP . emailAddressToSpam . removeEmailDups . textToEmailAddresses

Bu katmanın, bunun gibi zor kodlanmış bağımlılıklara sahip olması tamamen iyidir, çünkü tek amacı alt kat fonksiyonlarını birbirine yapıştırmaktır. Bir uygulamayı değiştirmek, farklı bir kompozisyon oluşturmak kadar kolaydır:

processTextFancy = spamToSMTP . emailAddressToFancySpam . removeEmailDups . textToEmailAddresses

Bu kolay yeniden birleşme, yan etkilerin eksikliği ile mümkün olmaktadır. Alt katman fonksiyonları birbirinden tamamen bağımsızdır. Bir sonraki katman processText, bazı kullanıcı yapılandırmalarına göre hangisinin gerçekten kullanılacağını seçebilir :

actuallyUsedProcessText = if (config == "Fancy") then processTextFancy else processText

Yine, bir sorun değil çünkü tüm bağımlılıklar bir yönden işaret ediyor. Hepsinin aynı şekilde işaret etmesini sağlamak için bazı bağımlılıkları tersine çevirmemize gerek yok, çünkü saf işlevler bizi zaten yapmaya zorladı.

configBunu en üstte kontrol etmek yerine en alt katmana geçerek daha çok birleştirebileceğinizi unutmayın . FP bunu yapmanıza engel olmaz, ancak denerseniz çok daha can sıkıcı hale gelme eğilimindedir.

Programlama bağımlılık enjeksiyon kalıplarına uygulanabilir bir alternatif nedir?

Bu beni garip bir soru olarak vurguluyor. İşlevsel Programlama yaklaşımları, bağımlılık enjeksiyonuna büyük ölçüde teğetdir.

Tabii ki, değişmeyen duruma sahip olmak sizi yan etkiler yaparak ya da sınıf durumunu işlevler arasında gizli bir sözleşme olarak kullanarak "aldatmaya" zorlayabilir. Verilerin aktarılmasını daha açık hale getirir, sanırım bağımlılık enjeksiyonunun en temel şeklidir. Ve etrafta dolaşan fonksiyonların işlevsel programlama konsepti bunu çok daha kolaylaştırır.

Ancak bağımlılıkları ortadan kaldırmaz. Operasyonlarınız hala durumunuz değiştiğinde ihtiyaç duydukları tüm veriye / işlemlere ihtiyaç duyuyor. Ve hala o bağımlılıkları bir şekilde oraya götürmen gerekiyor. Bu yüzden işlevsel programlama yaklaşımlarının DI'nin yerini aldığını söyleyemem , bu yüzden başka bir alternatif yok.

Herhangi bir şey varsa, size OO kodunun programcıların nadiren düşündüğünden daha fazla bağımlılık yaratabildiğini gösterdiler.

Sorunuza hızlı cevap: Hayır .

Ancak başkalarının iddia ettiği gibi, soru iki, biraz alakasız kavramları ile evlenir.

Bu adımı adım adım yapalım.

DI, işlevsel olmayan stille sonuçlanır

İşlev programlamasının temelinde saf işlevler vardır - girdiyi çıktıya eşleyen işlevler, böylece belirli bir girdi için her zaman aynı çıktıyı elde edersiniz.

DI tipik olarak , birimin artık saf olmadığı anlamına gelir çünkü çıktı enjeksiyona bağlı olarak değişebilir. Örneğin, aşağıdaki işlevde:

const bookSeats = ( seatCount, getBookedSeatCount ) => { ... }

getBookedSeatCount(bir işlev) aynı giriş için farklı sonuçlar verecek şekilde değişebilir. Bu da bookSeatssaf değildir.

Bunun için istisnalar vardır - farklı algoritmalar kullanıyor olsa da, aynı giriş-çıkış eşlemesini uygulayan iki sıralama algoritmasından birini enjekte edebilirsiniz. Ancak bunlar istisnalar.

Bir sistem saf olamaz

Bir sistemin saf olamaması gerçeği, işlevsel programlama kaynaklarında iddia edildiği gibi aynı şekilde göz ardı edilir.

Bir sistemin açık örnekleri ile yan etkileri olması gerekir:

• UI
• Veritabanı
• API (istemci-sunucu mimarisinde)

Bu yüzden sisteminizin bir kısmı yan etkiler içermeli ve bu kısım da zorunlu stil veya OO stilini içerebilir.

Kabuk-çekirdek paradigması

Terimleri Gary Bernhardt'ın sınırlar üzerine yaptığı mükemmel konuşmadan ödünç alarak , iyi bir sistem (veya modül) mimarisi bu iki katmanı içerecektir:

• çekirdek
  • Saf fonksiyonlar
  • Dallanma
  • Bağımlılık yok
• Kabuk
  • Impure (yan etkiler)
  • Dallanma yok
  • Bağımlılıklar
  • Zorunlu olabilir, OO stili vb. İçerir.

Anahtar paket, sistemi 'saf parçaya (çekirdek) ve saf parçaya (kabuk)' ayırmaktır.

Hafif kusurlu bir çözüm (ve sonuç) sunmasına rağmen, bu Mark Seemann'ın makalesi aynı konsepti önermektedir. Haskell uygulaması, hepsinin FP kullanarak yapılabileceğini gösterdiği gibi, özellikle anlayışlı.

DI ve FP

DI'nin kullanılması, uygulamanızın büyük bir kısmı saf olsa bile tamamen mantıklıdır. Anahtar DI'yi saf olmayan kabuk içinde sınırlamaktır.

Bir örnek API saplamaları olacaktır - üretimde gerçek API'yi istiyorsunuz, ancak testlerde saplamalar kullanın. Kabuk-çekirdek modeline bağlı kalmak burada çok yardımcı olacaktır.

Sonuç

Yani FP ve DI tam olarak alternatif değil. Hem sisteminizde olması muhtemeldir hem de tavsiye, sırasıyla FP ve DI'nin bulunduğu sistemin saf ve saf olmayan kısmı arasında ayrım yapılmasını sağlamaktır.

OOP bakış açısından, fonksiyonların tek yöntemli arayüzler olduğu düşünülebilir.

Arayüz bir fonksiyondan daha güçlü bir sözleşmedir.

İşlevsel bir yaklaşım kullanıyorsanız ve çok fazla DI işlemi yapıyorsanız, bir OOP yaklaşımını kullanmaya kıyasla, her bağımlılık için daha fazla aday alacaksınız.

void DoStuff(Func<DateTime> getDateTime) {}; //Anything that satisfies the signature can be injected.

vs

void DoStuff(IDateTimeProvider dateTimeProvider) {}; //Only types implementing the interface can be injected.