🎯 🕶️ 🥀 जावा में अनुबंध प्रोग्रामिंग 💪🏼 👼 💃🏻

शुभ दोपहर

जावा कोर डिस्टेंस एजुकेशन कोर्स के विस्तृत अध्ययन के हिस्से के रूप में , मैं प्रकाशनों की एक श्रृंखला लिख रहा हूं और कुछ सबसे लोकप्रिय लेखों का अनुवाद कर रहा हूं।

मैं ऑनलाइन शिक्षा प्लेटफॉर्म udemy.com (कौरसेरा / एडएक्स के समान) पर जावा डेवलपर्स कोर्स के लिए स्काला भी सिखाता हूं।

अब मैं आपको कुछ टिप्पणियों के साथ "प्रोग्रामिंग विद असेसरीज" के अपने अनुवाद पर विचार करने के लिए आमंत्रित करता हूं।

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

अन्य जावा कोर लेख और अनुवाद

पाठ्यक्रम कार्यक्रम "जावा कोर"

रूसी में जावा वीडियो के 1000+ घंटे

जावा एनोटेशंस, भाग I

मल्टीकोर जावा प्रोग्रामिंग कोर्स के लिए अन्य लेख और अनुवाद

पाठ्यक्रम का कार्यक्रम "जावा में मल्टीकोर प्रोग्रामिंग"

जावा / GPars आधारित अभिनेताओं का परिचय, भाग I

JSR 133 (जावा मेमोरी मॉडल) FAQ (अनुवाद)

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

अभिकथन प्रोग्रामिंग (oracle.com: प्रोग्रामिंग विद असेसरीज)

एक मुखर जावा प्रोग्रामिंग भाषा में एक बयान है जो आपको कार्यक्रम के बारे में अपनी मान्यताओं का परीक्षण करने की अनुमति देता है। उदाहरण के लिए, यदि आप एक विधि लिखते हैं जो एक कण की गति की गणना करता है, तो आप "दावा" कर सकते हैं कि गणना की गई गति प्रकाश की गति से कम है।

प्रत्येक कथन में एक तार्किक अभिव्यक्ति होती है, जो आपकी राय में, निष्पादन के समय सही होगी। अन्यथा, सिस्टम एक अपवाद फेंक देगा। यह जांचने से कि तार्किक अभिव्यक्ति वास्तव में सत्य है, एक मुखर आपके कार्यक्रम के व्यवहार के बारे में आपकी धारणाओं की पुष्टि करता है, जिससे आपका विश्वास बढ़ जाता है कि कार्यक्रम त्रुटि मुक्त है।

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

यह लेख बताता है कि कैसे बयानों के साथ प्रोग्राम करना है। इसमें निम्नलिखित विषय शामिल हैं:

परिचय

कोड में एंबेडिंग स्टेटमेंट्स

दावों का उपयोग करते हुए फ़ाइलें संकलित करना

दावों को सक्षम और अक्षम करना

मौजूदा कार्यक्रमों के साथ संगतता

डिजाइन पूछे जाने वाले प्रश्न

परिचय

मुखर कथन के दो रूप हैं। पहला, सरल रूप है:

assert Expression1;

जहां अभिव्यक्ति ₁ एक बूलियन अभिव्यक्ति है। जब सिस्टम स्टेटमेंट की जांच करता है, तो यह एक्सप्रेशन _{1 का} मूल्यांकन करता है और यदि यह गलत ( गलत ) है, तो सिस्टम एक विस्तृत त्रुटि संदेश के बिना java.lang.AssertionError फेंकता है।

अनुमोदन का दूसरा रूप है:

 assert Expression1 : Expression2;

जहां:

अभिव्यक्ति ₁ एक तार्किक अभिव्यक्ति है।
अभिव्यक्ति ₂ एक अभिव्यक्ति है जो मायने रखती है ( शून्य विधि के लिए कॉल नहीं हो सकती)।

एक विस्तृत त्रुटि संदेश प्रदान करने के लिए मुखर कथन के इस संस्करण का उपयोग करें। सिस्टम एक विस्तृत त्रुटि संदेश के रूप में मान के स्ट्रिंग प्रतिनिधित्व का उपयोग करने के लिए उपयुक्त AssertionError कंस्ट्रक्टर को अभिव्यक्ति ₂ मान पास करता है।

अनुवादक टिप्पणी

अभिकथन में प्रत्येक डेटा प्रकार के लिए अलग-अलग कंस्ट्रक्टर होते हैं (लघु और बाइट स्वचालित रूप से इंट में डाली जाती है, कोई भी कंस्ट्रक्टर इसके लिए प्रदान नहीं किए गए थे)

 package java.lang; public class AssertionError extends Error { ... public AssertionError(Object detailMessage) {...} public AssertionError(boolean detailMessage) {...} public AssertionError(char detailMessage) {...} public AssertionError(int detailMessage) {...} public AssertionError(long detailMessage) {...} public AssertionError(float detailMessage) {...} public AssertionError(double detailMessage) {...} ... }

