जावा में जब भी लागू हो "अंतिम" संशोधक का उपयोग करना [बंद]

Question

जावा में, प्रत्येक चर (स्थानीय या वर्ग), पैरामीटर फाइनल घोषित करने की प्रथा है यदि वे वास्तव में हैं।

यद्यपि यह कोड को बहुत अधिक क्रियाशील बनाता है, इससे कोड को आसानी से पढ़ने / लोभी करने में मदद मिलती है और गलतियों को भी रोकता है क्योंकि इरादा स्पष्ट रूप से चिह्नित है।

इस पर आपके क्या विचार हैं और आप क्या करते हैं?

Comments

इससे धार्मिक तर्क हो सकता है। कुछ लोग इसे पसंद करते हैं, कुछ लोग इससे नफरत करते हैं। मुझे अंतिम फ़ील्ड पसंद हैं, लेकिन अंतिम स्थानीय चर नहीं हैं जब तक कि उन्हें होने की आवश्यकता नहीं है, सुनिश्चित करें कि इसकी पूरी तरह तर्कसंगत नहीं है। सुनिश्चित नहीं है कि कोई भी डाउन वोट होगा। मैं एलेक्स मिलर से सहमत हूं। ;)

— पीटर लॉरी

मैं समझ सकता हूं कि क्या लोगों को फाइनल के साथ अपना कोड क्लैट करना पसंद नहीं है। लेकिन यह एक समस्या है जिसे एक अच्छा संपादक हल कर सकता है: bugs.eclipse.org/bugs/show_bug.cgi?id=409379

— oberlies

संबंधित stackoverflow.com/questions/154314/when-should-one-use-final

— एड्रियन बन

Answer 1

मुझे लगता है कि यह सब अच्छी कोडिंग शैली के साथ करना है। बेशक आप finalकहीं भी बहुत सारे संशोधक का उपयोग किए बिना अच्छे, मजबूत कार्यक्रम लिख सकते हैं , लेकिन जब आप इसके बारे में सोचते हैं ...

finalउन सभी चीज़ों को जोड़ना, जिन्हें बदलना नहीं चाहिए , वे उन संभावनाओं को कम करती हैं, जिन्हें आप (या अगले प्रोग्रामर, अपने कोड पर काम कर रहे हैं) विचार प्रक्रिया का गलत अर्थ निकालेंगे या दुरुपयोग करेंगे जो आपके कोड के परिणामस्वरूप हुई। कम से कम यह कुछ घंटियाँ बजनी चाहिए जब वे अब आपकी पहले की अपरिवर्तनीय चीज़ को बदलना चाहते हैं।

पहले तो, यह finalआपके कोड में बहुत सारे कीवर्ड्स को देखने में अजीब लगता है , लेकिन बहुत जल्द आप खुद ही इस शब्द को देखना बंद कर देंगे और बस यही सोचेंगे, यह कभी-कभी-कभी-कभी-इस-बिंदु से बदल जाएगा पर (आप इसे मुझसे ले सकते हैं ;-)

मुझे लगता है कि यह अच्छा अभ्यास है। मैं इसे हर समय उपयोग नहीं कर रहा हूं, लेकिन जब मैं कर सकता हूं और यह समझ में आता है कि finalमैं इसे करूंगा।

Comments

मापदंडों के लिए अंतिम कीवर्ड का उपयोग करने के बजाय आप स्थैतिक विश्लेषण टूल का उपयोग कर सकते हैं जैसे FindBugs की आवश्यकता है कि पैरामीटर चर पुन: असाइन नहीं किए जाते हैं। इस तरह आप सिंटैक्टिक बोझ को हटा देते हैं और इसे अपने कंटीन्यूअस इंटीग्रेशन टूल में फाइंडबग्स चेक के जरिए लागू कर सकते हैं।

— टिमो वेस्टकम्पर

@ टिमो यह काम करेगा, लेकिन इसका नकारात्मक पक्ष यह है कि इसे चेकइन के बाद चेक करने की आवश्यकता है, न कि जब देव कोड पर काम कर रहा हो। के लिए final, संकलक स्पष्ट रूप से आप जारी रखते हैं, तो आप एक गलती करते नहीं दूँगा।

— माइक

finalजब भी आप सहेजते हैं, तो ग्रहण में जहाँ भी संभव हो (परिवर्तन नहीं होता है) को जोड़ने का विकल्प होता है ।

— बर्ट एफ

+1 मैं प्यार करता हूँ final। यह समय के 98% से कोई फर्क नहीं पड़ता है, यह समय की 1% की मामूली असुविधा है, लेकिन समय का 1% मुझे कुछ बेवकूफ बनाने से बचाता है या अनायास ही इसके लायक है।

— बर्ट एफ

@BertF हाँ, मैंने हमेशा finalअपने कोड को "क्लीन अप ..." कोड में हर जगह जोड़ते हुए ग्रहण करने दिया । हर जगह का अर्थ है यहां तक ​​कि पकड़ने () ब्लॉक में, और जैसा कि कहा गया है, आप थोड़ी देर के बाद उन्हें नोटिस नहीं करेंगे। बेशक, अगर मैं एक भाषा बन जाएगा, finalडिफ़ॉल्ट होगा, और एक varया modifiableवैकल्पिक कीवर्ड होगा।

— मैर्टन बोडेवेस

Answer 2

ग्रस्त रहना उसपर:

• अंतिम फ़ील्ड - अंतिम फ़ील्ड के रूप में चिह्नित करना उन्हें निर्माण के अंत तक सेट करने के लिए मजबूर करता है, जिससे फ़ील्ड संदर्भ अपरिवर्तनीय हो जाता है। यह खेतों के सुरक्षित प्रकाशन की अनुमति देता है और बाद में पढ़ने पर सिंक्रनाइज़ेशन की आवश्यकता से बच सकता है। (ध्यान दें कि एक वस्तु संदर्भ के लिए, केवल फ़ील्ड संदर्भ अपरिवर्तनीय है - ऑब्जेक्ट संदर्भ को संदर्भित करने वाली चीजें अभी भी बदल सकती हैं और जो अपरिवर्तनीयता को प्रभावित करती हैं।)
• फाइनल स्टैटिक फील्ड्स - हालांकि मैं कई मामलों के लिए अब एनम का उपयोग करता हूं जहां मैं स्टैटिक फाइनल फील्ड्स का उपयोग करता था।

विचार करें लेकिन विवेकपूर्ण तरीके से उपयोग करें:

• अंतिम कक्षाएं - फ्रेमवर्क / एपीआई डिजाइन एकमात्र मामला है जहां मैं इस पर विचार करता हूं।
• अंतिम विधियाँ - मूल रूप से अंतिम कक्षाओं के समान। यदि आप टेम्प्लेट मेथड पैटर्न जैसे क्रेजी और मार्किंग स्टफ फाइनल का उपयोग कर रहे हैं, तो आप शायद विरासत पर बहुत अधिक भरोसा कर रहे हैं और प्रतिनिधिमंडल पर पर्याप्त नहीं हैं।

जब तक गुदा महसूस न करें तब तक अनदेखा करें:

• विधि पैरामीटर और स्थानीय चर - मैं मोटे तौर पर ऐसा इसलिए करता हूं क्योंकि मैं आलसी हूं और मुझे लगता है कि यह कोड को अव्यवस्थित करता है। मैं पूरी तरह से स्वीकार करूंगा कि मापदंडों और स्थानीय चर को चिह्नित करना, जिन्हें मैं संशोधित नहीं करने जा रहा हूं, वह "हल्का" है। काश यह डिफ़ॉल्ट होता। लेकिन यह नहीं है और मुझे लगता है कि कोड को फाइनल के साथ समझना अधिक कठिन है। अगर मैं किसी और के कोड में हूं, तो मैं उन्हें बाहर नहीं ले जाऊंगा, लेकिन अगर मैं नया कोड लिख रहा हूं, तो मैं उन्हें नहीं डालूंगा। एक अपवाद यह है कि आपको कुछ अंतिम निशान लगाना है, जिससे आप पहुंच सकते हैं एक अनाम आंतरिक वर्ग के भीतर से।

Comments

इस अंतिम विषय पर कई प्रश्नों के सर्वश्रेष्ठ उत्तर

— गेब्रियल bčerbák

अधिकांश समय जब मैं इसके सामने अंतिम शब्द के बिना स्थानीय चर देखता हूं और इसका उपयोग नहीं किया जा सकता है तो यह मुझे बताता है कि मुझे संभवतः एक नई विधि में कुछ कोड निकालना चाहिए जो वांछित मूल्य देता है जिसे मैं अंतिम बनाऊंगा। जिन मामलों में यह लागू नहीं होता है, वह तब होता है जब मैं कुछ धाराओं का उपयोग करता हूं या फिर जिन्हें इसे पकड़ने की आवश्यकता होती है।

— nxxz

Answer 3

उपयोग करने से पहले आपको वास्तव में अंतिम कीवर्ड के पूर्ण उपयोग को समझने की आवश्यकता है। यह चर, क्षेत्र, विधियों और कक्षाओं पर अलग-अलग प्रभाव डालता है और लागू कर सकता है

मैं अधिक जानकारी के लिए नीचे दिए गए लेख से संबंधित जाँच करने की सलाह दूंगा।

अंतिम शब्द अंतिम खोजशब्द पर

Answer 4

finalसंशोधक, विशेष रूप से चर के लिए, एक साधन संकलक एक परंपरा है कि आम तौर पर समझदार है को लागू करने के लिए है: यकीन है कि एक (स्थानीय या उदाहरण) चर ठीक एक बार (कोई और अधिक कम नहीं) असाइन किया गया है बनाते हैं। यह सुनिश्चित करने से पहले कि इसका उपयोग करने से पहले एक चर निश्चित रूप से सौंपा गया है, आप एक के सामान्य मामलों से बच सकते हैं NullPointerException:

final FileInputStream in;
if(test)
  in = new FileInputStream("foo.txt");
else
  System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned

एक चर को एक से अधिक बार असाइन किए जाने से रोककर, आप ओवरब्रॉड स्कूपिंग को हतोत्साहित करते हैं। इसके अलावा:

 String msg = null;
 for(int i = 0; i < 10; i++) {
     msg = "We are at position " + i;
     System.out.println(msg);
 }
 msg = null;

