कार्यात्मक प्रोग्रामिंग भाषाओं, जैसे क्लोजर के लिए मेरे (संयुक्त रूप से सीमित) जोखिम से, ऐसा लगता है कि डेटा के इनकैप्सुलेशन की कम महत्वपूर्ण भूमिका है। आमतौर पर विभिन्न देशी प्रकार जैसे कि नक्शे या सेट वस्तुओं पर डेटा का प्रतिनिधित्व करने की पसंदीदा मुद्रा है। इसके अलावा, वह डेटा आमतौर पर अपरिवर्तनीय है।
उदाहरण के लिए, इस मामले के बारे में एक साक्षात्कार में क्लोजुरे के रिच हिकी से अधिक प्रसिद्ध उद्धरणों में से एक है :
फोगस: उस विचार के बाद — कुछ लोग इस तथ्य से आश्चर्यचकित हैं कि क्लोजर अपने प्रकारों के डेटा-छिपने के इनकैप्सुलेशन में संलग्न नहीं है। आपने डेटा छिपाने का फैसला क्यों किया?
हिक्की: आइए स्पष्ट रहें कि क्लॉजुर प्रोग्रामिंग से लेकर अमूर्तता पर जोर देता है। हालांकि कुछ बिंदु पर, किसी को डेटा तक पहुंच की आवश्यकता होती है। और अगर आपके पास "निजी" की धारणा है, तो आपको विशेषाधिकार और विश्वास की संगत धारणाओं की आवश्यकता है। और यह पूरी तरह से जटिलता और थोड़े मूल्य का एक टन जोड़ता है, एक प्रणाली में कठोरता पैदा करता है, और अक्सर चीजों को उन जगहों पर रहने के लिए मजबूर करता है जो उन्हें नहीं करना चाहिए। यह अन्य खोने के अतिरिक्त है जो तब होता है जब साधारण जानकारी को कक्षाओं में रखा जाता है। डेटा अपरिवर्तनीय है, इस बात की थोड़ी बहुत हानि है कि पहुँच प्रदान करने की बात आ सकती है, इसके अलावा कोई व्यक्ति किसी ऐसी चीज़ पर निर्भर हो सकता है जो बदल सकती है। ठीक है, ठीक है, लोग वास्तविक जीवन में हर समय करते हैं, और जब चीजें बदलती हैं, तो वे अनुकूलन करते हैं। और अगर वे तर्कसंगत हैं, वे जानते हैं कि जब वे किसी ऐसी चीज के आधार पर कोई निर्णय लेते हैं जो बदल सकती है जो उन्हें भविष्य में अनुकूल बनाने की आवश्यकता हो सकती है। इसलिए, यह एक जोखिम प्रबंधन निर्णय है, जो मुझे लगता है कि प्रोग्रामर बनाने के लिए स्वतंत्र होना चाहिए। अगर लोगों को अमूर्तता के कार्यक्रम की इच्छा नहीं है और कार्यान्वयन विवरणों से शादी करने से सावधान रहना है, तो वे कभी भी अच्छे प्रोग्रामर नहीं होंगे।
OO दुनिया से आ रहा है, यह मुझे वर्षों से सीखे गए कुछ निहित सिद्धांतों को जटिल लगता है। इनमें कुछ को नाम देने के लिए सूचना छिपाने, कानून का कानून और यूनिफॉर्म एक्सेस सिद्धांत शामिल हैं। सामान्य थ्रेड जो कि एनकैप्सुलेशन है, हमें दूसरों के लिए एक एपीआई परिभाषित करने की अनुमति देता है ताकि वे जान सकें कि उन्हें क्या करना चाहिए और क्या नहीं छूना चाहिए। संक्षेप में, एक अनुबंध बनाना जो कुछ कोड के अनुरक्षक के लिए स्वतंत्र रूप से बदलाव और रिफ्लेक्टरिंग के बारे में चिंता किए बिना अनुमति देता है कि यह उपभोक्ता के कोड (ओपन / क्लोज्ड सिद्धांत) में बग को कैसे लागू कर सकता है। यह अन्य प्रोग्रामर को यह जानने के लिए एक स्वच्छ, घुमावदार इंटरफ़ेस प्रदान करता है कि वे उस डेटा को प्राप्त करने या बनाने के लिए किन उपकरणों का उपयोग कर सकते हैं।
जब डेटा को सीधे एक्सेस करने की अनुमति दी जाती है, तो वह एपीआई कॉन्ट्रैक्ट टूट जाता है और उन सभी एनकैप्सुलेशन लाभों को दूर जाने लगता है। इसके अलावा, सख्ती से अपरिवर्तनीय डेटा डोमेन-विशिष्ट संरचनाओं (ऑब्जेक्ट्स, स्ट्रक्चर, रिकॉर्ड) के आसपास से गुजरता हुआ प्रतीत होता है जो किसी राज्य का प्रतिनिधित्व करने और उस राज्य पर किए जाने वाले कार्यों के सेट के अर्थ में बहुत कम उपयोगी होता है।
कार्यात्मक कोडबेस इन मुद्दों को कैसे संबोधित करते हैं जो तब आते हैं जब कोडबेस का आकार इतना बड़ा हो जाता है कि एपीआई को परिभाषित करने की आवश्यकता होती है और सिस्टम के विशिष्ट भागों के साथ काम करने पर बहुत सारे डेवलपर्स शामिल होते हैं? क्या इस स्थिति के उदाहरण उपलब्ध हैं जो प्रदर्शित करते हैं कि इस प्रकार के कोडबेस में इसे कैसे नियंत्रित किया जाता है?
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.ज़रुरी नहीं। केवल एक चीज जो बदलती है वह यह है कि परिवर्तन एक नई वस्तु पर समाप्त होते हैं। यह एक बड़ी जीत है जब यह कोड के बारे में तर्क करने की बात आती है; चारों ओर उत्परिवर्तनीय वस्तुओं को पारित करने का अर्थ है कि जो उन्हें बदल सकता है, एक समस्या है जो कोड के आकार के साथ स्केल करता है।