स्थिरांक
"अमिगो, तुम्हाला माहित आहे का की Java मध्ये सर्व व्हेरिएबल्स बदलता येत नाहीत?"
"ते कसे आहे, किम? खरंच, 'व्हेरिएबल' हा शब्द बदलाबद्दल बोलतो."
"यात काही शंका नाही. इतर अनेक प्रोग्रामिंग भाषांप्रमाणे, जावामध्ये स्थिरांक आहेत , म्हणजेच व्हेरिएबल्स ज्यांची मूल्ये बदलता येत नाहीत . आणि 'स्थिर' हा शब्द स्थिरतेबद्दल बोलतो."
"आणि ते कशासाठी आहेत?"
"सामान्यतः, ते काही मूलभूत गोष्टींसाठी वापरले जातात जसे की Pi
वर्षाच्या महिन्यांतील संख्या किंवा दिवसांची संख्या. असे म्हटले आहे की, तत्वतः, प्रोग्रामर कोणत्याही व्हेरिएबलला स्थिर बनवू शकतो, जर त्याने किंवा तिने असे ठरवले तर म्हणून आवश्यक आहे."
"तुम्हाला नाव, कारचा रंग किंवा आठवड्यातील एखाद्या दिवसाचे नाव असे म्हणायचे आहे?"
"तुम्हाला योग्य कल्पना आली आहे. काहीही बदलू नये."
"आणि हे स्थिरांक Java मध्ये कसे दिसतात?"
"Java मध्ये त्यांच्यासाठी एक विशेष कीवर्ड आहे: final
. एक अपरिवर्तनीय व्हेरिएबल तयार करणे हे सामान्य तयार करण्यासारखेच दिसते. फरक एवढाच आहे की व्हेरिएबलच्या प्रकारापूर्वी तुम्हाला शब्द लिहावा लागेल final
, जसे की:
final Type name = value;
"तुम्ही स्थिरांक तयार केल्यास आणि नंतर त्याला वेगळे मूल्य नियुक्त करण्याचा प्रयत्न केल्यास काय होईल?"
"हा विचारण्यासाठी योग्य प्रश्न आहे! आणि योग्य उत्तर हे आहे: जर तुम्ही व्हेरिएबलला वेगळे मूल्य नियुक्त करण्याचा प्रयत्न केला final
, तर तुमचा प्रोग्राम संकलित होणार नाही."
"तुम्ही final
व्हेरिएबल घोषित केले पण त्याला मूल्य दिले नाही तर?"
"असे करण्यात काही अर्थ नाही, त्यामुळे जावामध्येही याला परवानगी नाही. final
व्हेरिएबल घोषित केल्यावर प्रारंभ करणे आवश्यक आहे, म्हणजे, आपण त्यास एक मूल्य नियुक्त करणे आवश्यक आहे. या नियमाला एक अपवाद आहे: आपण प्रारंभ करू शकता कंस्ट्रक्टरमध्ये स्थिर क्लास व्हेरिएबल. पण त्याबद्दल तुम्हाला नंतर कळेल.
"म्हणजे, सर्वकाही final
स्थिर आहे असे नाही. कीवर्डची संख्या कमी करण्यासाठी, जावा डेव्हलपर हा शब्द final
फक्त स्थिरांक घोषित करण्यापेक्षा अधिक वापरतात. final
पद्धती आणि अगदी वर्गांना देखील लागू होऊ शकतात. म्हणून घोषित केलेल्या पद्धती final
अधिलिखित करता येत नाहीत आणि एक वर्ग. final
वारसा म्हणून घोषित केले जाऊ शकत नाही."
"अरे... ओव्हरराइड? वारसा मिळालेला? आता तुम्ही कोणती भाषा बोलत आहात?"
"ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंगची भाषा. तुम्हाला ती लवकरच मिळेल. तोपर्यंत, फक्त सुंदर शब्दावलीचा आनंद घ्या."
"ठीक आहे. तर, final
व्हेरिएबल्स, क्लासेस आणि पद्धतींपुढे ठेवता येईल आणि हा कीवर्ड त्यांना काही अर्थाने अपरिवर्तनीय बनवतो?"
"होय. शिवाय, final
कोणत्याही व्हेरिएबल्सच्या आधी मॉडिफायर जोडला जाऊ शकतो: लोकल व्हेरिएबल्स, मेथड पॅरामीटर्स, क्लास फील्ड आणि स्टॅटिक क्लास व्हेरिएबल्स.
"येथे लक्षात ठेवण्याची महत्त्वाची गोष्ट आहे: final
व्हेरिएबलच्या नावापूर्वी फक्त त्या व्हेरिएबलमधील कोणत्याही बदलांपासून संरक्षण आहे . जर व्हेरिएबल ऑब्जेक्टचा संदर्भ संग्रहित करत असेल, तर ऑब्जेक्ट अजूनही बदलता येऊ शकतो."
"मला नीट समजत नाही."
"तुम्हाला खरोखर लवकरच समजेल. येथे एक उदाहरण आहे:
|
आम्ही एक अॅरे तयार करतो. याची परवानगी नाही: व्हेरिएबल data म्हणून घोषित केले आहे final . पण तुम्ही हे करू शकता. आणि हे देखील. |
"समजले. अवघड आहे."
जागतिक स्थिरांक
"जागतिक स्थिरांक काय आहेत असे तुम्हाला वाटते?"
"माझा अंदाज आहे की जागतिक स्थिरांक कदाचित जागतिक चलांसारखे आहेत, फक्त स्थिरांक?"
"अगदी. तुम्हाला तुमच्या प्रोग्राममध्ये जागतिक स्थिरांक घोषित करायचे असल्यास, स्टॅटिक क्लास व्हेरिएबल्स तयार करा , आणि ते बनवा public
आणि final
. अशा व्हेरिएबल्सच्या नावांसाठी एक विशेष शैली आहे: ते सर्व कॅपिटल अक्षरांमध्ये लिहिलेले आहेत, ज्यामध्ये अंडरस्कोर वर्ण वापरला जातो. वेगळे शब्द.
उदाहरणे:
class Solution
{
public static final String SOURCE_ROOT = "c:\\projects\\my\\";
public static final int DISPLAY_WIDTH = 1024;
public static final int DISPLAY_HEIGHT = 768;
}
व्हेरिएबल शेडिंग
"मी आधी म्हटल्याप्रमाणे, तुम्ही एकाच पद्धतीत एकाच नावाने अनेक स्थानिक चल तयार करू शकत नाही. वेगवेगळ्या पद्धतींमध्ये, तुम्ही करू शकता."
"मला ते माहित आहे!"
"परंतु तुम्हाला कदाचित माहित नसेल की वर्गातील व्हेरिएबल्स आणि मेथडमधील स्थानिक व्हेरिएबल्सचे नाव समान असू शकते.
उदाहरण:
कोड | परिवर्तनीय दृश्यमानता |
---|---|
|
|
"पद्धतीमध्ये add
, आम्ही नावाचे स्थानिक व्हेरिएबल घोषित केले आहे sum
. पद्धत संपेपर्यंत, ते इन्स्टन्स व्हेरिएबलला सावली (किंवा मुखवटा ) करते sum
."
"हम्म... मी म्हणेन की हे अपेक्षित वर्तन आहे."
"परंतु हा कथेचा शेवट नाही. असे दिसून आले की जर एखाद्या इंस्टन्स व्हेरिएबलला स्थानिक व्हेरिएबलने सावली दिली असेल, तर पद्धतमध्ये इन्स्टन्स व्हेरिएबलचा संदर्भ देण्याचा एक मार्ग आहे. आम्ही हे त्याच्या नावापूर्वी कीवर्ड लिहून करतो this
. :
this.name
"येथे एक उदाहरण आहे जेथे नावाचा संघर्ष यशस्वीरित्या सोडवला गेला आहे:
कोड | परिवर्तनीय दृश्यमानता |
---|---|
|
|
आणि count
व्हेरिएबल्स sum
कीवर्डसह किंवा त्याशिवाय सर्वत्र उपलब्ध आहेत this
. ज्या ओळींवर sum
लोकल व्हेरिएबल इन्स्टन्स व्हेरिएबलला सावली देते sum
, sum
इन्स्टन्स व्हेरिएबल फक्त कीवर्ड वापरून ऍक्सेस केले जाऊ शकते this
.
"अर्थात, मला याचा सराव करावा लागेल."
"तुम्ही व्यवस्थापित कराल."
"फक्त (नॉन-स्टॅटिक) इन्स्टन्स व्हेरिएबलऐवजी स्टॅटिक क्लास व्हेरिएबल सावलीत असेल तर? तुम्ही त्याद्वारे प्रवेश करू शकत नाही this
?"
"तुमचे म्हणणे बरोबर आहे. हा कीवर्ड कार्य करणार नाही. तुम्हाला वर्गाच्या नावाद्वारे त्याचा संदर्भ घ्यावा लागेल:
ClassName.name
उदाहरण:
कोड | परिवर्तनीय दृश्यमानता |
---|---|
|
|
"लक्ष द्या: तुम्ही क्लासचे नाव उपसर्ग म्हणून किंवा न वापरता सर्वत्र count
आणि स्टॅटिक व्हेरिएबल्समध्ये प्रवेश करू शकता . ज्या ओळींमध्ये स्थानिक व्हेरिएबल इन्स्टन्स व्हेरिएबलला सावली देते, तेथे क्लास व्हेरिएबलमध्ये प्रवेश केवळ उपसर्ग म्हणून वापरताना शक्य आहे .sum
Solution
sum
sum
sum
Solution
for
लूपमधील चल
for
"आणि आणखी एक लहान पण मनोरंजक तथ्य. अशी एक जागा देखील आहे जिथे व्हेरिएबल एका विशिष्ट प्रकारे घोषित केले जाते — मी लूपच्या आत बोलत आहे ." सामान्यतः, for
लूपमध्ये कंसात व्हेरिएबल असते counter
. आणि या व्हेरिएबलची दृश्यमानता काय असेल? शेवटी, ते लूपच्या शरीरात नाही. ही संपूर्ण पद्धत आहे का? किंवा नाही?"
for
"मी याबद्दल आधीच काहीतरी ऐकले आहे. जसे मला ते समजले आहे, लूपच्या शीर्षलेखामध्ये घोषित केलेले व्हेरिएबल केवळ लूपच्या मुख्य भागामध्ये आणि लूपच्या शीर्षलेखामध्येfor
दृश्यमान आहे ."
"शाबास, अमिगो. पण तरीही, ही सामग्री मजबूत करण्यासाठी एक उदाहरण पहा:
कोड | परिवर्तनीय दृश्यमानता |
---|---|
|
|
"म्हणून तुम्ही म्हणत आहात की माझ्या कोडमध्ये मी एकाच नावाच्या काउंटर व्हेरिएबलसह एकामागून एक अनेक लूप लिहू शकतो, आणि कोणतीही अडचण येणार नाही?"
"कोणतीही अडचण येणार नाही. येथे पहा:
कोड | परिवर्तनीय दृश्यमानता |
---|---|
|
|
GO TO FULL VERSION