आपको इसका उपयोग करने के लिए प्रोत्साहित किया जाता है:

 for(int i = 0; i < 10; i++) {
     final String msg = "We are at position " + i;
     System.out.println(msg);
 }

कुछ लिंक:

• अंतिम कहानी (पुस्तक "हार्डकोर जावा" का मुफ्त अध्याय)
• कुछ अंतिम पैटर्न
• निश्चित कार्य

Comments

+1 ओवरब्रॉड स्कोपिंग तर्क को हतोत्साहित करने के लिए

— टॉम ट्रान्सस्की

संक्षेप में, आप मूल रूप finalसे जावा को अधिक अभिव्यक्ति आधारित बनाने के लिए उपयोग कर सकते हैं ।

— एडम जेंट

वास्तव में "यह सुनिश्चित करने से कि चर का उपयोग करने से पहले निश्चित रूप से असाइन किया गया है, आप एक NullPointerException के सामान्य मामलों से बच सकते हैं:" यह सही नहीं है, 'अंतिम' से यहां कोई फर्क नहीं पड़ता है, संकलक जानता है और 'चर' के बारे में शिकायत करता है। प्रदान किए गए उदाहरण में अशक्त होना।

— न्होलकु

@nyholku आप सही हैं, जावा में स्थानीय चर निश्चित रूप से उपयोग करने से पहले असाइन किया जाना चाहिए, वह भी बिना अंतिम। लेकिन खेतों के लिए आपको फाइनल चाहिए। थोड़े अधिक जटिल उदाहरण में, जहां "इन" एक वर्ग का एक उदाहरण चर है, और यदि / अन्यथा निर्माता में है, तो आपको समस्या को इंगित करने के लिए अंतिम की आवश्यकता है। इसके अलावा, स्थानीय चर के लिए भी अंतिम IMO में कुछ मूल्य होता है, क्योंकि यह मैला ढोने वाले को "त्रुटि" के बारे में "घोषणा" को जोड़कर संभवतः "अनसाइन किया जा रहा है" संकलन त्रुटि से रोकता है। दूसरे शब्दों में, अंतिम चर मेरे अनुभव में अशक्त के उपयोग को कम करते हैं।

— ब्रूनो डी फिगेन

Answer 5

मैं हर संभव चर घोषित करने के बारे में बहुत हठधर्मी हूं final। इसमें विधि पैरामीटर, स्थानीय चर और शायद ही कभी, मान ऑब्जेक्ट फ़ील्ड शामिल हैं। मुझे हर जगह अंतिम चर घोषित करने के तीन मुख्य कारण मिले हैं:

1. घोषणा का इरादा: एक अंतिम चर घोषित करके, मैं कह रहा हूं कि यह चर केवल एक बार लिखे जाने के लिए है। यह अन्य डेवलपर्स के लिए एक सूक्ष्म संकेत है, और संकलक के लिए एक बड़ा संकेत है।
2. एकल-उपयोग चर को लागू करना: मैं इस विचार में विश्वास करता हूं कि प्रत्येक चर का जीवन में केवल एक ही उद्देश्य होना चाहिए। प्रत्येक चर को केवल एक उद्देश्य देकर, आप डिबगिंग करते समय उस विशेष चर के उद्देश्य को कम करने में लगने वाले समय को कम कर देते हैं।
3. अनुकूलन की अनुमति देता है: मुझे पता है कि संकलक के पास प्रदर्शन बढ़ाने की चालें थीं जो विशेष रूप से एक चर संदर्भ की अपरिहार्यता पर निर्भर करती थीं। मुझे लगता है कि इन पुराने प्रदर्शन चालों (या नए वाले) में से कुछ का उपयोग संकलक द्वारा किया जाएगा।

हालांकि, मुझे लगता है कि अंतिम चर और तरीके अंतिम चर संदर्भ के रूप में लगभग उपयोगी नहीं हैं। finalकीवर्ड, जब इन घोषणाओं के साथ प्रयोग किया बस स्वचालित परीक्षण और तरीके सकता है कि आप कभी नहीं प्रत्याशित है में अपने कोड का उपयोग करने के बाधाओं प्रदान करते हैं।

Comments

finalचर और विधि मापदंडों का प्रदर्शन पर कोई प्रभाव नहीं पड़ता है क्योंकि यह बायोटेक में व्यक्त नहीं किया गया है।

— स्टीव कू

वैरिएबल: = लैटिन: वैरियस> विभिन्न> परिवर्तनीय

— आहारकर्ता

Answer 6

प्रभावी जावा में एक आइटम है जो कहता है "अनुकूल अपरिवर्तनीय वस्तुओं"। अंतिम के रूप में फ़ील्ड्स की घोषणा करने से आपको इस ओर कुछ छोटे कदम उठाने में मदद मिलती है, लेकिन वास्तव में इससे अधिक अपरिवर्तनीय वस्तुएं हैं।

यदि आप जानते हैं कि ऑब्जेक्ट अपरिवर्तनीय हैं, तो उन्हें कई थ्रेड्स / क्लाइंट्स के बीच सिंक्रनाइज़ेशन चिंताओं के बिना पढ़ने के लिए साझा किया जा सकता है, और यह इस कारण से आसान है कि प्रोग्राम कैसे चलता है।