यह आपको अभिव्यक्ति _{2 के} रूप में किसी भी आदिम या संदर्भ प्रकार की अभिव्यक्ति का उपयोग करने की अनुमति देता है :

 public class App { public static void main(String[] args) { assert args != null : 1; assert args != null : 1.0; assert args != null : false; assert args != null : "Hello!"; assert args != null : new int[] {10, 20, 30}; }

या मनमाने तरीके से कॉल करते हैं जो कुछ वापस करते हैं

 public class App { public static void main(String[] args) { assert args != null : f0(); assert args != null : f1(); assert args != null : f2(); assert args != null : f3(); assert args != null : f4(); } private static byte f0() {return 0;} private static double f1() {return 0.0;} private static boolean f2() {return true;} private static String f3() {return "Hello!";} private static int[] f4() {return new int[] {10, 20, 30};} }

लेकिन शून्य लौटाने की विधि नहीं कह रहा है

 public class App { public static void main(String[] args) { assert args != null : f(); //    } private static void f() {} } >> COMPILATION ERROR: 'void' type is not allowed here

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

सभी अखंडित अपवादों की तरह, अभिकथन विफलताओं में आमतौर पर फ़ाइल संख्या और उस रेखा के साथ एक स्टैक ट्रेस होता है, जहां से उन्हें फेंका गया था। अनुमोदन के दूसरे रूप का उपयोग पहले के लिए प्राथमिकता में किया जाना चाहिए जब कार्यक्रम में कुछ अतिरिक्त जानकारी होती है जो विफलता का निदान करने में मदद कर सकती है। उदाहरण के लिए, यदि एक्सप्रेशन ₁ में दो एक्स और वाई चर के बीच संबंध शामिल है, तो दूसरे फॉर्म का उपयोग किया जाना चाहिए। इन शर्तों के तहत, अभिव्यक्ति _{2 के} लिए एक उचित चर "x:" + x + ", y:" + y होगा ।

अनुवादक टिप्पणी

यह उदाहरण के लिए, निम्न उदाहरण के लिए संदर्भित करता है।

 class App { public static void f(){ int x, y; //   assert x > y; } }

बस एक बयान उल्लंघन की स्थिति में एक AsertionError फेंक देंगे (x> y)।

लेकिन ऐसा उदाहरण

 class App { public static void f(){ int x, y; //   assert x > y : "x: " +  + ", : " + ; } }

एक संदेश के साथ एक AsertionError फेंक देंगे, कहते हैं, "x: 0, y: 123" जो प्रोग्रामर को गणना के समय x और y के विशिष्ट अवैध मूल्यों का विश्लेषण करने की अनुमति देगा।

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

अनुवादक टिप्पणी

ArrayUtils.min (int []] विधि में, पोस्ट-इनवेरिएंट के दो चेक और जटिलता में दोनों न्यूनतम तत्व (O (N)) को खोजने की जटिलता के साथ सराहनीय हैं

 public class ArrayUtils { public static int min(int[] array) { int min; //     //  min -    array assert checkMin(array, min); assert checkContains(array, min); return min; } // ,        private static boolean checkMin(int[] array, int min) { for (int elem : array) { if (elem < min) { return false; } } return true; } // ,     "" private static boolean checkContains(int[] array, int min) { for (int elem : array) { if (elem == min) { return true; } } return false; } }

अनुवादक टिप्पणी

खाली ऑपरेटर, जाहिरा तौर पर, ऑपरेटर का अर्थ है "अर्धविराम" (;)

 public class App { public static void main(String[] args) { ;;;; ;;;;;;;; ;;; ;; ;;; ;;;;;;;;;; ;; ;; ;;;;;;;; ;;;; for (int k = 0; k < 10; k++) { ; } } }

जावा में मुखर कीवर्ड जोड़ने से मौजूदा कोड के निहितार्थ हैं। अधिक जानकारी के लिए मौजूदा कार्यक्रमों के साथ संगतता देखें।

कोड में एंबेडिंग स्टेटमेंट्स

ऐसी कई स्थितियाँ हैं जहाँ बयानों का उपयोग करना उपयोगी है, जिनमें शामिल हैं:

ऐसी स्थितियाँ भी हैं जहाँ आपको उनका उपयोग नहीं करना चाहिए:

सार्वजनिक विधियों के तर्कों का परीक्षण करने के लिए बयानों का उपयोग न करें।

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

कथन को बंद किया जा सकता है और कार्यक्रमों को यह नहीं मानना चाहिए कि कथन में निहित तार्किक अभिव्यक्ति का मूल्यांकन किया जाएगा। इस नियम के उल्लंघन के गंभीर परिणाम हो सकते हैं। मान लीजिए कि आप सभी अशक्त तत्वों को नामों की सूची से हटाना चाहते हैं, यह जानते हुए कि सूची में इनमें से कम से कम एक या अधिक तत्व हैं। ऐसा करना गलत होगा:
```
 //  ! -     assert names.remove(null);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
कार्यक्रम ठीक काम करेगा बशर्ते कि दावे सक्षम किए गए हों, लेकिन अगर वे अक्षम हो गए हैं तो विफल हो जाएंगे। क्योंकि इस स्थिति में, वे सूची से अशक्त वस्तुओं को नहीं हटाएंगे। सही दृष्टिकोण बयान की पुष्टि करने से पहले कार्रवाई करना होगा, और फिर बयान की जांच करना कि कार्रवाई पूरी हो गई है:
```
 // ! -      boolean nullsRemoved = names.remove(null); //       . assert nullsRemoved;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
एक नियम के रूप में, बयानों में निहित भाव साइड इफेक्ट्स से मुक्त होना चाहिए: एक अभिव्यक्ति (अभिव्यक्ति मूल्यांकन) की गणना किसी भी राज्य को प्रभावित नहीं करना चाहिए जो गणना पूरी होने के बाद उपयोग किया जाता है। इस नियम का एकमात्र अपवाद: स्टेटमेंट एक राज्य को संशोधित कर सकता है जो विशेष रूप से अन्य बयानों के भीतर उपयोग किया जाता है। इस मुहावरे का उपयोग पाठ में नीचे दिखाया गया है ।

अनुवादक टिप्पणी

साइड इफेक्ट (दुष्प्रभाव) - कोई भी क्रिया जो "दृश्यमान दुनिया" को बदल देती है।

यह समझा जाता है कि बस कर रहा है

tmp x = 1 + 2 + 3;

यह "दृश्यमान दुनिया" को नहीं बदलता है (यदि कोई नीचे प्रोग्राम में tmp पहचानकर्ता का उपयोग नहीं करता है), हालांकि "अदृश्य प्रोग्रामर वर्ल्ड" बदल गया है (बायटेकोड्स लोड किए गए हैं, स्टैक पर मेमोरी एक स्थानीय चर के लिए आवंटित की गई है, प्रोसेसर 1, 2 और 3 को जोड़ा गया है)

क्रियान्वयन

System.out.println ("हैलो!");

"दृश्यमान दुनिया" को बदलता है (साइड इफेक्ट्स) - इस तरह की रेखा वाला एक प्रोग्राम स्पष्ट रूप से कंसोल में "अधिक" प्रिंट करता है, लेकिन फिर भी यह नीचे दिए गए प्रोग्राम को प्रभावित नहीं करता है - हम पढ़े गए डेटा को नहीं बदलते हैं।

लेकिन रेखा

tmp = 2 * tmp;

नीचे दिए गए प्रोग्राम को प्रभावित करता है (साइड इफेक्ट्स) अगर हम नीचे पढ़ते हैं और tmp वैरिएबल के मान का उपयोग करते हैं।

आंतरिक आक्रमणकारी

भाषा में बयान उपलब्ध होने से पहले, कई प्रोग्रामर ने कार्यक्रम के व्यवहार के बारे में अपनी मान्यताओं को "राज्य" करने के लिए टिप्पणियों का उपयोग किया। उदाहरण के लिए, इफिस-हनीफ-… की लंबी श्रृंखला में किसी अन्य अनुभाग के बारे में अपनी मान्यताओं का खुलासा करने के लिए…। पहले कुछ इस तरह लिखा था:

 if (i % 3 == 0) { ... } else if (i % 3 == 1) { ... } else{ //    (i % 3 == 2) ... }

अब "स्पष्ट रूप से सत्य कथन" के साथ प्रत्येक टिप्पणी के बजाय एक बयान का उपयोग करने के लायक है । उदाहरण के लिए, यह इस तरह पिछले कोड को फिर से लिखने के लायक है:

 if (i % 3 == 0) { ... } else if (i % 3 == 1) { ... } else { assert i % 3 == 2 : i; ... }

यह ध्यान देने योग्य है कि उपरोक्त उदाहरण में कथन 'i' ऋणात्मक हो सकता है, क्योंकि% ऑपरेटर शेष की गणना करता है, जो नकारात्मक हो सकता है।

अनुवादक टिप्पणी

एक उदाहरण है

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

 switch(suit) { caseSuit.CLUBS: //  ... break; caseSuit.DIAMONDS: //  ... break; caseSuit.HEARTS: //  ... break; caseSuit.SPADES: //  ... }

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

 default: assert false : suit;

यदि चर का सेट एक अलग मान लेता है और अभिकथन शामिल किया जाता है, तो अभिकथन विफल हो जाएगा और जोर का अपवाद छोड़ देगा।

एक स्वीकार्य विकल्प होगा:

 default: throw new AssertionError(suit);

यह मुहावरा सुरक्षा प्रदान करता है, भले ही दावे अक्षम हों। और यह अतिरिक्त सुरक्षा कुछ भी नहीं के लायक है: थ्रो स्टेटमेंट केवल तभी निष्पादित होता है जब प्रोग्राम क्रैश हो जाता है। इसके अलावा, यह विकल्प कुछ परिस्थितियों में मान्य है जब मुखर मान्य नहीं है। कहते हैं, यदि कोई विधि एक विधि लौटाती है, तो स्विच स्टेटमेंट में प्रत्येक मामले में रिटर्न होता है और स्विच के बाद कोई रिटर्न परिणाम नहीं होता है, तो पहला विकल्प सिंटैक्स त्रुटि की ओर ले जाएगा।

अनुवादक टिप्पणी

यह कार्यक्रम संकलन है

 public class App { public static int twice(int arg) { switch (arg) { case 0: return 0; case 1: return 2; case 2: return 4; case 3: return 6; default: throw new AssertionError(arg); } } }

लेकिन यह एक नहीं है

 class App { public static int twice(int arg) { switch (arg) { case 0: return 0; case 1: return 2; case 2: return 4; case 3: return 6; default: assert false : arg; } } } COMPILATION ERROR: Missing return statement

रन-टाइम आक्रमणकारी

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

 assert false;

मान लें कि आपके पास निम्नलिखित विधि है:

 void foo() { for (...) { if (...) {return;} ... } //      !!! }

आपको अंतिम टिप्पणी को बदलने की आवश्यकता है ताकि कोड इस तरह दिखे:

 void foo() { for (...) { if (...) {return;} } assert false; //      !!! }

नोट: इस विधि का उपयोग सावधानी के साथ करें। यदि राज्य जावा विनिर्देशन के अनुसार अनुपलब्ध होने के लिए निर्धारित किया जाता है, तो यदि आप कथन को वहाँ लगाने का प्रयास करते हैं, तो आपको एक संकलन-समय त्रुटि प्राप्त होगी। फिर, एक स्वीकार्य विकल्प सिर्फ एक जोर लगाना है।

अनुवादक टिप्पणी

जावा विनिर्देश के अनुसार, संकलक को "अनुपलब्धता" के लिए ऑपरेटरों की जांच करना आवश्यक है। यदि "दुर्गम" ऑपरेटरों का पता लगाया जाता है, तो संकलन त्रुटि होती है। पूर्वापेक्षा: कथनों के साथ एक कार्यक्रम जो कभी निष्पादित नहीं होता है, सबसे अधिक संभावना प्रोग्रामर त्रुटि का परिणाम है

 public class App { public static void main(String[] args) { return; return; //    } } >> COMPILATION ERROR: Unreachable statement

सत्यापन नियमों को सख्ती से लागू किया जाता है और सभी संभावित स्थितियों को शामिल नहीं किया जाता है। चलिए बस इतना ही कहते हैं कि संकलक को "छल" करना बहुत आसान है:

 public class App { public static void main(String[] args) { if (true) {return;} return; //   ,    } }

Preconditions, postconditions (पोस्टकंडिशन) वर्ग आक्रमणकारी

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

पूर्व शर्त (पूर्व शर्त)

अधिवेशन द्वारा, सार्वजनिक विधियों में पूर्वधारणाएँ विशिष्ट, विशिष्ट अपवादों को फेंकने वाले चेक का उत्पादन करती हैं। उदाहरण के लिए:

 /** *    (refresh rate). * * @param rate  ,     . * @throws IllegalArgumentException  (rate <= 0)  (rate > MAX_REFRESH_RATE). */ public void setRefreshRate(int rate) { //       if (rate <= 0 || rate > MAX_REFRESH_RATE) throw new IllegalArgumentException("Illegal rate: " + rate); setRefreshInterval(1000 / rate); }

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

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

 /** *    (    ) * * @param interval    . */ private void setRefreshInterval(int interval) { //     (nonpublic)  assert (interval > 0) && (interval <= 1000 / MAX_REFRESH_RATE) : interval; ... //    }

नोट: यदि MAX_REFRESH_RATE 1000 से अधिक है या क्लाइंट 1000 से अधिक की अपडेट दर का चयन करता है, तो यह कथन विफल हो जाएगा। यह वास्तव में, लाइब्रेरी में त्रुटि दर्शाता है!

लॉक-स्थिति पूर्व शर्त

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

 privateObject[] a; public synchronized int find(Object key) { return find(key, a, 0, a.length); } / /    -   c      private int find(Object key, Object[] arr, int start, int len) { ... }

एक स्थैतिक विधि जिसे होल्डलॉक (ऑब्जेक्ट) कहा जाता है, को यह जांचने के लिए थ्रेड क्लास में जोड़ा गया था कि क्या वर्तमान थ्रेड निर्दिष्ट ऑब्जेक्ट पर लॉक रखती है। इस विधि का उपयोग एक टिप्पणी के पूरक के लिए एक बयान के संयोजन में किया जा सकता है, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

 / /         : private int find(Object key, Object[] arr, int start, intlen) { assert Thread.holdsLock(this); // lock-status assertion ... }

कृपया ध्यान दें, एक बयान लिखना भी संभव है कि कुछ लॉक पर कब्जा नहीं किया गया है !

अनुवादक टिप्पणी

Java.util.concurrent से कई वर्गों के लिए समान जांच संभव है:

ReentrantLock.isHeldByCurrentThread () - सटीक समकक्ष

ReentrantReadWriteLock.isWriteLockedByCurrentThread () - सटीक एनालॉग

Semaphore.availablePermits () - समान विश्लेषण के लिए उपयोग किया जा सकता है

...

Postconditions (postconditions)

आप सार्वजनिक और गैर-गणतांत्रिक दोनों तरीकों से बयानों का उपयोग करके पोस्टकंडिशन को सत्यापित कर सकते हैं। उदाहरण के लिए, निम्नलिखित सार्वजनिक विधि एक बयान के बाद के परीक्षण का उपयोग करती है:

जिसका मूल्य (यह ^-1 मॉड मी) BigInteger लौटाता है।

  /** * @param m  * @return this^(-1) mod m. * @throws ArithmeticException  m <= 0   BigInteger *       * mod m ( BigInteger    m). */ public BigInteger modInverse(BigInteger m) { if (m.signum <= 0) { throw new ArithmeticException("Modulus not positive: " + m); } ... //   assert this.multiply(result).mod(m).equals(ONE) : this; return result; }

अनुवादक टिप्पणी

बीजगणित का एक बिट: बेस एन (जेड _एन ) पर अवशेषों की एक अंगूठी में, प्रत्येक गैर-एज़रो तत्व x में (और क्या अतिरिक्त है, एक विलक्षण) व्युत्क्रम तत्व है, यदि x का एन के साथ सहसंबंध है। यदि x का एन के साथ कोई अपराध नहीं है, तो x का पारस्परिक तत्व नहीं है।

उदाहरण # 1 (रिंग Z ₅ में उल्टा):

1 के लिए - उलटा = 1, 1 * 1 मॉड 5 = 1

2 के लिए - उलटा = 3, 2 * 3 मॉड 5 = 1

3 के लिए - उलटा = 2, 3 * 2 मॉड 5 = 1

4 के लिए - उलटा = 4, 4 * 4 मॉड 5 = 1

उदाहरण # 2 (रिंग जेड ₆ में उल्टा):

1 के लिए - उलटा = 1, 1 * 1 मॉड 6 = 1

2 के लिए - कोई वापसी नहीं

3 के लिए - कोई वापसी नहीं

4 के लिए - कोई वापसी नहीं

5 के लिए - उलटा = 5, 5 * 5 मॉड 6 = 1

232.x

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

  void foo(int[] array) { //     ... //          int- //    ,     }

यहां पोस्टऑप्शन के पाठात्मक कथन को "कार्यात्मक" में बदलने के लिए उपरोक्त विधि को कैसे बदलना है:

 void foo(final int[] array) { //  (inner)         class DataCopy { private int[] arrayCopy; DataCopy() { arrayCopy = (int[]) array.clone();} boolean isConsistent() {return Arrays.equals(array, arrayCopy);} } DataCopy copy = null; //  ;         assert ((copy = new DataCopy()) != null); ... //    array // ,   array   assert copy.isConsistent(); }

आप एक से अधिक डेटा आइटम संग्रहीत करने और मनमानी जटिलता के बयानों का परीक्षण करने के लिए इस दृष्टिकोण को आसानी से सामान्य कर सकते हैं।

निम्नलिखित में से एक अधिक विवरण के साथ पहला कथन (जो विशेष रूप से किसी साइड इफेक्ट के लिए किया जाता है) को बदलने का प्रयास कर सकता है:

 copy = new DataCopy();

यह मत करो। दूसरा उदाहरण इस बात की परवाह किए बिना कि कथनों को शामिल किया गया है या नहीं, सरणी को कॉपी करेगा। यह उस सिद्धांत का उल्लंघन करता है जो दावा करता है कि यदि उन्हें अक्षम किया गया है तो किसी भी कीमत पर नहीं उठाना चाहिए।

वर्ग के आक्रमणकारी

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

मुखर तंत्र हमलावरों की जाँच के लिए कोई विशेष शैली नहीं लगाता है। हालांकि, कभी-कभी अभिव्यक्तियों को संयोजित करना सुविधाजनक होता है जो आवश्यक बाधाओं को एक एकल आंतरिक विधि में जांचता है जो एक जोर को ट्रिगर कर सकता है। संतुलित वृक्ष उदाहरण को जारी रखने के लिए, एक निजी पद्धति को लागू करना उचित होगा जो यह जांचती है कि पेड़ वास्तव में डेटा संरचना की आवश्यकताओं के अनुसार संतुलित है:

 //  true     private boolean balanced() { ... }

चूँकि यह विधि बाधा की जाँच करती है, जो किसी भी विधि के क्रियान्वयन से पहले और बाद में सही होनी चाहिए, प्रत्येक सार्वजनिक विधि और निर्माणकर्ता के पास वापसी से ठीक पहले निम्नलिखित पंक्ति होनी चाहिए:

 assert balanced();

एक नियम के रूप में, प्रत्येक सार्वजनिक विधि के हेडर में समान चेक रखने की आवश्यकता नहीं है, केवल अगर डेटा संरचना देशी तरीकों के माध्यम से लागू नहीं की जाती है। इस मामले में, यह संभव है कि एक मेमोरी भ्रष्टाचार बग विधि कॉल के बीच जावा "हीप" ("देशी पीयर") के ढांचे के बाहर डेटा संरचना को नुकसान पहुंचा सकता है। विधि की शुरुआत में विफलता इंगित करेगी कि इस तरह का स्मृति भ्रष्टाचार हुआ है।

अनुवादक टिप्पणी

इसका मतलब यह है कि जावा जावा इंटरफेस (जेएनआई) के माध्यम से वर्ग को लागू किया गया है।

कक्षा के राज्य को अन्य वर्गों द्वारा बदला जा सकता है, तो प्रत्येक कक्षा पद्धति की शुरुआत में कक्षा के आक्रमणकारियों की जाँच करना भी शामिल करना उचित हो सकता है। क्लास डिज़ाइन का उपयोग करना बेहतर है, ताकि राज्य सीधे अन्य कक्षाओं के लिए दिखाई न दे!

अनुवादक टिप्पणी

« » ( ) « » . . «» , «» - , .

उन्नत तकनीक

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

वर्ग फ़ाइलों से दावों को खत्म करना

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

क्‍लास मेकेनिज्म क्‍लास फाइल से हटाने के लिए सीधे समर्थन की पेशकश नहीं करता है। हालाँकि, बयानों का उपयोग "सशर्त संकलन" के मुहावरे के साथ किया जा सकता है। यह दृष्टिकोण जावा विनिर्देशन में वर्णित है और संकलक को उत्पन्न श्रेणी की फाइलों में दिए गए सभी "संदर्भों" को समाप्त करने की अनुमति देता है:

  static final boolean asserts = ... ; // false    if (asserts) assert <expr> ;

अनुवादक टिप्पणी

« » . :

«An optimizing compiler may realize that the statement… will never be executed and may choose to omit the code for that statement from the generated class file ...»

( , ) javac «optimizing compiler»,

 public class App { static final boolean asserts = false; public static void main(String[] args) { //   if (asserts) { //  B } //  C } }

 public class App { static final boolean asserts = false; public static void main(String[] args) { //   //  C } }

दावा कैसे करें

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

 static { boolean assertsEnabled = false; assert assertsEnabled = true; //   !!! if (!assertsEnabled) throw new RuntimeException("   !!!"); }

अपनी कक्षा की घोषणा के शीर्ष पर इस स्थिर इनिशियलाइज़र को रखें।

अनुवादक टिप्पणी

« » , — . यानी

 class App { static int x = f(); static { System.err.println("static{}"); } static int y = g(); static { boolean assertsEnabled = false; assert assertsEnabled = true; if (!assertsEnabled) throw new RuntimeException(); } public static void main(String[] args) {} static int f() { System.err.println("f()"); return 0; } static int g() { System.err.println("g()"); return 0; } } >> f() >> static{} >> g() >> Exception in thread "main" java.lang.ExceptionInInitializerError >> ...

दावों का उपयोग करते हुए फ़ाइलों का संकलन

Javac संकलक को बयान वाले कोड को स्वीकार करने के लिए, आपको निम्न उदाहरण में -source 1.4 कमांड-लाइन विकल्प का उपयोग करना होगा :

 javac -source 1.4 MyClass.java

यह ध्वज आवश्यक है ताकि स्रोत कोड स्तर पर संगतता समस्या पैदा न हो।

अनुवादक टिप्पणी

javac (-source -target)

javac -source 1.3 -target 1.4

class-. , . यानी , Java 5 Java 1.3, - Java 1.4.

1.3 , , assert , generics, varargs,…

class- 1.4 , , class- Java 1.4. class- (minor_version, major_version)

 ClassFile { ... u2 minor_version; u2 major_version; ... }

Oracle's Java Virtual Machine implementation in JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. JDK releases 1.1.* support class file format versions in the range 45.0 through 45.65535 inclusive. For k ≥ 2, JDK release 1.k supports class file format versions in the range 45.0 through 44+k.0 inclusive.

दावों को सक्षम और अक्षम करना

डिफ़ॉल्ट रूप से, दावे रन टाइम पर अक्षम हो जाते हैं। हमारे पास दो कमांड लाइन स्विच हैं।

विस्तार, उपयोग के विभिन्न स्तरों पर अनुमोदन सक्षम करने के लिए -enableassertions या -ea । विवरणों के विभिन्न स्तरों पर अक्षम करने के लिए, -disableassertions या -da का उपयोग करें । आप ध्वज तर्कों के साथ बारीकियों को निर्दिष्ट करते हैं:

लापता तर्क

सिस्टम कक्षाओं को छोड़कर सभी वर्गों में बयानों को चालू या बंद करता है
packageName ...

निर्दिष्ट पैकेज में और सभी उप-पैकेजों में बयानों को सक्षम या अक्षम करता है
...

वर्तमान कार्यशील निर्देशिका में अनाम पैकेज में बयानों को सक्षम या अक्षम करता है।
className

निर्दिष्ट क्लास में स्टेटमेंट्स को सक्षम या निष्क्रिय करता है।

उदाहरण के लिए, निम्नलिखित कमांड केवल कॉम . wombat.fruitbat पैकेज और उसके उप- पैकेजों के लिए सक्षम दावों के साथ बैटट्यूटर प्रोग्राम लॉन्च करता है :

 java -ea:com.wombat.fruitbat... BatTutor

यदि कमांड लाइन में कई ऐसे "स्विच" होते हैं, तो उन्हें किसी भी वर्ग को लोड करने से पहले संसाधित किया जाता है। उदाहरण के लिए, निम्नलिखित कमांड com.wombat.fruitbat पैकेज के दावे के साथ बैटट्यूटर प्रोग्राम लॉन्च करता है, लेकिन com.wombat.fruitbat.Brickbat वर्ग अक्षम के साथ :

 java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat BatTutor

उपरोक्त कमांड लाइन झंडे एक अपवाद के साथ सभी क्लास लोडर पर लागू होते हैं। यह एक प्रणाली ClassLoader है। अपवाद चिंताएं तर्क के बिना स्विच करती हैं, जो (जैसा कि ऊपर संकेत दिया गया है) सिस्टम कक्षाओं पर लागू नहीं होता है। यह व्यवहार सिस्टम कक्षाओं को छोड़कर सभी वर्गों में अनुमोदन को शामिल करना आसान बनाता है, जो आमतौर पर वांछनीय है।

सभी सिस्टम कक्षाओं में स्टेटमेंट को सक्षम करने के लिए, एक अलग ध्वज का उपयोग करें: -enablesystemassertions या -esa । इसी तरह, सिस्टम कक्षाओं में स्टेटमेंट्स को डिसेबल करने के लिए -disablesystemassertions या -dsa का उपयोग करें ।

उदाहरण के लिए, निम्न कमांड ने बैटट्यूटर प्रोग्राम को सिस्टम क्लास और com.wombat.fruitbat पैकेज और उसके उप पैकेज में शामिल दावों के साथ लॉन्च किया:

 java -esa -ea:com.wombat.fruitbat...

जिस समय कक्षा आरंभीकृत की जाती है और तब तक नहीं बदलती है, तब वर्ग (चालू या बंद) के लिए अनुमोदन की स्थिति निर्धारित की जाती है। हालांकि, एक अलग मामला है जिसे विशेष हैंडलिंग की आवश्यकता होती है। यह संभव है, हालांकि आमतौर पर अवांछनीय है, आरंभ से पहले तरीकों या निर्माणकर्ताओं को निष्पादित करने के लिए। यह तब हो सकता है यदि वर्ग पदानुक्रम स्थैतिक आरंभीकरण प्रक्रिया में चक्रीय है।

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

अनुवादक टिप्पणी

:

An assert statement that is executed before its class has completed initialization is enabled.

This rule is motivated by a case that demands special treatment. Recall that the assertion status of a class is set no later than the time it is initialized. It is possible, though generally not desirable, to execute methods or constructors prior to initialization. This can happen when a class hierarchy contains a circularity in its static initialization, as in the following example:

 public class Foo { public static void main(String[] args) { Baz.testAsserts(); // Will execute after Baz is initialized. } } class Bar { static { Baz.testAsserts(); // Will execute before Baz is initialized! } } class Baz extends Bar { static void testAsserts() { boolean enabled = false; assert enabled = true; System.out.println("Asserts " + (enabled ? "enabled" : "disabled")); } } >> Asserts enabled >> Asserts disabled

Invoking Baz.testAsserts() causes Baz to be initialized. Before this can happen, Bar must be initialized. Bar's static initializer again invokes Baz.testAsserts(). Because initialization of Baz is already in progress by the current thread, the second invocation executes immediately, though Baz is not initialized (§12.4.2).

Because of the rule above, if the program above is executed without enabling assertions.

मौजूदा कार्यक्रमों के साथ संगतता

जावा में मुखर कीवर्ड जोड़ने से पहले से मौजूद बायनेरिज़ ( .class फ़ाइलों) के साथ कोई समस्या नहीं होती है । यदि आप एक ऐसे अनुप्रयोग को संकलित करने का प्रयास करते हैं जो पहचानकर्ता के रूप में मुखर का उपयोग करता है , तो आपको एक संकलक चेतावनी या त्रुटि संदेश प्राप्त होगा। ऐसी दुनिया से संक्रमण को सुविधाजनक बनाने के लिए जहां कथन उस दुनिया के लिए एक वैध पहचानकर्ता है जहां यह नहीं है, संकलक इस संस्करण में संचालन के दो तरीकों का समर्थन करता है:

स्रोत मोड 1.3 (डिफ़ॉल्ट) - संकलक उन प्रोग्रामों को स्वीकार करता है जो पहचानकर्ता के रूप में मुखर का उपयोग करते हैं , लेकिन चेतावनी जारी करते हैं। इस मोड में, प्रोग्राम को स्टेटमेंट का उपयोग करने की अनुमति नहीं है।
स्रोत मोड 1.4 - यदि प्रोग्राम पहचानकर्ता के रूप में मुखर का उपयोग करता है, तो संकलक एक त्रुटि संदेश उत्पन्न करता है । इस मोड में, कार्यक्रमों को अनुमोदन का उपयोग करने की अनुमति है।

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

अनुवादक टिप्पणी

( Java 1.4), . यानी javac JDK 7 JDK 8 , -source 1.3

डिजाइन और पूछे जाने वाले प्रश्न

इस खंड में मुखर की आंतरिक संरचना के बारे में अक्सर पूछे जाने वाले प्रश्न होते हैं।

सामान्य समस्याएं

संगतता

सिंटैक्स और शब्दार्थ

क्लास एश्योरियन इर्रर को

सक्षम और अक्षम करने के दावे

सामान्य प्रश्न

क्यों मुखरता प्रदान करते हैं, यह देखते हुए कि आप बिना विशेष समर्थन के जावा प्रोग्रामिंग लैंग्वेज में शीर्ष पर कार्यक्रम कर सकते हैं?

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

इस उपकरण का परिचय भाषा के विस्तार के माध्यम से क्यों लागू किया गया है, न कि एक पुस्तकालय के रूप में?

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

अनुवादक टिप्पणी

Java Oak . :).

-- (design-by-contract) , , Eiffel?

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

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

बूलियन अभिकथन के अलावा, यदि कोड को अक्षम किया जाता है तो कोड ब्लॉक निष्पादन को अक्षम करने के लिए मुखर जैसा निर्माण क्यों नहीं प्रदान किया जाता है?

इस तरह की डिज़ाइन प्रदान करने से प्रोग्रामर को जटिल इनलाइन स्टेटमेंट बनाने के लिए प्रोत्साहित किया जाएगा, हालांकि उन्हें अलग-अलग तरीकों से रखना बेहतर है।

अनुकूलता

क्या नया कीवर्ड मौजूदा कार्यक्रमों के साथ एक संगतता मुद्दा बन जाएगा जो पहचानकर्ता के रूप में 'जोर' का उपयोग करता है?

हां, स्रोत फ़ाइल स्तर पर (पहचानकर्ता के रूप में 'मुखर' का उपयोग करने वाली कक्षाओं के बायनेरिज़ सही ढंग से काम करना जारी रखेंगे।) संक्रमण को सुविधाजनक बनाने के लिए, हमने एक रणनीति लागू की है जिसके अनुसार डेवलपर्स संक्रमण अवधि के दौरान पहचानकर्ता के रूप में 'मुखर' का उपयोग करना जारी रख सकते हैं।

क्या यह उपकरण क्लास की फ़ाइलों को जन्म नहीं देता है जो पुराने JRE पर नहीं चलाई जा सकतीं?

हाँ, यह करता है। क्लास फ़ाइलों में ClassLoader के नए तरीके और वांछित वर्ग जैसे क्लास कक्षाएं शामिल होंगी।। यदि इन विधियों के कॉल वाले वर्ग-फ़ाइल को पुराने JRE (जिसके वर्ग ClassLoader के पास ऐसे तरीके नहीं हैं) द्वारा निष्पादित किया जाता है , तो प्रोग्राम निष्पादित नहीं किया जाएगा और NoSuchMethodError फेंक देगा । यह वास्तव में ऐसा है जब भाषा की नई विशेषताओं का उपयोग करने वाले प्रोग्राम पुराने संस्करणों के साथ संगत नहीं होते हैं।

सिंटेक्स और शब्दार्थ

अभिव्यक्ति ₂ में आदिम प्रकार की अनुमति क्यों है ?

इस अभिव्यक्ति के प्रकार को सीमित करने का कोई अच्छा कारण नहीं है। मनमाने प्रकार के संकल्प डेवलपर्स के लिए सुविधा प्रदान करते हैं, उदाहरण के लिए, प्रत्येक कथन के साथ एक अद्वितीय पूर्णांक कोड जोड़ना चाहते हैं। इसके अलावा, यह System.out.println (...) के तर्क के रूप में अभिव्यक्ति को "महसूस" करता है , जो वांछनीय लगता है।

कक्षा जोर

जब एक अभिकथन एक बयान से उत्पन्न होता है जिसमें अभिव्यक्ति ₂ गायब है , तो कार्यक्रम विस्तृत पाठ संदेश में कथन की स्थिति की रिपोर्ट क्यों नहीं करता है, उदाहरण के लिए, "ऊंचाई <मैक्सहाइट" ?

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

क्यों AssertionError वस्तु है, जो यह एक अपवाद दिया के लिए पहुँच प्रदान नहीं करता है? इसी प्रकार, कथन से एस्टरियन एर्रर कंस्ट्रक्टर के लिए एक मनमानी वस्तु क्यों नहीं पारित करेंत्रुटि संदेश (स्ट्रिंग) के बजाय?

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

क्यों प्रासंगिक पहुँच के तरीके (जैसे getFile () , getLine () , getMethod () ) AsErionError के लिए प्रदान नहीं करते हैं ?

यह सुविधा थ्रोएबल के लिए पहले से ही उपलब्ध है । इसलिए, इसका उपयोग सभी फेंकने वालों के लिए किया जा सकता है, न कि केवल जोरदार त्रुटियों के लिए। इस कार्यक्षमता को प्रदान करने के लिए हमारे पास Throwable.getStackTrace () पर ऐसी विधि है।

अनुवादक टिप्पणी

( assert AssertionError ) , Throwable.getStackTrace() — 1.4.

++- Throwable AssertionError.

अनुवादक टिप्पणी

 public class App { public static void main(String[] args) { try { f(); } catch (Throwable t) { StackTraceElement[] stack = t.getStackTrace(); StackTraceElement frame = stack[0]; System.out.println("FileName: " + frame.getFileName()); System.out.println("ClassName: " + frame.getClassName()); System.out.println("MethodName: " + frame.getMethodName()); System.out.println("LineNumber: " + frame.getLineNumber()); } } public static void f() { throw new RuntimeException(); } } >> FileName: App.java >> ClassName: App >> MethodName: f >> LineNumber: 16

AssertionError Error , RuntimeException ?

यह एक मूट प्वाइंट है।विशेषज्ञों के एक समूह ने इस पर चर्चा की और इस निष्कर्ष पर पहुंचे कि प्रोग्रामर को जोर देने के बाद प्रोग्रामर को पुनर्स्थापित करने की कोशिश करने से बचाने के लिए त्रुटि अधिक उपयुक्त पूर्वज है । सामान्य तौर पर, मुखर त्रुटि के स्रोत को स्थानीय बनाना मुश्किल या असंभव है। इस तरह के एक इनकार का मतलब है कि कार्यक्रम "एक अज्ञात दिशा में आगे बढ़ रहा है" ("ज्ञात स्थान के बाहर") और निष्पादन को जारी रखने के प्रयास घातक होने की संभावना है। इसके अलावा, कन्वेंशन सम्मेलनों में अधिकांश रनटाइम अपवादों को इंगित करने के तरीकों की आवश्यकता होती है (मतलब अपवाद उत्तराधिकारी , लेकिन त्रुटि नहीं ), जिसे वे फेंक सकते हैं ( @throws)javadoc में)। यह मुश्किल से विधि के विनिर्देश में शामिल करने के लिए समझ में आता है, जिसके तहत यह जोरदार त्रुटियों को उत्पन्न कर सकता है। ऐसी जानकारी को कार्यान्वयन विवरण के रूप में माना जा सकता है, जो कार्यान्वयन से कार्यान्वयन और रिलीज़ से रिलीज़ तक भिन्न हो सकता है।

अनुवादक टिप्पणी

«How to Write Doc Comments for the Javadoc Tool» «Documenting Exceptions with @throws Tag» .

दावों को सक्षम और अक्षम करना

अधिक परंपरागत पैकेज शब्दार्थ के बजाय पैकेज-ट्री शब्दार्थ का उपयोग करने वाले और बंद करने वाले बयान क्यों आते हैं?

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

अनुवादक टिप्पणी

Java, ( ).

: .

यानी aaa.bbb.ccc «» aaa.bbb xxx.yyy.zzz . (public, protected, (package private), private) : . « ».

Swing

 javax.swing.* javax.swing.border.* javax.swing.colorchooser.* javax.swing.event.* javax.swing.filechooser.* javax.swing.plaf.* javax.swing.plaf.basic.* javax.swing.plaf.metal.* javax.swing.plaf.multi.* javax.swing.plaf.nimbus.* javax.swing.plaf.synth.* javax.swing.table.* javax.swing.text.* javax.swing.text.html.* javax.swing.text.html.parser.* javax.swing.text.rtf.* javax.swing.tree.* javax.swing.undo.* javax.swing.* javax.swing.*

-- javax.swing.* .

यदि कोई अनुमोदन स्थिति सेट करने के लिए बहुत देर हो जाती है (यदि वर्ग पहले से ही आरंभिक है) तो अपवाद को फेंकने के बजाय सेट क्लैसैसेर्सियनस्टैटस () एक बूलियन को क्यों लौटाता है ?

यदि झंडा बहुत देर से सेट किया गया है तो कोई कार्रवाई (संभवतः एक चेतावनी संदेश के अलावा) आवश्यक या वांछित नहीं है। अपवाद अनावश्यक रूप से भारी लगता है।

दो का उपयोग करने के बजाय एक विधि नाम को अधिभार क्यों नहीं दिया गया: setDefaultAssertionStatus () और setAssertionStatus () ?

नामकरण के तरीकों में स्पष्टता आम अच्छे के लिए है। पद्धति ओवरलोडिंग से भ्रम पैदा होता है।

क्यों वांछितों के शब्दार्थ को अनुकूलित न करेंतब तक इसे और अधिक "प्रोग्रामर फ्रेंडली" बनाने के लिए बयान की वर्तमान स्थिति को वापस करके जब कक्षा पहले से ही आरम्भ की जाती है?

यह अभी तक स्पष्ट नहीं है कि परिणामी पद्धति का कोई लाभ होगा या नहीं। यह विधि किसी एप्लिकेशन प्रोग्रामर द्वारा उपयोग करने के लिए अभिप्रेत नहीं है, और यह आवश्यक से अधिक धीमी और कठिन बनाने के लिए अव्यावहारिक लगता है। एप्लेट्स को चालू / बंद करने से रोकने के लिए

कोई RuntimePermission क्यों नहीं है ?

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

अनुवादक टिप्पणी

«» Java.

java.lang.SecurityManager ( — , — ) RuntimePermission , — .

 //   "" public class App { public static void main(String[] args) { while (true); } }

 //   -  public class App { public static void main(String[] args) { new Thread(new Runnable() { public void run() { System.exit(123); } }).start(); while (true); } } >> Process finished with exit code 123

 //      System.exit(123); //         ... ""! public class App { public static void main(String[] args) { System.setSecurityManager(new SecurityManager() { public void checkExit(int status) { throw new SecurityException("You haven't permission to exit."); } }); new Thread(new Runnable() { public void run() {System.exit(123);} }).start(); while (true); } }

/ , , .

 public class App { public static void main(String[] args) { ClassLoader loader = App.class.getClassLoader(); loader.setDefaultAssertionStatus(true); loader.setPackageAssertionStatus("", true); } }

SecurityException

 grant { permission java.lang.RuntimePermission "getClassLoader"; };

java.policy

क्यों नहीं एक निर्माण प्रदान करें जो "आसपास" वर्ग के अनुमोदन की स्थिति को क्वेरी करेगा?

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

 boolean assertsEnabled = false; assert assertsEnabled = true; //   !!! / /  assertsEnabled

क्लास इनिशियलाइज़ेशन से पहले चलने वाला एक मुखर व्यवहार क्यों करता है जैसे कि बयानों को शामिल किया गया था?

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

संपर्क विवरण

मैं जावा प्रशिक्षण ऑनलाइन करता हूं (यहां प्रोग्रामिंग पाठ्यक्रम हैं ) और जावा कोर कोर्स के रीडिजाइन के भाग के रूप में प्रशिक्षण सामग्री का हिस्सा प्रकाशित करता हूं। आप YouTube चैनल पर दर्शकों के व्याख्यान की वीडियो रिकॉर्डिंग देख सकते हैं, शायद इस लेख में चैनल का वीडियो बेहतर व्यवस्थित है।

स्काइप: गोलोवचक्र्स

ईमेल: GolovachCourses@gmail.com

जावा में अनुबंध प्रोग्रामिंग

परिचय

कोड में एंबेडिंग स्टेटमेंट्स

आंतरिक आक्रमणकारी

रन-टाइम आक्रमणकारी

Preconditions, postconditions (पोस्टकंडिशन) वर्ग आक्रमणकारी

पूर्व शर्त (पूर्व शर्त)

लॉक-स्थिति पूर्व शर्त

Postconditions (postconditions)

वर्ग के आक्रमणकारी

उन्नत तकनीक

वर्ग फ़ाइलों से दावों को खत्म करना

दावा कैसे करें

दावों का उपयोग करते हुए फ़ाइलों का संकलन

दावों को सक्षम और अक्षम करना

मौजूदा कार्यक्रमों के साथ संगतता

डिजाइन और पूछे जाने वाले प्रश्न

सामान्य प्रश्न

अनुकूलता

सिंटेक्स और शब्दार्थ

कक्षा जोर

दावों को सक्षम और अक्षम करना

संपर्क विवरण

More articles: