🚨 🕰️ 🏫 गो में इंटरफेस का उपयोग कैसे करें 🚆 🗞️ 🐹

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

इस पोस्ट में लेखक से गो में इंटरफेस के इष्टतम उपयोग के बारे में सिफारिशें हैं, जो कोड लिखने में उनके अनुभव के आधार पर है।

इस पोस्ट के उदाहरणों में हम दो पैकेज animal और circus उपयोग करेंगे। इस पोस्ट में कई चीजें पैकेज के नियमित उपयोग पर कोड बॉर्डरिंग के साथ काम करने का वर्णन करती हैं।

कैसे नहीं करना है

एक बहुत ही सामान्य घटना जो मैं देखता हूं:

 package animals type Animal interface { Speaks() string } //  Animal type Dog struct{} func (a Dog) Speaks() string { return "woof" }

 package circus import "animals" func Perform(a animal.Animal) string { return a.Speaks() }

यह जावा-शैली इंटरफेस का तथाकथित उपयोग है। यह निम्नलिखित चरणों की विशेषता हो सकता है:

एक इंटरफ़ेस परिभाषित करें।
एक प्रकार को परिभाषित करें जो इंटरफ़ेस व्यवहार को संतुष्ट करता है।
इंटरफ़ेस कार्यान्वयन को संतुष्ट करने वाले तरीकों को परिभाषित करें।

सारांश में, हम "लेखन प्रकारों के साथ काम कर रहे हैं जो इंटरफेस को संतुष्ट करते हैं।" इस कोड की अपनी अलग गंध है , निम्नलिखित विचार सुझाते हैं:

केवल एक प्रकार इंटरफ़ेस को संतुष्ट करता है, इसे आगे बढ़ाने के किसी भी इरादे के बिना।
फ़ंक्शंस आमतौर पर इंटरफ़ेस प्रकारों के बजाय कंक्रीट प्रकार लेते हैं।

इसके बजाय कैसे करें

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

जिसका अर्थ है: animals पैकेज में Animal को परिभाषित करने के बजाय, इसे उपयोग के बिंदु पर परिभाषित करें, अर्थात, circus * पैकेज।

 package animals type Dog struct{} func (a Dog) Speaks() string { return "woof" }

 package circus type Speaker interface { Speaks() string } func Perform(a Speaker) string { return a.Speaks() }

ऐसा करने का एक अधिक प्राकृतिक तरीका इस प्रकार है:

परिभाषित प्रकार
उपयोग के बिंदु पर इंटरफ़ेस को परिभाषित करें।

यह दृष्टिकोण animals पैकेज के घटकों पर निर्भरता को कम करता है। निर्भरता को कम करना दोष-सहिष्णु सॉफ्टवेयर बनाने का सही तरीका है।

बिस्तर का नियम

अच्छा सॉफ्टवेयर लिखने के लिए एक अच्छा सिद्धांत है। यह डाक का कानून है , जिसे अक्सर निम्नानुसार तैयार किया जाता है:

"जो आप का उल्लेख करते हैं और जो आप स्वीकार करते हैं, उसके बारे में उदारवादी हो"

गो के संदर्भ में, कानून है:

"स्वीकार इंटरफेस, वापसी संरचनाओं"

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

 func funcName(a INTERFACETYPE) CONCRETETYPE

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

"खाली इंटरफ़ेस कुछ नहीं कहता है," रोब पाइक

इसलिए, कार्यों को interface{} को स्वीकार करने से रोकना अत्यधिक उचित है।

आवेदन उदाहरण: नकल

डाक कानून लागू करने के लाभों का एक महत्वपूर्ण उदाहरण परीक्षण के मामले हैं। मान लें कि आपके पास एक फ़ंक्शन है जो इस तरह दिखता है:

 func Takes(db Database) error

यदि Database एक इंटरफ़ेस है, तो परीक्षण कोड में आप बस एक वास्तविक DB ऑब्जेक्ट पास करने की आवश्यकता के बिना Database कार्यान्वयन की एक नकल प्रदान कर सकते हैं।

जब पहले से इंटरफ़ेस की परिभाषा स्वीकार्य है

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

एक इंटरफ़ेस को परिभाषित करना आमतौर पर ओवर-इंजीनियरिंग की स्मैक है, लेकिन ऐसी परिस्थितियां हैं जिनमें आपको स्पष्ट रूप से ऐसा करना चाहिए। विशेष रूप से, निम्नलिखित उदाहरण दिमाग में आते हैं:

सीलबंद इंटरफेस
सार डेटा प्रकार
पुनरावर्ती इंटरफेस

अगला, हम संक्षेप में उनमें से प्रत्येक पर विचार करते हैं।

सीलबंद इंटरफेस

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

यदि आपने कुछ इस तरह परिभाषित किया है:

 type Fooer interface { Foo() sealed() }

केवल Fooer द्वारा परिभाषित पैकेज ही इसका उपयोग कर सकते हैं और इससे कुछ भी मूल्य बना सकते हैं। यह आपको प्रकारों के लिए ब्रूट-फोर्स स्विच ऑपरेटर बनाने की अनुमति देता है।

सीलबंद इंटरफ़ेस विश्लेषण टूल को किसी भी गैर-टकराव पैटर्न पैटर्न को आसानी से लेने की अनुमति देता है। BurntSushi के सारांश पैकेज का उद्देश्य इस समस्या को हल करना है।

सार डेटा प्रकार

पहले से एक इंटरफ़ेस को परिभाषित करने के एक अन्य मामले में सार डेटा प्रकार बनाना शामिल है। उन्हें या तो सील किया जा सकता है या सील नहीं किया जा सकता है।

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

 type Interface interface { // Len —    . Len() int // Less      //   i     j. Less(i, j int) bool // Swap     i  j. Swap(i, j int) }

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

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

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

पुनरावर्ती इंटरफेस

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

 type Fooer interface { Foo() Fooer }

एक पुनरावर्ती इंटरफ़ेस पैटर्न को अग्रिम में इसकी परिभाषा की आवश्यकता होगी। बिंदु का उपयोग इंटरफ़ेस परिभाषा सिफारिश यहाँ लागू नहीं है।

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

निष्कर्ष

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

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

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

इस प्रकार, यह पोस्ट स्वयं को याद दिलाने के रूप में भी कार्य करती है कि कोड लिखने का मार्ग कैसा दिखता है, जो बाद में सिरदर्द का कारण नहीं होगा। आपकी टिप्पणियों की प्रतीक्षा है!

गो में इंटरफेस का उपयोग कैसे करें