Comments

सावधान - अंतिम और अपरिवर्तनीय पूरी तरह से अलग अवधारणाएं हैं। एक अंतिम उत्परिवर्तित वस्तु होना आसान है - अंतिम संदर्भ के बारे में है, उत्परिवर्तन वस्तु उदाहरण के बारे में है। अंतिम व्यक्ति olaf = नया व्यक्ति (); olaf.setName ( "ओलाफ");

— ओलाफ कोक

वास्तव में - अपरिवर्तनीय वस्तुएं एक चीज हैं, अपरिवर्तनीय संदर्भ (यानी अंतिम) पूरी तरह से कुछ और हैं।

— एससीएफएफ

लेकिन वे निकट से संबंधित हैं क्योंकि आप Person.name फ़ील्ड को अंतिम घोषित कर सकते हैं (और वर्ग अंतिम घोषित कर रहे हैं, और ...) व्यक्ति ऑब्जेक्ट को अंतिम बनाते हैं। हालांकि यह उतना आसान नहीं है जितना कि "फाइनल पर्सन" करना ...

— सेबस्टियन गैन्सलैंड्ट

यह स्थानीय चर (पैरामीटर स्थानीय हैं) के लिए अप्रासंगिक है। यह केवल कक्षा चर पर लागू होता है इसलिए यह केवल आंशिक रूप से प्रश्न को संबोधित करता है।

— रॉबिन

Answer 7

मैं कभी भी ऐसी स्थिति में नहीं था जहां एक चर पर अंतिम कीवर्ड होने से मुझे गलती करने से रोका गया हो, इसलिए फिलहाल मुझे लगता है कि यह समय की एक बड़ी बर्बादी है।

जब तक ऐसा करने का कोई वास्तविक कारण नहीं है (जैसा कि आप उस चर के बारे में एक विशिष्ट बिंदु को अंतिम रूप देना चाहते हैं) मैं नहीं करूंगा क्योंकि मुझे लगता है कि यह कोड को कम पठनीय बनाता है।

यदि, फिर भी, आपको यह पता नहीं है कि कोड को पढ़ना या लिखना अधिक कठिन है, तो हर तरह से इसके लिए जाएं।

संपादित करें: एक स्पष्टीकरण के रूप में (और डाउन-वोट वापस जीतने का प्रयास), मैं यह नहीं कह रहा हूं कि स्थिरांक को अंतिम रूप से चिह्नित न करें, मैं कह रहा हूं कि सामान की तरह मत करो:

public String doSomething() {
  final String first = someReallyComplicatedExpressionToGetTheString();
  final String second = anotherReallyComplicatedExpressionToGetAnother();

  return first+second;
}

यह सिर्फ कोड (मेरी राय में) को पढ़ने के लिए कठिन बनाता है।

यह भी याद रखने योग्य है कि सभी अंतिम कार्य आपको एक चर को फिर से असाइन करने से रोकते हैं, यह इसे अपरिवर्तनीय या ऐसा कुछ भी नहीं बनाता है।

Comments

बयान को उसके सिर पर मोड़ना: मैं बहुत सारी स्थितियों में रहा हूँ जहाँ (और सामान्य रूप से अपरिवर्तनीय वस्तुओं का उपयोग नहींfinal ) की संख्या और बग के प्रभाव में महत्वपूर्ण योगदान रहा है।

— क्रिस वेस्ट

मैं सभी अपरिवर्तनीय वस्तुओं के लिए हूं, मैं अभी ऐसी स्थिति में नहीं हूं जहां किसी अपरिवर्तनीय वस्तु को अंतिम रूप देने से मुझे मदद मिली हो।

— एससीएफएफ

मैं सहमत हूं कि हमें स्थानीय चर और विधि मापदंडों पर अंतिम उपयोग नहीं करना चाहिए, यह कोड को बहुत कम पठनीय बनाता है।

— rmaruszewski

— @ क्रिस

Answer 8

फाइनल का उपयोग हमेशा स्थिरांक के लिए किया जाना चाहिए। यह अल्पकालिक चर (एक विधि के भीतर) के लिए भी उपयोगी है जब चर को परिभाषित करने के नियम जटिल होते हैं।

उदाहरण के लिए:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

Answer 9

अंतिम कीवर्ड का उपयोग करने के खिलाफ सबसे बड़े तर्क में से एक लगता है कि "यह अनावश्यक है", और यह "अंतरिक्ष को बर्बाद करता है"।

यदि हम "अंतिम" के कई लाभों को स्वीकार करते हैं जैसा कि यहां कई महान पदों द्वारा इंगित किया गया है, तो यह स्वीकार करते हुए कि यह अधिक टाइपिंग और स्थान लेता है, मैं तर्क दूंगा कि जावा को डिफ़ॉल्ट रूप से चर "अंतिम" बनाना चाहिए था, और आवश्यकता है कि चीजों को चिह्नित किया जाए: उत्परिवर्तनीय "यदि कोडर चाहता है कि यह हो।

Comments

डाउनवोटर्स, देखभाल करने के लिए समझाना?

— RAY

लगता है कि यह एक चर कहलाता है, है ना?

— एलन

चुनने के लिए हजारों अंग्रेजी शब्द हैं।

— RAY

यह पूर्ण है। final"लिखने के लिए बहुत लंबा" के अलावा कोई तर्क नहीं हैं , "कोड को अनाड़ी बनाता है"। के लिए कई तर्क दिए गए हैं final। और हम इसे सेव पर ऑटो-ऐड कर सकते हैं, यदि आप इसे हाथ से टाइप नहीं करना चाहते हैं।

— दिमित्री पोपोव

Answer 10

मैं finalहर समय ऑब्जेक्ट विशेषताओं के लिए उपयोग करता हूं ।

finalकीवर्ड दृश्यता अर्थ विज्ञान जब वस्तु विशेषताओं पर इस्तेमाल किया है। असल में, कंस्ट्रक्टर रिटर्न से पहले एक अंतिम ऑब्जेक्ट विशेषता का मान सेट करना होता है। इसका मतलब है कि जब तक आप thisसंदर्भ को निर्माणकर्ता से बचने नहीं देते हैं और आप सभी विशेषताओं के finalलिए उपयोग करते हैं , आपकी वस्तु (जावा 5 शब्दार्थ के तहत) ग्वारेंटेड का ठीक से निर्माण किया जाना है, और चूंकि यह अपरिवर्तनीय है, इसलिए इसे सुरक्षित रूप से प्रकाशित किया जा सकता है अन्य धागे के लिए।

अपरिवर्तनीय वस्तुएं केवल धागा-सुरक्षा के बारे में नहीं हैं। वे आपके कार्यक्रम में राज्य के बदलावों के बारे में तर्क करना भी बहुत आसान बनाते हैं, क्योंकि जो बदल सकता है उसका स्थान जानबूझकर और यदि लगातार उपयोग किया जाता है, तो केवल उन चीजों तक सीमित होना चाहिए जो बदलनी चाहिए ।

मैं कभी-कभी तरीकों को अंतिम भी बनाता हूं, लेकिन अक्सर नहीं। मैं शायद ही कभी कक्षाओं को अंतिम बनाता हूं। मैं आम तौर पर ऐसा करता हूं क्योंकि मुझे बहुत कम जरूरत है। मैं आमतौर पर वंशानुक्रम का अधिक उपयोग नहीं करता हूं। मैं इसके बजाय इंटरफेस और ऑब्जेक्ट रचना का उपयोग करना पसंद करता हूं - यह खुद को एक डिजाइन के लिए उधार देता है जो मुझे लगता है कि अक्सर परीक्षण करना आसान होता है। जब आप कंक्रीट कक्षाओं के बजाय इंटरफेस पर कोड करते हैं, तो आपको परीक्षण करते समय इनहेरिटेंस का उपयोग करने की आवश्यकता नहीं होती है, जैसा कि यह है, जेमॉक जैसे फ्रेमवर्क के साथ, मॉक-ऑब्जेक्ट्स को बनाने में बहुत आसान है, क्योंकि यह कंक्रीट कक्षाओं के साथ है।

मुझे लगता है कि मुझे अपनी कक्षाओं के बहुमत को अंतिम रूप देना चाहिए, लेकिन मैंने अभी तक हैबिट में प्रवेश नहीं किया है।

Answer 11

मुझे अपनी नौकरी के लिए बहुत सारे कोड पढ़ने होंगे। उदाहरण के चर पर अंतिम रूप से अनुपस्थित रहना मुझे परेशान करने के लिए शीर्ष चीजों में से एक है और कोड को अनावश्यक रूप से समझना मुश्किल बनाता है। मेरे पैसे के लिए, स्थानीय चर पर अंतिम स्पष्टता से अधिक अव्यवस्था का कारण बनता है। भाषा को डिफ़ॉल्ट बनाने के लिए डिज़ाइन किया जाना चाहिए था, लेकिन हमें गलती से रहना होगा। कभी-कभी यह विशेष रूप से लूप के साथ उपयोगी होता है और अगर-और पेड़ के साथ निश्चित असाइनमेंट होता है, लेकिन ज्यादातर यह इंगित करता है कि आपकी विधि बहुत जटिल है।

Comments

एक उपकरण का उपयोग क्यों न करें जो अव्यवस्था को कम करता है?

— पचेरियर

@Pacerier एक संपादक के रूप में जो कोड को गलत तरीके से प्रस्तुत करता है?

— टॉम हॉकिन -

Answer 12

फाइनल को स्पष्ट रूप से स्थिरांक पर, और अपरिवर्तनीयता को लागू करने के लिए उपयोग किया जाना चाहिए, लेकिन तरीकों पर एक और महत्वपूर्ण उपयोग है।

प्रभावी जावा में इस पर एक संपूर्ण आइटम है (आइटम 15) जो अनपेक्षित विरासत के नुकसान को इंगित करता है। प्रभावी रूप से यदि आपने वंशानुक्रम के लिए अपनी कक्षा को डिज़ाइन और दस्तावेज़ नहीं किया है, तो इससे विरासत में प्राप्त करना अप्रत्याशित समस्याएं दे सकता है (आइटम एक अच्छा उदाहरण देता है)। इसलिए सिफारिश यह है कि आप किसी भी वर्ग और / या विधि पर अंतिम उपयोग करें जिसका उद्देश्य विरासत में नहीं मिला है।

