Dari paparan saya (memang terbatas) untuk bahasa pemrograman fungsional, seperti Clojure, tampaknya enkapsulasi data memiliki peran yang kurang penting. Biasanya berbagai jenis asli seperti peta atau set adalah mata uang yang dipilih untuk mewakili data, lebih dari objek. Selanjutnya, data itu umumnya tidak dapat diubah.
Misalnya, inilah salah satu kutipan terkenal dari Rich Hickey of Clojure fame, dalam sebuah wawancara tentang masalah ini :
Fogus: Mengikuti gagasan itu — beberapa orang dikejutkan oleh fakta bahwa Clojure tidak terlibat dalam enkapsulasi penyembunyian data pada tipenya. Mengapa Anda memutuskan untuk tidak lagi menyembunyikan data?
Hickey: Mari kita perjelas bahwa Clojure sangat menekankan pemrograman pada abstraksi. Pada titik tertentu, seseorang akan perlu memiliki akses ke data. Dan jika Anda memiliki gagasan "pribadi", Anda perlu gagasan tentang hak istimewa dan kepercayaan yang sesuai. Dan itu menambah satu ton kompleksitas dan sedikit nilai, menciptakan kekakuan dalam suatu sistem, dan seringkali memaksa hal-hal untuk hidup di tempat yang tidak seharusnya. Ini merupakan tambahan dari kehilangan lainnya yang terjadi ketika informasi sederhana dimasukkan ke dalam kelas. Sejauh data tidak dapat diubah, ada sedikit bahaya yang dapat terjadi karena menyediakan akses, selain dari itu seseorang dapat bergantung pada sesuatu yang mungkin berubah. Baiklah, orang-orang melakukan itu sepanjang waktu di kehidupan nyata, dan ketika segalanya berubah, mereka beradaptasi. Dan jika mereka rasional, mereka tahu kapan mereka membuat keputusan berdasarkan sesuatu yang dapat berubah yang mungkin mereka perlu adaptasi di masa depan. Jadi, ini adalah keputusan manajemen risiko, yang menurut saya programmer harus bebas untuk membuat. Jika orang tidak memiliki kepekaan terhadap keinginan untuk memprogram abstraksi dan untuk berhati-hati dalam mengawinkan detail implementasi, maka mereka tidak akan pernah menjadi programmer yang baik.
Datang dari dunia OO, ini tampaknya menyulitkan beberapa prinsip yang diabadikan yang telah saya pelajari selama bertahun-tahun. Ini termasuk Menyembunyikan Informasi, Hukum Demeter dan Prinsip Akses Seragam, untuk beberapa nama. Utas umum adalah enkapsulasi memungkinkan kita untuk mendefinisikan API agar orang lain tahu apa yang harus dan tidak boleh mereka sentuh. Intinya, membuat kontrak yang memungkinkan pengelola beberapa kode untuk secara bebas melakukan perubahan dan perbaikan tanpa khawatir tentang bagaimana bug dapat dimasukkan ke dalam kode konsumen (prinsip Terbuka / Tertutup). Ini juga menyediakan antarmuka yang bersih, dikuratori untuk programmer lain untuk mengetahui alat apa yang dapat mereka gunakan untuk mendapatkan atau membangun data itu.
Ketika data diizinkan untuk diakses secara langsung, kontrak API itu rusak dan semua manfaat enkapsulasi itu tampaknya hilang. Selain itu, data yang benar-benar tidak dapat diubah tampaknya membuat keliling struktur spesifik domain (objek, struct, catatan) jauh kurang berguna dalam arti mewakili suatu keadaan dan serangkaian tindakan yang dapat dilakukan pada keadaan itu.
Bagaimana basis kode fungsional mengatasi masalah ini yang tampaknya muncul ketika ukuran basis kode tumbuh sangat besar sehingga API perlu didefinisikan dan banyak pengembang yang terlibat dalam bekerja dengan bagian-bagian tertentu dari sistem? Apakah ada contoh situasi ini yang tersedia yang menunjukkan bagaimana ini ditangani dalam jenis basis kode ini?
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.Tidak juga. Satu-satunya hal yang berubah adalah bahwa perubahan tersebut berakhir pada objek baru. Ini adalah kemenangan besar dalam hal pertimbangan tentang kode; melewati benda-benda yang bisa berubah-ubah berarti harus melacak siapa yang mungkin memutasi mereka, suatu masalah yang meningkat dengan ukuran kode.