एपीआई निर्माण: फ़्रेमयुक्त और दीवार

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



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



सार्वजनिक एपीआई - गौरैया नहीं, प्रकाशित करें - आप नहीं हटाएंगे। सब कुछ सही करने का केवल एक प्रयास है, इसलिए प्रयास करें।



एपीआई का उपयोग करना आसान होना चाहिए, लेकिन गलत तरीके से उपयोग करना मुश्किल है। ऐसे एपीआई का उपयोग करके कुछ सरल बनाना सरल होना चाहिए; मुश्किल संभव है; कुछ गलत करना असंभव या कम से कम कठिन होना चाहिए।



एपीआई को स्वयं का वर्णन करना चाहिए। इस तरह के एपीआई पर कोड सीखने से टिप्पणियों को पढ़ने की इच्छा नहीं होती है। सामान्य तौर पर, टिप्पणियों की शायद ही कभी आवश्यकता होती है।



एपीआई विकसित करने से पहले, स्वस्थ संशयवाद की डिग्री के साथ आवश्यकताओं को इकट्ठा करें। सामान्य कार्यों को महसूस करें और उन्हें हल करें।



एपीआई उपयोग पैटर्न के रूप में अपनी आवश्यकताओं को डिज़ाइन करें। डिज़ाइन प्रक्रिया के दौरान उनके साथ जांचें।



पहले ड्राफ्ट में, एपीआई संक्षिप्त होना चाहिए, आमतौर पर हस्ताक्षर और एक-पंक्ति विवरण के साथ एक पृष्ठ। यदि सब सही नहीं है, तो इसे फिर से करना आसान होगा।



एपीआई को लागू करने से पहले एक विस्तृत परिभाषा से पहले भी उपयोग पैटर्न को एनकोड करें । इसके लिए धन्यवाद, आप मौलिक रूप से अस्थिर एपीआई पर समय नहीं बिताएंगे।



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



उदाहरणों के लिए कोड अनुकरणीय होना चाहिए। उपयोगकर्ता इसे अपने कार्यक्रमों में कॉपी कर लेंगे। थोड़ी सी गलती सौ गुना के आसपास आती है।



आप हर किसी को और हर चीज को खुश नहीं कर सकते, सभी को समान रूप से खुश करने का प्रयास करते हैं। अधिकांश एपीआई अपने रचनाकारों की जरूरतों के अनुरूप होते हैं, जो उन्हें लचीलेपन से वंचित करते हैं।



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



एपीआई को विकसित करते समय, क्षेत्र में एक योद्धा नहीं है। अधिक से अधिक सहयोगियों को एपीआई दिखाएं और आलोचना लें। वे आपकी गलतियों को नोटिस कर सकते हैं।



नाम मायने रखता है। स्पष्टता और समरूपता के लिए प्रयास करें। सुसंगत रहें। प्रत्येक एपीआई एक छोटी भाषा है, उपयोगकर्ता इसमें पढ़ना और लिखना सीखेंगे। अच्छा एपीआई कोड प्राकृतिक पाठ की तरह है।



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



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



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



अस्थिरता कम करें। अपरिवर्तनीय वस्तुएँ सरल और सुरक्षित हैं।



दस्तावेज़ीकरण मायने रखता है। कोई भी दस्तावेज के बिना एक अच्छा एपीआई का उपयोग नहीं करेगा। हर सार्वजनिक इकाई का वर्णन करें: हर वर्ग, हर कार्य, हर तर्क, हर क्षेत्र।



एपीआई समाधान के प्रदर्शन निहितार्थों को ध्यान में रखें, लेकिन उन्हें एपीआई गुणवत्ता से ऊपर न रखें। सौभाग्य से, एक अच्छा एपीआई आमतौर पर उच्च प्रदर्शन वाले दोस्त होते हैं।



एक अजीब मठ में अपने चार्टर के साथ मत जाओ। एपीआई को भाषा और मंच में व्यवस्थित होना चाहिए, सम्मेलनों का पालन करना चाहिए। बुरा विचार एपीआई को बिना किसी बदलाव के एक प्लेटफॉर्म से दूसरे प्लेटफॉर्म पर पोर्ट करना है।



उपलब्धता कम करें। आप इसे संदेह करते हैं - इसे निजी बनाएं। यह एपीआई को सरल बनाता है और कनेक्टिविटी को कम करता है।



विरासत का उपयोग केवल तभी करें जब आप कुटिल होने के बिना कह सकते हैं कि एक उपवर्ग का प्रत्येक उदाहरण एक सुपरक्लास का एक उदाहरण है। एक सार्वजनिक वर्ग उत्तराधिकार नहीं दे सकता, केवल कार्यान्वयन का पुन: उपयोग करने के लिए।



विरासत की संभावना के बारे में सोचें और दस्तावेज़ करें, या इसे प्रतिबंधित करें। दस्तावेज़ीकरण में बताएं कि कक्षा के तरीके एक दूसरे को कैसे और कब कहते हैं। इसके बिना सुरक्षित वंशानुक्रम संभव नहीं है।



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



कम से कम आश्चर्य के सिद्धांत का पालन करें। एक फ़ंक्शन को अपने नाम और हस्ताक्षर के लिए सबसे अधिक अपेक्षित कुछ करना चाहिए।



जितनी जल्दी हो सके पॉप अप में त्रुटियों के लिए प्रयास करें। सभी के सर्वश्रेष्ठ - संकलन के स्तर पर। रन टाइम में - अधिमानतः पहली गलत कॉल पर।



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



अधिभार विधियों / कार्यों सावधानी के साथ। यदि उनका प्रभाव अलग है, तो अलग-अलग नाम देना बेहतर है।



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



कार्यों में तर्कों का एक क्रम रखें। अन्यथा, उपयोगकर्ता सब कुछ मिला देंगे।



तर्कों की लंबी सूची से बचें, खासकर यदि एक ही प्रकार के कई टुकड़े एक पंक्ति में जाते हैं।



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



नहीं।



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



यदि उपयोगकर्ता त्रुटि को संभालने में सक्षम होने की संभावना नहीं है, तो अनियंत्रित अपवादों को फेंक दें।



एपीआई बनाना एक कला है, विज्ञान नहीं। सुंदरता के बारे में सोचो, विश्वास अंतर्ज्ञान। इन नियमों का आँख बंद करके पालन न करें, लेकिन कभी-कभी और अच्छे कारण से इनका उल्लंघन करें।

---

प्रस्तुति और वीडियो : एक ही बात, लेकिन थोड़े अलग शब्दों में और जावा उदाहरणों के साथ।