यह ड्रैकियन लग सकता है, लेकिन यह समझ में आता है। यदि आप दूसरों द्वारा उपयोग के लिए एक क्लास लाइब्रेरी लिख रहे हैं, तो आप उन्हें उन चीजों से विरासत में नहीं लेना चाहते हैं जो इसके लिए डिज़ाइन नहीं किए गए थे - आप खुद को वापस संगतता के लिए वर्ग के एक विशेष कार्यान्वयन में बंद कर देंगे। यदि आप किसी टीम में कोडिंग कर रहे हैं तो टीम के किसी अन्य सदस्य को फाइनल को हटाने से रोकने के लिए कुछ भी नहीं है अगर उन्हें वास्तव में करना है। लेकिन खोजशब्द उन्हें इस बारे में सोचते हैं कि वे क्या कर रहे हैं, और उन्हें चेतावनी देते हैं कि जिस वर्ग से वे विरासत में प्राप्त कर रहे हैं वह इसके लिए डिज़ाइन नहीं किया गया है, इसलिए उन्हें अतिरिक्त सावधानी बरतनी चाहिए।

Answer 13

एक और चेतावनी यह है कि बहुत से लोग अंतिम रूप से भ्रमित करते हैं कि उदाहरण चर की सामग्री बदल नहीं सकती है, बजाय इसके कि संदर्भ नहीं बदल सकता है।

Comments

और यह पोस्ट उसी का एक बड़ा प्रमाण है।

— InigoD

Answer 14

स्थानीय चर के लिए भी, यह जानते हुए कि इसे अंतिम रूप दिया गया है, इसका मतलब है कि मुझे बाद में बदले जाने वाले संदर्भ के बारे में चिंता करने की आवश्यकता नहीं है। इसका मतलब है कि जब डिबगिंग और मैं उस चर को बाद में देखते हैं, तो मुझे विश्वास है कि यह उसी वस्तु का जिक्र कर रहा है। बग की तलाश करते समय मुझे एक चिंता की जरूरत है। एक बोनस यह है कि यदि 99% चर को अंतिम घोषित किया जाता है, तो कुछ चर जो वास्तव में परिवर्तनशील होते हैं, बेहतर होते हैं। इसके अलावा, अंतिम संकलक को कुछ और संभव बेवकूफ गलतियों को खोजने देता है जो अन्यथा ध्यान नहीं दे सकते हैं।

Answer 15

finalप्रत्येक विधि में प्रत्येक पैरामीटर के लिए टाइप करने का चयन कोडर्स और कोड रीडर दोनों के लिए बहुत जलन पैदा करेगा।

एक बार जलन उचित स्विच से परे स्काला में जाती है जहां तर्क डिफ़ॉल्ट रूप से अंतिम होते हैं।

या, आप हमेशा कोड स्टाइलिंग टूल का उपयोग कर सकते हैं जो आपके लिए स्वचालित रूप से करेंगे। सभी आईडीई ने उन्हें कार्यान्वित किया है या प्लगइन्स के रूप में।

Answer 16

जावा में चर के साथ उपयोग किए जाने पर अंतिम C ++ में निरंतर के लिए एक विकल्प प्रदान करता है। तो जब एक चर के लिए अंतिम और स्थिर का उपयोग किया जाता है तो यह अपरिवर्तनीय हो जाता है। उसी समय माइग्रेट किए गए C ++ प्रोग्रामर को बहुत खुश करता है ;-)

संदर्भ चर के साथ उपयोग किए जाने पर यह आपको ऑब्जेक्ट को फिर से संदर्भित करने की अनुमति नहीं देता है, हालांकि ऑब्जेक्ट को हेरफेर किया जा सकता है।

जब अंतिम विधि के साथ प्रयोग किया जाता है, तो यह उपवर्गों द्वारा विधि को ओवर-राइड करने की अनुमति नहीं देता है।

एक बार उपयोग बहुत स्पष्ट होने के बाद इसका उपयोग सावधानी से किया जाना चाहिए। यह मुख्य रूप से डिजाइन पर निर्भर करता है क्योंकि विधि पर अंतिम उपयोग करना बहुरूपता की मदद नहीं करेगा।

जब आप यह सुनिश्चित कर लें कि परिवर्तनशील मूल्य का परिवर्तन कभी नहीं किया जाना चाहिए, तो आपको इसका उपयोग केवल चर के लिए करना चाहिए। यह भी सुनिश्चित करें कि आप SUN.for द्वारा प्रोत्साहित कोडिंग कन्वेंशन का पालन करें: जैसे: अंतिम int COLOR_RED = 1; (अपर केस अंडरस्कोर द्वारा अलग किया गया)

एक संदर्भ चर के साथ, इसका उपयोग केवल तब करें जब हमें किसी विशेष वस्तु के अपरिवर्तनीय संदर्भ की आवश्यकता हो।

पठनीयता के हिस्से के बारे में, यह सुनिश्चित करें कि अंतिम संशोधनकर्ता का उपयोग करते समय टिप्पणियां बहुत महत्वपूर्ण भूमिका निभाती हैं।

Comments

