"हॅलो, अमिगो! मला आजचे व्याख्यान encapsulation ला समर्पित करायचे आहे . ते काय आहे याची तुम्हाला आधीच कल्पना आहे."
तर encapsulation चे फायदे काय आहेत? तेथे बरेच आहेत, परंतु मी माझ्या मते, सर्वात महत्वाचे चार आहेत:
1) वैध अंतर्गत स्थिती.
प्रोग्राम्समध्ये वारंवार अनेक वर्ग असतात जे एकाच ऑब्जेक्टशी संवाद साधतात. ऑब्जेक्टच्या अंतर्गत डेटासह एकाच वेळी संवाद साधून, ते ऑब्जेक्टच्या डेटा अखंडतेचे उल्लंघन करू शकतात, ज्यामुळे ऑब्जेक्ट योग्यरित्या कार्य करणे थांबवते.
त्यामुळे ऑब्जेक्टने त्याच्या अंतर्गत डेटामधील कोणत्याही बदलांचा मागोवा घेणे आवश्यक आहे, किंवा अजून चांगले - ते बदल करण्यासाठी ते असावे.
जर आम्हाला काही क्लास व्हेरिएबल इतर वर्गांद्वारे बदलायचे नसतील, तर आम्ही ते खाजगी घोषित करतो , याचा अर्थ फक्त त्या वर्गाच्या पद्धतीच त्यात प्रवेश करू शकतात. जर आम्हाला व्हेरिएबल्स इतर वर्गांसाठी फक्त वाचण्यासाठी हवे असतील तर आम्ही या व्हेरिएबल्समध्ये पब्लिक गेटर जोडतो.
उदाहरणार्थ, आमच्या संग्रहात किती घटक आहेत हे प्रत्येकाने जाणून घ्यावे असे आम्हाला वाटते, परंतु आमच्या परवानगीशिवाय कोणीही ते बदलू शकत नाही. या प्रकरणात, आम्ही व्हेरिएबल खाजगी इंट काउंट आणि पब्लिक getCount() पद्धत घोषित करतो .
योग्य एन्कॅप्सुलेशन हमी देते की इतर वर्ग आमच्या वर्गाच्या अंतर्गत डेटामध्ये थेट प्रवेश करू शकत नाहीत आणि परिणामी, आम्ही त्यांच्या क्रियांवर नियंत्रण ठेवण्यास सक्षम असल्याशिवाय त्यात बदल करू शकत नाही. त्यांनी वर्गावर मेथड कॉल करणे आवश्यक आहे ज्यामध्ये बदलले जाणारे व्हेरिएबल्स आहेत.
असे गृहीत धरणे उत्तम आहे की इतर प्रोग्रामर नेहमी तुमचे वर्ग त्यांच्यासाठी सर्वात सोयीस्कर पद्धतीने वापरतील, तुमच्यासाठी (किंवा तुमच्या वर्गासाठी) सर्वात सुरक्षित असतील अशा पद्धतीने नाही. हे बगचे स्त्रोत आहे आणि त्यांना प्रतिबंधित करण्याचा एक मार्ग आहे.
२) पॅरामीटर तपासणे.
कधीकधी तुम्हाला तुमच्या वर्गाच्या पद्धतींमध्ये पास केलेले पॅरामीटर्स तपासावे लागतात. उदाहरणार्थ, समजा आमच्याकडे एक "व्यक्ती" दर्शवणारा वर्ग आहे आणि तुम्ही त्याची जन्मतारीख निर्दिष्ट करू शकता. पास केलेला कोणताही डेटा प्रोग्रामच्या लॉजिक आणि क्लासच्या लॉजिकशी सुसंगत आहे हे आम्ही सत्यापित केले पाहिजे. उदाहरणार्थ, 13 वा महिना नाही, 30 फेब्रुवारी नाही इ.
"कोणीतरी 30 फेब्रुवारी ही जन्मतारीख का दर्शवेल?"
"ठीक आहे, सर्व प्रथम, हे डेटा एंट्री त्रुटीचे परिणाम असू शकते."
दुसरे, प्रोग्राम घड्याळाच्या कामाप्रमाणे काम करण्यापूर्वी, त्यात बरेच बग असू शकतात. उदाहरणार्थ, असे काहीतरी होऊ शकते.
प्रोग्रामर कोड लिहितो जो परवा कोणाचा वाढदिवस आहे हे ठरवतो. समजा आज ३ मार्च आहे. कार्यक्रम सध्याच्या तारखेला २ जोडतो आणि ५ मार्चला जन्मलेल्या प्रत्येकाला शोधतो. आतापर्यंत, खूप चांगले.
पण जेव्हा 30 मार्च येतो तेव्हा प्रोग्रामला कोणीही सापडत नाही, कारण 32 मार्च नसतो. जेव्हा पद्धती पॅरामीटर तपासतात तेव्हा प्रोग्राम खूपच कमी असतात."
"मला आठवतं जेव्हा आम्ही ArrayList चा अभ्यास केला तेव्हा मी त्याचा कोड पाहिला आणि इंडेक्स पॅरामीटर शून्यापेक्षा जास्त किंवा समान आणि अॅरेच्या लांबीपेक्षा कमी आहे याची खात्री करण्यासाठी गेट आणि सेट पद्धती तपासल्या होत्या. कोड अॅरेमध्ये निर्देशांकाशी संबंधित घटक नसल्यास अपवाद.
"होय, ते क्लासिक इनपुट चेकिंग आहे. "
३) वर्गांमध्ये कोड बदलताना कमी बग.
समजा आम्ही एका मोठ्या प्रकल्पाचा भाग म्हणून खरोखर उपयुक्त वर्ग लिहिला. प्रत्येकाला ते इतके आवडले की इतर प्रोग्रामरनी ते त्यांच्या स्वतःच्या कोडमध्ये शेकडो ठिकाणी वापरण्यास सुरुवात केली.
वर्ग इतका उपयुक्त ठरला की तुम्ही त्यात सुधारणा करण्याचा निर्णय घेतला. परंतु आपण वर्गातील कोणत्याही पद्धतीपासून मुक्त झाल्यास, इतर डझनभर प्रोग्रामरचे कोड यापुढे संकलित होणार नाहीत. त्यांना त्यांचा कोड पटकन पुन्हा लिहावा लागेल. आणि जितके अधिक पुनर्लेखन घडते, तितक्या अधिक संधी बग्ससाठी असतील. तुम्ही नियमितपणे बिल्ड तोडल्यास, तुमचा तिरस्कार केला जाईल.
परंतु आम्ही खाजगी म्हणून चिन्हांकित केलेल्या पद्धती बदलल्यास, आम्हाला माहित आहे की या पद्धती कोठेही इतर कोणाच्या कोडद्वारे कॉल केल्या जात नाहीत. आम्ही ते पुन्हा लिहू शकतो, आणि पॅरामीटर्सची संख्या आणि प्रकार बदलू शकतो आणि अवलंबून कोड अजूनही कार्य करेल. किंवा किमान ते अजूनही संकलित करेल.
4) इतर ऑब्जेक्ट्स आपल्या ऑब्जेक्टशी कसे संवाद साधतील हे आम्ही परिभाषित करतो.
आमच्या ऑब्जेक्टवर काय कृती करता येतील यावर आम्ही निर्बंध घालू शकतो. उदाहरणार्थ, आम्ही क्लासचा फक्त एकच प्रसंग तयार करू इच्छितो—जरी तो प्रोजेक्टमध्ये एकाच वेळी अनेक ठिकाणी तयार केला गेला असेल. आणि आपण हे encapsulation वापरून साध्य करू शकतो.
Encapsulation आम्हाला अतिरिक्त निर्बंध लागू करू देते जे अतिरिक्त फायद्यांमध्ये बदलू शकतात . उदाहरणार्थ, स्ट्रिंग क्लास एक अपरिवर्तनीय ऑब्जेक्ट म्हणून लागू केला जातो. स्ट्रिंग वर्गाची उदाहरणे त्याची निर्मिती आणि त्याचा नाश यांच्यामध्ये बदलता येत नाहीत. स्ट्रिंग क्लासच्या सर्व पद्धती (काढून टाका, सबस्ट्रिंग, ...) नवीन स्ट्रिंग परत करत नाहीत आणि ज्या ऑब्जेक्टवर कॉल केला जातो तो बदलत नाही.
"पवित्र गाय. तर ती अशीच आहे."
"एनकॅप्सुलेशन मनोरंजक आहे."
"मी सहमत आहे."
GO TO FULL VERSION