Bir programcıya referans şeffaflığının faydaları nelerdir?

Programlamada, referans şeffaflığının faydaları nelerdir?

RT, işlevsel ve zorunlu paradigmalar arasındaki en büyük farklardan birini yapar ve genellikle fonksiyonel paradigmanın savunucuları tarafından zorunlu olana göre açık bir avantaj olarak kullanılır; fakat tüm çabalarında, bu savunucular bir programcı olarak bana neden fayda sağladığını asla açıklamazlar .

Elbette, bunun ne kadar "saf" ve "zarif" olduğuna ilişkin akademik açıklamaları olacak, ancak daha az "saf" bir koddan daha iyi hale nasıl getirecekler? Günlük programımda bana nasıl fayda sağlar?

Not: Bu , referans şeffaflığı nedir? İkincisi RT'nin ne olduğu konusunu ele alırken, bu soru faydalarını (bu kadar sezgisel olmayabilir) ele alır.

Bunun yararı, saf işlevlerin kodunuzun akıl yürütmesini kolaylaştırmasıdır. Veya başka bir deyişle, yan etkiler kodunuzun karmaşıklığını artırır.

Bir computeProductPriceyöntem örneği alın .

Saf bir yöntem sizden ürün miktarı, para birimi vb. İster. Yöntem aynı argümanlarla çağrıldığında her zaman aynı sonucu üreteceğini bilirsiniz .

• Hatta önbelleğe alabilir ve önbelleğe alınmış sürümü kullanabilirsiniz.
• Tembel yapabilir ve gerçekten ihtiyaç duyduğunuzda çağrısını erteleyebilirsiniz, değerin bu arada değişmeyeceğini bilerek.
• Yan etkileri olmayacağını bilerek yöntemi birden çok kez çağırabilirsiniz.
• İhtiyaç duyulan her şeyin argüman olduğunu bilerek, yöntemin kendisini dünyadan soyutlanarak akıl edebilirsiniz.

Saf olmayan bir yöntemin kullanımı ve hata ayıklaması daha karmaşık olacaktır. Değişkenler dışındaki değişkenlerin durumuna bağlı olduğu ve muhtemelen değiştirildiği için, birden çok kez çağrıldığında farklı sonuçlar üretebileceği veya hiç çağrılmadığında veya çok erken veya çok geç çağrıldığında aynı davranışa sahip olamayacağı anlamına gelir.

Misal

Çerçevede bir sayıyı ayrıştıran bir yöntem olduğunu düşünün:

decimal math.parse(string t)

Referans şeffaflığı yoktur, çünkü şunlara bağlıdır:

• Numaralandırma sistemini belirten ortam değişkeni, yani Taban 10 veya başka bir şey.

• mathKitaplık içindeki, ayrıştırılacak sayıların kesinliğini belirten değişken . Yani değeri ile 1, dizeyi ayrıştırmak "12.3456"verir 12.3.

• Beklenen biçimlendirmeyi tanımlayan kültür. Örneğin fr-FR, ayrıştırma "12.345"verir 12345, çünkü ayırma karakteri olmamalıdır ,,.

Böyle bir yöntemle çalışmanın ne kadar kolay veya zor olacağını düşünün. Aynı girişle, yöntemi çağırdığınız ana bağlı olarak radikal olarak farklı sonuçlara sahip olabilirsiniz, çünkü bir şey, bir yerde ortam değişkenini değiştirdi veya kültürü değiştirdi veya farklı bir hassasiyet ayarladı. Yöntemin deterministik olmayan karakteri daha fazla hataya ve daha fazla hata ayıklamaya neden olan kabusa yol açar. Bazı paralel kod sekizlik sayıları ayrıştırdığı için çağrı yapmak math.parse("12345")ve 5349cevap almak hoş değildir.

Açıkçası kırık olan bu yöntem nasıl düzeltilir? Referans şeffaflığı getirerek. Başka bir deyişle, küresel durumdan kurtulup her şeyi yöntemin parametrelerine taşıyarak:

decimal math.parse(string t, base=10, precision=20, culture=cultures.en_us)

Şimdi yöntem saf olduğuna göre, yöntemi çağırdığın önemli değil, her zaman aynı argümanlar için aynı sonucu üreteceğini biliyorsun.

Ne olduğunu çözmek için kodunuzdaki bir noktaya sık sık bir kırılma noktası ekler ve uygulamayı hata ayıklayıcıda çalıştırır mısınız? Bunu yaparsanız, bunun nedeni büyük ölçüde tasarımlarınızda referans şeffaflığı (RT) kullanmamanızdır. Ve bu yüzden ne işe yaradığını çözmek için kodu çalıştırmak zorunda.

RT'ye bütün mesele, kodun son derece belirleyici olmasıdır, yani kodu okuyabilir ve aynı girdi seti için her seferinde ne yaptığını öğrenebilirsiniz. Bazıları tek bir işlevin ötesinde kapsamı olan değişkenleri değiştirmeye başladığınızda, kodu okuyamazsınız. Gerçekte nasıl çalıştığını anlamak için bu kodun kafanızda veya hata ayıklayıcıda yürütülmesi gerekir.

Kod ne kadar basit okunursa ve nedense, hatalar o kadar kolay korunur ve tespit edilir, böylece sizin ve işvereniniz için zaman ve para tasarrufu sağlar.

İnsanlar "mantık yürütmek daha kolay" terimini atarlar, ama bunun ne anlama geldiğini asla açıklamazlar. Aşağıdaki örneği düşünün:

result1 = foo("bar", 12)
// 100 lines of code
result2 = foo("bar", 12)

Are result1ve result2aynı ya da farklı? Referans şeffaflığı olmadan, hiçbir fikriniz yoktur. Aslında fooemin olmak için vücudunu okumalısınız ve muhtemelen herhangi bir fonksiyonun vücudunu fooçağırır, vb.

İnsanlar bu yükü fark etmezler çünkü buna alışkındırlar, ancak bir ya da iki ay boyunca tamamen işlevsel bir ortamda işe giderseniz, geri dönün, hissedeceksiniz ve bu çok büyük bir anlaşma .

İnsanların referans şeffaflığı eksikliği üzerinde çalışmak için yaptıkları birçok savunma mekanizması vardır. Küçük örneğim için, result1bellekte kalmak isteyebilirim , çünkü değişip değişmeyeceğini bilemezdim. Sonra iki durum ile kod var: önce result1depolanmış ve sonra. Referans şeffaflığı ile, yeniden hesaplama zaman alıcı olmadığı sürece kolayca yeniden hesaplayabilirim.

Şunu söyleyebilirim: referans şeffaflığı sadece fonksiyonel programlama için değil, işlevlerle çalışan herkes için de iyi çünkü en az şaşkınlık ilkesine bağlı.

Bir işleve sahipsiniz ve ne yapması gerektiği konusunda daha iyi bir neden olabilir, çünkü dikkate almanız gereken harici faktörler yoktur, belirli bir giriş için çıktı her zaman aynı olacaktır. Zorunlu dilimde bile bu paradigmayı olabildiğince takip etmeye çalışıyorum, temelde otomatik olarak bundan sonra gelen bir sonraki şey: bazen koştuğum korkunç 1000+ çizgi fonksiyonları yerine anlaşılması kolay küçük fonksiyonlar.

Bu büyük işlevler sihir yapar ve onlara dokunmaktan korkarım çünkü muhteşem yollarla kırılabilirler.

Bu yüzden saf fonksiyonlar sadece fonksiyonel programlama için değil, her program için bir şeydir.