क्या कोई मुझे बता सकता है कि यह मतदान क्यों है ??? बस जिज्ञासु ..

— सर्वव्यापी

यह शायद इसलिए है क्योंकि आप कहते हैं कि आपको XYZ होने पर ही इसे अंतिम रूप देना चाहिए। अन्य लोग इसे अंतिम रूप देने के लिए बेहतर अभ्यास मानते हैं जब तक कि अन्यथा ऐसा करने की आवश्यकता न हो।

— प्रोग्रामर

यह C ++ कॉन्स्टेबल कीवर्ड के विकल्प के रूप में नहीं है। -1।

— tmj

Answer 17

मैं स्थानीय चर पर उनका उपयोग कभी नहीं करता हूं, अतिरिक्त क्रिया के लिए बहुत कम बिंदु है। यहां तक ​​कि अगर आपको नहीं लगता है कि चर को फिर से असाइन किया जाना चाहिए, तो इससे अगले व्यक्ति को उस कोड को बदलने से बहुत कम फर्क पड़ेगा, जो अन्यथा सोचता है, और चूंकि कोड को बदला जा रहा है, इसलिए इसे अंतिम बनाने का कोई मूल उद्देश्य अब मान्य नहीं हो सकता है। यदि यह सिर्फ स्पष्टता के लिए है, तो मेरा मानना ​​है कि यह क्रिया के नकारात्मक प्रभावों के कारण विफल हो जाता है।

बहुत अधिक वही है जो सदस्य चर पर भी लागू होता है, क्योंकि वे स्थिरांक के मामले को छोड़कर थोड़ा लाभ प्रदान करते हैं।

अपरिवर्तनीयता पर भी इसका कोई असर नहीं पड़ता है, क्योंकि किसी चीज़ के अपरिवर्तनीय होने का सबसे अच्छा सूचक यह है कि इसे इस तरह के रूप में प्रलेखित किया जाता है और / या ऐसी कोई विधि नहीं है जो ऑब्जेक्ट को बदल सके (यह, वर्ग के फाइनल बनाने के साथ ही गारंटी देने का एकमात्र तरीका है यह अपरिवर्तनीय है)।

लेकिन हे, यह सिर्फ मेरी राय है :-)

Answer 18

मैंने सभी क्षेत्रों और विशेषताओं को अंतिम रूप देने के लिए एक्लिप्स की स्थापना की जो संशोधित नहीं हैं। यह एक्लिप्स "सेव एक्ट्स" का उपयोग करके बहुत अच्छा काम करता है जो फ़ाइल को सहेजते समय इन अंतिम संशोधक (अन्य चीजों के साथ) को जोड़ता है।

अत्यधिक सिफारिशित।

की जाँच करें मेरी ब्लॉग पोस्ट क्रिया ग्रहण को बचाने के।

Answer 19

तर्कों के लिए मुझे लगता है कि उनकी ज़रूरत नहीं है। ज्यादातर वे सिर्फ तत्परता को चोट पहुँचाते हैं। एक तर्क चर का पुनर्सृजन करना इतना पागलपनपूर्ण है कि मुझे पूरा विश्वास होना चाहिए कि उन्हें वैसे भी स्थिरांक माना जा सकता है।

तथ्य यह है कि ग्रहण का रंग अंतिम लाल होता है, इससे कोड में परिवर्तनशील घोषणाओं को स्थान देना आसान हो जाता है, जो मुझे लगता है कि अधिकांश समय रीडबिलिटी में सुधार करता है।

मैं इस नियम को लागू करने की कोशिश करता हूं कि किसी भी और सभी चर को अंतिम रूप दिया जाना चाहिए और ऐसा नहीं होने का एक चरम वैध कारण नहीं है। "यह चर क्या है?" इसका उत्तर देना इतना आसान है। सवाल अगर आपको सिर्फ इनटाइजेशन ढूंढना है और आश्वस्त रहें कि यह वही है।

मैं वास्तव में अब एक दिन के बजाय गैर-अंतिम चर के आसपास घबरा जाता हूं। यह एक चाकू के धागे में लटकने के बीच का अंतर है, जो आपके सिर पर लटका हुआ है, या सिर्फ आपके पास यह रसोई दराज है ...

एक अंतिम चर माननीयों के लिए एक अच्छा तरीका है।

एक गैर-अंतिम चर कुछ बग-प्रोन एल्गोरिथ्म के भाग के लिए बाध्य है।

एक अच्छी विशेषता यह है कि जब एल्गोरिथ्म के लिए प्रश्न से बाहर एक चर का उपयोग करने का विकल्प होता है, तो ज्यादातर समय इसकी बजाय एक विधि लिखना होता है, जो आमतौर पर कोड में काफी सुधार करता है।

Answer 20

मैं अब थोड़ी देर के लिए कोडिंग कर रहा हूं और जब भी मैं फाइनल कर सकता हूं। थोड़ी देर के लिए ऐसा करने के बाद (चर, विधि मापदंडों और वर्ग विशेषताओं के लिए), मैं कह सकता हूं कि मेरे चर के ९ ०% (या अधिक) वास्तव में अंतिम हैं। मुझे लगता है कि जब आप नहीं चाहते (तब मैंने देखा कि पहले और यह दर्द कभी-कभी होता है) संशोधित चर का लाभ आपके कोड में अतिरिक्त टाइपिंग और अतिरिक्त "अंतिम" कीवर्ड के लिए भुगतान करता है।

