1. गुणधर्म: गेटर्स आणि सेटर
जेव्हा डझनभर प्रोग्रामर एकाच वेळी एक मोठा प्रकल्प विकसित करत असतात, तेव्हा वर्ग फील्डमध्ये संग्रहित डेटा वेगळ्या पद्धतीने हाताळल्यास समस्या उद्भवतात.
कदाचित लोक वर्ग दस्तऐवजीकरणाचा तपशीलवार अभ्यास करण्यात अयशस्वी ठरतील किंवा कदाचित ते प्रत्येक प्रकरणाचे वर्णन करत नाही. परिणामी, वारंवार परिस्थिती उद्भवते जेव्हा ऑब्जेक्टचा अंतर्गत डेटा "दूषित" होऊ शकतो, ज्यामुळे ऑब्जेक्ट अवैध होतो.
या परिस्थिती टाळण्यासाठी, Java मध्ये सर्व वर्ग फील्ड खाजगी करण्याची प्रथा आहे . केवळ वर्गाच्या पद्धती वर्गाच्या व्हेरिएबल्समध्ये बदल करू शकतात. इतर वर्गातील कोणत्याही पद्धती थेट व्हेरिएबल्समध्ये प्रवेश करू शकत नाहीत.
जर तुम्हाला इतर वर्गांना तुमच्या वर्गातील ऑब्जेक्ट्समधील डेटा मिळवता यावा किंवा बदलता यावे असे वाटत असेल, तर तुम्हाला तुमच्या वर्गात दोन पद्धती जोडणे आवश्यक आहे - एक मिळवण्याची पद्धत आणि एक सेट पद्धत. उदाहरण:
कोड | नोंद |
---|---|
|
private नाव फील्ड कन्स्ट्रक्टरद्वारे फील्डचे आरंभीकरण getName() — ही पद्धत नाव फील्डचे मूल्य परत करते setName() — ही पद्धत नाव फील्डचे मूल्य बदलते |
इतर कोणताही वर्ग नाव फील्डचे मूल्य थेट बदलू शकत नाही. जर एखाद्याला नाव फील्डचे मूल्य मिळवायचे असेल, तर त्यांना getName()
ऑब्जेक्टवर पद्धत कॉल करावी लागेल Person
. काही कोड नाव फील्डचे मूल्य बदलू इच्छित असल्यास, त्याला setName()
ऑब्जेक्टवर पद्धत कॉल करणे आवश्यक आहे Person
.
या पद्धतीला "नेम फील्डसाठी गेटरgetName()
" देखील म्हणतात आणि या पद्धतीला " नेम फील्डसाठी सेटर " देखील म्हणतात .setName()
हा एक अतिशय सामान्य दृष्टीकोन आहे. जावा कोडपैकी 80-90% मध्ये, तुम्हाला वर्गात सार्वजनिक व्हेरिएबल्स कधीही दिसणार नाहीत. त्याऐवजी, ते घोषित केले जातील private
(किंवा protected
), आणि प्रत्येक व्हेरिएबलमध्ये सार्वजनिक गेटर्स आणि सेटर असतील.
हा दृष्टीकोन कोड लांब, परंतु अधिक विश्वासार्ह बनवतो.
क्लास व्हेरिएबलमध्ये थेट प्रवेश करणे म्हणजे तुमची कार दुहेरी पिवळ्या ओळींमधून वळवण्यासारखे आहे : हे सोपे आणि जलद आहे, परंतु जर प्रत्येकाने ते केले, तर प्रत्येकासाठी गोष्टी वाईट होतात.
समजा तुम्हाला बिंदू ( x
, y
) चे वर्णन करणारा वर्ग तयार करायचा आहे. नवशिक्या प्रोग्रामर हे कसे करेल ते येथे आहे:
class Point
{
public int x;
public int y;
}
अनुभवी Java प्रोग्रामर हे कसे करेल ते येथे आहे:
कोड |
---|
|
कोड मोठा आहे का? निःसंशयपणे.
परंतु तुम्ही गेटर्स आणि सेटरमध्ये पॅरामीटर प्रमाणीकरण जोडू शकता. उदाहरणार्थ, तुम्ही याची खात्री करू शकता x
आणि y
ते नेहमी शून्यापेक्षा मोठे (किंवा शून्यापेक्षा कमी नाही). उदाहरण:
कोड | नोंद |
---|---|
|
2. ऑब्जेक्ट आजीवन
ऑपरेटर वापरून ऑब्जेक्ट्स तयार केल्या जातात हे आपल्याला आधीच माहित आहे new
, परंतु ऑब्जेक्ट्स कशा हटवल्या जातात? ते कायमचे अस्तित्वात नसतात. त्यासाठी पुरेशी स्मृती नाही.
C++ सारख्या बर्याच प्रोग्रामिंग भाषांमध्ये, delete
ऑब्जेक्ट्स हटवण्यासाठी एक विशेष ऑपरेटर आहे. पण हे Java मध्ये कसे काम करते?
जावा मध्ये, सर्वकाही थोडे वेगळे केले जाते. Java ला डिलीट ऑपरेटर नाही. याचा अर्थ जावामध्ये वस्तू हटवल्या जात नाहीत? नाही, ते नक्कीच हटवले आहेत. अन्यथा, Java ऍप्लिकेशन्सची मेमरी त्वरीत संपेल, आणि काही महिने व्यत्यय न घेता चालणाऱ्या प्रोग्राम्सबद्दल कोणतीही चर्चा होणार नाही.
Java मध्ये, ऑब्जेक्ट्स हटवणे पूर्णपणे स्वयंचलित आहे. जावा मशीन स्वतः वस्तू हटविण्याचे काम हाताळते. या प्रक्रियेला कचरा संकलन म्हणतात, आणि कचरा गोळा करणाऱ्या यंत्रणेला कचरा संकलक ( GC ) म्हणतात .
मग एखादी वस्तू कधी हटवायची हे Java मशीनला कसे कळते?
कचरा संग्राहक सर्व वस्तूंना "पोहोचण्यायोग्य" आणि "अगम्य" मध्ये विभाजित करतो. एखाद्या वस्तूचा किमान एक संदर्भ असल्यास, तो पोहोचण्यायोग्य मानला जातो. ऑब्जेक्टचा संदर्भ देणारे कोणतेही व्हेरिएबल नसल्यास, ऑब्जेक्ट अगम्य मानला जातो आणि कचरा घोषित केला जातो, याचा अर्थ असा होतो की तो हटविला जाऊ शकतो.
Java मध्ये, तुम्ही अस्तित्वात असलेल्या ऑब्जेक्टचा संदर्भ तयार करू शकत नाही — तुम्ही फक्त तुमच्याकडे आधीपासून असलेले संदर्भ नियुक्त करू शकता. जर आपण एखाद्या वस्तूचे सर्व संदर्भ पुसून टाकले तर ती कायमची नष्ट होते.
परिपत्रक संदर्भ
जोपर्यंत आपण एका साध्या काउंटर उदाहरणावर येत नाही तोपर्यंत ते तर्क छान वाटतात: समजा आपल्याकडे दोन वस्तू आहेत ज्या एकमेकांना संदर्भ देतात (एकमेकांचे संदर्भ संग्रहित करतात). इतर कोणतीही वस्तू या वस्तूंचे संदर्भ साठवत नाहीत.
कोडमधून या ऑब्जेक्ट्समध्ये प्रवेश केला जाऊ शकत नाही, परंतु तरीही ते संदर्भित आहेत.
म्हणूनच कचरा गोळा करणारे वस्तू "संदर्भित" आणि "असंदर्भित" ऐवजी पोहोचण्यायोग्य आणि अगम्य अशी विभागतात.
पोहोचण्यायोग्य वस्तू
प्रथम, 100% जिवंत असलेल्या वस्तू पोहोचण्यायोग्य सूचीमध्ये जोडल्या जातात. उदाहरणार्थ, वर्तमान थ्रेड ( Thread.current()
) किंवा कन्सोल इनपुटस्ट्रीम ( System.in
).
नंतर पोहोचता येण्याजोग्या वस्तूंची सूची विस्तारित होऊन पोहोचण्यायोग्य वस्तूंच्या प्रारंभिक संचाद्वारे संदर्भित केलेल्या वस्तूंचा समावेश होतो. नंतर या विस्तारित संचाद्वारे संदर्भित वस्तू समाविष्ट करण्यासाठी ते पुन्हा विस्तारित केले जाते, आणि असेच.
याचा अर्थ असा की जर काही वस्तू आहेत ज्या केवळ एकमेकांना संदर्भित करतात, परंतु त्यांच्यापर्यंत पोहोचण्यायोग्य वस्तूंपासून पोहोचण्याचा कोणताही मार्ग नसेल, तर त्या वस्तू कचरा समजल्या जातील आणि हटविल्या जातील.
3. कचरा गोळा करणे
मेमरी विखंडन
ऑब्जेक्ट हटविण्याशी संबंधित आणखी एक महत्त्वाचा मुद्दा म्हणजे मेमरी फ्रॅगमेंटेशन. जर तुम्ही सतत वस्तू तयार केल्या आणि हटवल्या तर, लवकरच मेमरी मोठ्या प्रमाणात खंडित होईल: व्यापलेल्या मेमरीचे क्षेत्र अनक्युपाइड मेमरीच्या क्षेत्रांसह एकमेकांशी जोडले जातील.
परिणामी, आपण सहजपणे अशा परिस्थितीत येऊ शकतो जिथे आपण एक मोठी वस्तू (उदाहरणार्थ, दशलक्ष घटकांसह अॅरे) तयार करू शकत नाही, कारण तेथे मोठ्या प्रमाणात विनामूल्य मेमरी नसते. दुसर्या शब्दात, विनामूल्य मेमरी असू शकते, अगदी भरपूर, परंतु विनामूल्य मेमरीचा एक मोठा संलग्न ब्लॉक असू शकत नाही.
मेमरी ऑप्टिमायझेशन (डीफ्रॅगमेंटेशन)
Java मशीन ही समस्या एका विशिष्ट पद्धतीने सोडवते. हे असे काहीतरी दिसते:
मेमरी दोन भागात विभागली आहे. सर्व वस्तू केवळ अर्ध्या मेमरीमध्ये तयार केल्या जातात (आणि हटविल्या जातात). जेव्हा मेमरीमधील छिद्रे साफ करण्याची वेळ येते तेव्हा पहिल्या सहामाहीतील सर्व वस्तू दुसऱ्या सहामाहीत कॉपी केल्या जातात. परंतु ते एकमेकांच्या पुढे कॉपी केले जातात जेणेकरून छिद्र नसतील.
प्रक्रिया अंदाजे यासारखी दिसते:
पायरी 1: वस्तू तयार केल्यानंतर
पायरी 2: "छिद्र" चे स्वरूप
पायरी 3: "छिद्र" काढून टाकणे
आणि म्हणूनच तुम्हाला वस्तू हटवण्याची गरज नाही. Java मशीन सर्व पोहोचण्यायोग्य वस्तूंना नवीन स्थानावर कॉपी करते आणि मेमरीचे संपूर्ण क्षेत्र मुक्त करते जेथे वस्तू संग्रहित केल्या जात होत्या.
GO TO FULL VERSION