अच्छा काम करना बुरा: गो, भाग 1 के साथ बुराई कोड लिखना

एक जाओ प्रोग्रामर के लिए बुरी युक्तियाँ

जावा में प्रोग्रामिंग के दशकों के बाद, पिछले कुछ वर्षों में मैंने मुख्य रूप से गो पर काम किया। गो के साथ काम करना महान है, मुख्य रूप से क्योंकि कोड का पालन करना बहुत आसान है। जावा ने मल्टीपल इनहेरिटेंस, मैनुअल मेमोरी मैनेजमेंट और ऑपरेटर ओवरलोडिंग को हटाकर C ++ प्रोग्रामिंग मॉडल को सरल बनाया है। गो एक ही करता है, एक सरल और सीधी प्रोग्रामिंग शैली की ओर बढ़ना जारी रखता है, पूरी तरह से वंशानुक्रम और फ़ंक्शन को ओवरलोडिंग को हटा देता है। सरल कोड पठनीय कोड है, और पठनीय कोड समर्थित कोड है। और यह कंपनी और मेरे कर्मचारियों के लिए बहुत अच्छा है।

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

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

(defun add-mult-pi (in1 in2) (setq a in1) (setq b in2) (setq c (+ ab)) (setq d (* 3.1415 c) d ) 

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

आपके कोड को असमर्थित बनाने के लिए कई अलग-अलग तरीके हैं, लेकिन हम केवल कुछ ही देखेंगे। बुराई करने के लिए, आपको पहले अच्छा करना सीखना चाहिए। इसलिए, हम पहले देखते हैं कि "अच्छा" गो प्रोग्रामर कैसे लिखते हैं, और फिर हम इसके विपरीत कैसे देखते हैं।

खराब पैकेजिंग

पैकेज शुरू करने के लिए एक आसान विषय है। कैसे कोड संगठन हानि पठनीयता कर सकते हैं?

गो में, पैकेज नाम का उपयोग निर्यात की गई इकाई (उदाहरण के लिए, ` fmt.Println` या` http.RegisterFunc` ) के लिए किया जाता है। चूंकि हम पैकेज का नाम देख सकते हैं, "अच्छा" गो प्रोग्रामर सुनिश्चित करते हैं कि यह नाम बताता है कि निर्यातित इकाइयाँ क्या हैं। हमारे पास उपयोग पैकेज नहीं होने चाहिए, क्योंकि हमारे लिए ' use.JSONMarshal ' जैसे नाम काम नहीं करेंगे - हमें ' json.Marshal` की आवश्यकता है।

"अच्छा" गो डेवलपर्स भी डीएओ या मॉडल के लिए एक अलग पैकेज नहीं बनाते हैं। इस शब्द से अपरिचित लोगों के लिए, DAO एक " डेटा एक्सेस ऑब्जेक्ट " -एक कोड लेयर है जो आपके डेटाबेस के साथ इंटरैक्ट करता है। मैं एक ऐसी कंपनी के लिए काम करता था जहाँ 6 जावा सेवाओं ने उसी डेटाबेस को एक्सेस करने के लिए एक ही DAO लाइब्रेरी का आयात किया, जिसे उन्होंने साझा किया, क्योंकि " ... अच्छी तरह से, आप जानते हैं, माइक्रोसोर्सेज समान हैं ... "।

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

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

अनुचित इंटरफेस

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

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

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

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

इससे आपके कोड को समझना आसान हो जाता है, क्योंकि एक विधि घोषणा न केवल यह निर्धारित करती है कि उसे किस डेटा की आवश्यकता है, बल्कि यह सटीक रूप से इंगित करता है कि वह किस कार्यक्षमता का उपयोग करने जा रहा है। यह एक कारण है कि अच्छे गो डेवलपर्स सलाह का पालन करते हैं: " इंटरफेस स्वीकार करें, संरचनाएं लौटाएं ।"

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

पास ढेर संकेत

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

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

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

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

 func main() { //  a := 1 b := a b = 2 fmt.Println(a, b) // prints 1 2 //  c := &a *c = 3 fmt.Println(a, b, *c) // prints 3 2 3 } 

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

 type Foo struct { A int B string } func getA() int { return 20 } func getB(i int) string { return fmt.Sprintf("%d",i*2) } func main() { f := Foo{} fA = getA() fB = getB(fA) //  ,    f fmt.Println(f) } 

खैर, हम कैसे “दुष्ट” बन जाते हैं? बहुत सरल - इस मॉडल को चालू करना।

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

 type Foo struct { A int B string } func setA(f *Foo) { fA = 20 } //   fA! func setB(f *Foo) { fB = fmt.Sprintf("%d", fA*2) } func main() { f := Foo{} setA(&f) setB(&f) // ,  setA  setB //    ? fmt.Println(f) } 

दहशत फैलाने वाला

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

 func (dus DBUserService) Load(id int) (User, error) { rows, err := dus.DB.Query("SELECT name FROM USERS WHERE ID = ?", id) if err != nil { return User{}, err } if !rows.Next() { return User{}, fmt.Errorf("no user for id %d", id) } var name string err = rows.Scan(&name) if err != nil { return User{}, err } err = rows.Close() if err != nil { return User{}, err } return User{Id: id, Name: name}, nil } 

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

• सबसे पहले, वे सभी पुस्तकालयों के सभी स्रोत कोड को पढ़ सकते हैं जो उनके कोड को कॉल करते हैं, और सभी लाइब्रेरी जिन्हें कॉल लाइब्रेरी कहा जाता है, आदि।
• दूसरे, वे प्रलेखन पर भरोसा कर सकते हैं। मैं पक्षपाती हो सकता हूं, लेकिन व्यक्तिगत अनुभव मुझे प्रलेखन पर पूरी तरह से भरोसा करने की अनुमति नहीं देता है।

तो, हम इस बुराई को गो के पास कैसे लाते हैं? घबराहट ( घबराहट ) और रिकवरी ( ठीक होना ), बिल्कुल! घबराहट ऐसी स्थितियों के लिए डिज़ाइन की गई है, जैसे "ड्राइव गिर गया" या "नेटवर्क कार्ड में विस्फोट हो गया।" लेकिन इस तरह के लिए नहीं - "किसी ने int के बजाय स्ट्रिंग पास किया"।

दुर्भाग्य से, अन्य, "कम प्रबुद्ध डेवलपर्स" अपने कोड से त्रुटियों को वापस कर देंगे। इसलिए, यहाँ PanicIfErr का एक छोटा सहायक कार्य है। अन्य डेवलपर्स की गलतियों को घबराहट में बदलने के लिए इसका उपयोग करें।

 func PanicIfErr(err error) { if err != nil { panic(err) } } 

आप PanicIfErr का उपयोग अन्य लोगों की गलतियों को लपेटने, कोड को संपीड़ित करने के लिए कर सकते हैं। कोई और अधिक बदसूरत त्रुटि से निपटने! कोई भी गलती अब एक आतंक है। यह इतना उत्पादक है!

 func (dus DBUserService) LoadEvil(id int) User { rows, err := dus.DB.Query( "SELECT name FROM USERS WHERE ID = ?", id) PanicIfErr(err) if !rows.Next() { panic(fmt.Sprintf("no user for id %d", id)) } var name string PanicIfErr(rows.Scan(&name)) PanicIfErr(rows.Close()) return User{Id: id, Name: name} } 

आप पुनर्प्राप्ति को कार्यक्रम की शुरुआत के करीब कहीं रख सकते हैं, शायद अपने स्वयं के मिडलवेयर में । और फिर कहें कि आप न केवल त्रुटियों को संसाधित करते हैं, बल्कि किसी और का कोड क्लीनर भी बनाते हैं। अच्छाई करके बुराई करना सबसे अच्छी तरह की बुराई है।

 func PanicMiddleware(h http.Handler) http.Handler { return http.HandlerFunc( func(rw http.ResponseWriter, req *http.Request){ defer func() { if r := recover(); r != nil { fmt.Println(", - .") } }() h.ServeHTTP(rw, req) } ) } 

साइड इफेक्ट्स सेट करना

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

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

 package account type Account struct{ Id int UserId int } func init() { fmt.Println("  !") } func init() { fmt.Println("   ,     init()") } 

खाली कार्यों को अक्सर खाली आयात के साथ जोड़ा जाता है। गो के पास आयातों को घोषित करने का एक विशेष तरीका है, जो 'आयात _' github.com / lib / pq` की तरह दिखता है। जब आप किसी आयातित पैकेज के लिए एक खाली नाम पहचानकर्ता सेट करते हैं, तो यह init पद्धति चलती है, लेकिन यह पैकेज पहचानकर्ताओं में से किसी को नहीं दिखाती है। कुछ गो पुस्तकालयों के लिए - जैसे डेटाबेस ड्राइवर या छवि प्रारूप - आपको खाली पैकेज आयात को सक्षम करके उन्हें लोड करना होगा, बस init फ़ंक्शन को कॉल करने के लिए ताकि पैकेज अपना कोड पंजीकृत कर सके।

 package main import _ "github.com/lib/pq" func main() { db, err := sql.Open( "postgres", "postgres://jon@localhost/evil?sslmode=disable") } 

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

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

 package account import ( "fmt" "github.com/evil-go/example/registry" ) type StubAccountService struct {} func (a StubAccountService) GetBalance(accountId int) int { return 1000000 } func init() { registry.Register("account", StubAccountService{}) } 

यदि आप किसी खाते का उपयोग करना चाहते हैं, तो अपने कार्यक्रम में एक खाली आयात डालें। इसका मुख्य या संबंधित कोड होना जरूरी नहीं है - यह सिर्फ "कहीं" होना है। यह जादू है!

 package main import ( _ "github.com/evil-go/example/account" "github.com/evil-go/example/registry" ) type Balancer interface { GetBalance(int) int } func main() { a := registry.Get("account").(Balancer) money := a.GetBalance(12345) } 

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

जटिल विन्यास

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

 func main() { b, err := ioutil.ReadFile("account.json") if err != nil { fmt.Errorf("error reading config file: %v", err) os.Exit(1) } m := map[string]interface{}{} json.Unmarshal(b, &m) prefix := m["account.prefix"].(string) maker := account.NewMaker(prefix) } type Maker struct { prefix string } func (m Maker) NewAccount(name string) Account { return Account{Name: name, Id: m.prefix + "-12345"} } func NewMaker(prefix string) Maker { return Maker{prefix: prefix} } 

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

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

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

 func (m maker) NewAccount(name string) Account { return Account{Name: name, Id: m.prefix + "-12345"} } var Maker maker func init() { b, _ := ioutil.ReadFile("account.json") m := map[string]interface{}{} json.Unmarshal(b, &m) Maker.prefix = m["account.prefix"].(string) } 

कार्यात्मकता रूपरेखा

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

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

, . «», «» «».