कहा जा रहा है, अगर मैं एक भाषा डिजाइन करूंगा, तो मैं हर चर को अंतिम बनाऊंगा जब तक कि किसी अन्य कीवर्ड द्वारा संशोधित नहीं किया जाता।

मैं कक्षाओं और विधियों के लिए अंतिम बहुत का उपयोग नहीं करता, सोचा। यह अधिक या कम जटिल डिज़ाइन विकल्प है, जब तक कि आपकी कक्षा एक उपयोगिता वर्ग नहीं है (जिस स्थिति में आपके पास केवल एक निजी निर्माता होना चाहिए)।

जब मुझे आवश्यकता होती है तो मैं संग्रहणीय सूची बनाने के लिए Collections.unmodifiable ... का उपयोग करता हूं।

Answer 21

ईवेंट श्रोताओं के लिए अनाम स्थानीय कक्षाओं का उपयोग करना और इस तरह जावा में एक सामान्य पैटर्न है। अंतिम कीवर्ड का सबसे आम उपयोग सुनिश्चित करना है कि दायरे में चर भी श्रोता के लिए सुलभ हैं।

हालाँकि, यदि आप अपने आप को अपने कोड में बहुत सारे अंतिम विवरणों को रखना चाहते हैं। यह एक अच्छा संकेत हो सकता है कि आप कुछ गलत कर रहे हैं।

ऊपर पोस्ट किया गया लेख यह उदाहरण देता है:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

Answer 22

मैं इसे लगातार अंदर और बाहर के तरीकों के लिए उपयोग करता हूं।

मैं केवल कभी-कभी इसे विधियों के लिए उपयोग करता हूं क्योंकि मुझे नहीं पता कि क्या उपवर्ग किसी दिए गए तरीके को (जो भी कारणों से) ओवरराइड नहीं करना चाहेगा।

जहां तक ​​कक्षाओं, केवल कुछ बुनियादी ढांचे की कक्षाओं के लिए है, क्या मैंने अंतिम वर्ग का उपयोग किया है।

यदि कोई फ़ंक्शन पैरामीटर किसी फ़ंक्शन के अंदर लिखा जाता है, तो IntelliJ IDEA आपको चेतावनी देता है। इसलिए, मैंने फ़ंक्शन तर्कों के लिए अंतिम का उपयोग करना बंद कर दिया है। मैं उन्हें जावा रनटाइम लाइब्रेरी के अंदर भी नहीं देखता।

Answer 23

मैं शायद ही तरीकों या कक्षाओं पर अंतिम उपयोग करता हूं क्योंकि मुझे लोगों को उन्हें ओवरराइड करने की अनुमति देना पसंद है।

अन्यथा, मैं केवल अंत में उपयोग करता हूं अगर यह ए public/private static final type SOME_CONSTANT;

Comments

हम्म..एक जगह पर..स्टील आखिरकार दूसरी लाइन पर कहती है ;-)

— सर्वव्यापी

मूल्यों को ओवरराइड करने के लिए लोगों को अनुमति देना, बगलों में आश्चर्य और कड़ी मेहनत का सबसे बड़ा स्रोत है

— RAY

Answer 24

वर्ग के फाइनल को चिह्नित करने से कुछ विधि बाइंडिंग भी हो सकती है जो रनटाइम के बजाय संकलन समय पर होती है। नीचे "v2.foo ()" पर विचार करें - कंपाइलर जानता है कि बी में एक उपवर्ग नहीं हो सकता है, इसलिए फू () को ओवरराइड नहीं किया जा सकता है, इसलिए कॉल करने के लिए कार्यान्वयन संकलन समय पर जाना जाता है। यदि वर्ग B को अंतिम रूप से चिह्नित नहीं किया जाता है, तो यह संभव है कि वास्तविक प्रकार v2 कुछ वर्ग है जो B को बढ़ाता है और foo () को ओवरराइड करता है।

class A {
    void foo() {
        //do something
    }
}
final class B extends A {
    void foo() {
    }
}
class Test {
    public void t(A v1, B v2) {
        v1.foo();
        v2.foo();
    }
}

Answer 25

स्थिरांक के लिए फाइनल का उपयोग करना दृढ़ता से प्रोत्साहित किया जाता है। हालाँकि, मैं इसे विधियों या वर्गों (या कम से कम कुछ समय के लिए इसके बारे में सोचने के लिए) का उपयोग नहीं करूँगा, क्योंकि यह असंभव नहीं है, तो परीक्षण कठिन बनाता है । यदि आप पूरी तरह से एक वर्ग या विधि को अंतिम रूप देना चाहते हैं, तो सुनिश्चित करें कि यह वर्ग कुछ इंटरफ़ेस को लागू करता है, इसलिए आप एक ही इंटरफ़ेस को लागू करने का नकली कर सकते हैं ।

Comments

यह परीक्षण को कठिन नहीं बनाता है क्योंकि आपको वैसे भी इंटरफेस का उपयोग करना चाहिए।

— क्रिस वेस्ट