Clojure gibi işlevsel programlama dillerine (kuşkusuz sınırlı) maruz kalmamdan, verilerin kapsüllenmesinin daha az önemli bir rolü olduğu görülmektedir. Genellikle haritalar veya kümeler gibi çeşitli yerel türler, nesneleri temsil etmek için tercih edilen para birimidir. Ayrıca, bu veriler genellikle değişmezdir.
Örneğin, işte bu konuyla ilgili bir röportajda Clojure şöhretinden Zengin Hickey'den daha ünlü alıntılardan biri :
Fogus: Bu fikri izleyerek — bazı insanlar Clojure'un türlerinde veri gizleme kapsüllemesine girmemesinden şaşırırlar. Neden veri gizlemeyi bırakmaya karar verdiniz?
Hickey: Clojure'un soyutlamalara programlamayı güçlü bir şekilde vurguladığını açıklığa kavuşturalım. Bir noktada, birisinin verilere erişmesi gerekecek. Ve eğer “özel” fikriniz varsa, karşılık gelen ayrıcalık ve güven kavramlarına ihtiyacınız vardır. Ve bu, bir ton karmaşıklık ve az değer katar, bir sistemde sağlamlık yaratır ve çoğu zaman işleri yapmamaları gereken yerlerde yaşamaya zorlar. Bu, basit bilgi sınıflara konulduğunda meydana gelen diğer kayıplara ek olarak yapılır. Verilerin değişmez olduğu ölçüde, birisinin değişebilecek bir şeye bağımlı hale gelmesinin dışında erişim sağlamada çok az zarar vardır. Tamam, insanlar bunu gerçek hayatta her zaman yaparlar ve işler değiştiğinde adapte olurlar. Ve eğer rasyonel iseler, Gelecekte adapte olabilmeleri için değiştirebilecekleri bir şeye dayanarak bir karar verdiklerini bilirler. Yani, bu bir risk yönetimi kararı, bence programcıların özgürce yapması gerektiğini düşünüyorum. Eğer insanlar soyutlamalara programlamak ve uygulama ayrıntılarıyla evlenmek konusunda dikkatli olmak gibi bir duyarlılığa sahip değillerse, asla iyi bir programcı olmayacaklardır.
OO dünyasından geliyor, bu yıllar boyunca öğrendiğim bazı ilkeleri karmaşıklaştırıyor gibi görünüyor. Bunlar arasında Bilgi Gizleme, Demeter Yasası ve Tekdüzen Erişim İlkesi sayılabilir. Bu ortak konu, kapsüllemenin, başkalarının neye dokunmaları gerektiğini ve dokunmamaları gerektiğini bilmesi için bir API tanımlamamıza olanak tanımasıdır. Temel olarak, bazı kodların bakımının, tüketicinin koduna nasıl hatalar getirebileceğinden endişe etmeden serbestçe değişiklik ve yeniden düzenleme yapmasına izin veren bir sözleşme oluşturmak (Açık / Kapalı prensibi). Ayrıca, diğer programcıların bu verilere ulaşmak veya bu verilere dayanmak için hangi araçları kullanabileceklerini bilmesi için temiz ve küratörlü bir arayüz sağlar.
Verilere doğrudan erişilmesine izin verildiğinde, söz konusu API sözleşmesi bozulur ve tüm bu kapsülleme avantajları ortadan kalkar gibi görünür. Ayrıca, kesinlikle değiştirilemez veriler, alana özgü yapıların (nesneler, yapılar, kayıtlar) etrafından geçmeyi, bir durumu temsil etme ve bu durumda gerçekleştirilebilecek eylemler kümesini daha az kullanışlı hale getirmektedir.
İşlevsel kod tabanları, bir kod tabanının boyutu muazzam bir şekilde büyüdüğünde ortaya çıkan bu sorunları, API'lerin tanımlanması gerektiği ve birçok geliştiricinin sistemin belirli bölümleriyle çalışmaya dahil olacağı şekilde nasıl ele alır? Bu tür kod tabanlarında bunun nasıl ele alındığını gösteren bu durumun örnekleri var mı?
Also, strictly immutable data seems to make passing around domain-specific structures (objects, structs, records) much less useful in the sense of representing a state and the set of actions that can be performed on that state.Pek sayılmaz. Değişen tek şey, değişikliklerin yeni bir nesneye dönüşmesidir. Kod hakkında muhakeme söz konusu olduğunda bu büyük bir kazançtır; Değişken nesnelerin etrafından geçilmesi, onları kimin değiştirebileceğini takip etmek zorunda kalmak anlamına gelir, bu da kodun boyutu ile ölçeklenen bir sorundur.