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

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

डेकोरेटर

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

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

func ProfileMiddleware(next http.Handler) http.Handler { started := time.Now() next.ServeHTTP() elapsed := time.Now().Sub(started) fmt.Printf("HTTP: elapsed time %d", elapsed) } 

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

• एक पॉइंटर के माध्यम से डेटाबेस के साथ सीधे बातचीत करने के बजाय, हमें इंटरफ़ेस के माध्यम से इंटरैक्शन पर जाने की आवश्यकता है (व्यवहार को कार्यान्वयन से अलग करने के लिए)।
• SQL डेटाबेस क्वेरी निष्पादित करने वाली प्रत्येक विधि के लिए एक आवरण बनाएँ।

नतीजतन, हमें एक डेकोरेटर मिलता है जो आपको डेटाबेस के सभी प्रश्नों को प्रोफाइल करने की अनुमति देता है। इस दृष्टिकोण के लाभ निर्विवाद हैं:

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

इसलिए, उदाहरण के लिए, आप निम्नलिखित प्रकार के डेकोरेटर को लागू कर सकते हैं:

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

एक नियम के रूप में, जब अमीर सज्जाकार को लागू करते हैं, तो सभी तरीकों के कार्यान्वयन की आवश्यकता नहीं होती है: यह गैर-कार्यान्वित तरीकों को एक आंतरिक वस्तु को सौंपने के लिए पर्याप्त है।

मान लीजिए कि हमें डेटाबेस के लिए DML प्रश्नों को ट्रैक करने के लिए (INSERT / UPDATE / DELETE प्रश्नों को ट्रैक करने के लिए) एक उन्नत लकड़हारा लागू करना होगा। इस मामले में, हमें पूरे डेटाबेस इंटरफ़ेस को लागू करने की आवश्यकता नहीं है - केवल एक्जेक विधि को ओवरलैप करें।

 type MyDatabase interface{ Query(...) (sql.Rows, error) QueryRow(...) error Exec(query string, args ...interface) error Ping() error } type MyExecutor struct { MyDatabase } func (e *MyExecutor) Exec(query string, args ...interface) error { ... } 

इस प्रकार, हम देखते हैं कि गोलंग भाषा में एक समृद्ध डेकोरेटर बनाना भी विशेष रूप से कठिन नहीं है।

खाका विधि

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

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

मान लें कि हमें निम्नलिखित हस्ताक्षर के साथ एक टेम्पलेट विधि को परिभाषित करने की आवश्यकता है:

 func Method(s string) error 

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

 type MyStruct struct { MethodImpl func (me *MyStruct, s string) error } // Wrapper for template method func (ms *MyStruct) Method(s string) error { return ms.MethodImpl(ms, s) } // First constructor func NewStruct1() *MyStruct { return &MyStruct{ MethodImpl: func(me *MyStruct, s string) error { // Implementation 1 ... }, } } // Second constructor func NewStruct2() *MyStruct { return &MyStruct{ MethodImpl: func(me *MyStruct, s string) error { // Implementation 2 ... }, } } func main() { // Create object instance o := NewStruct2() // Call the template method err := o.Method("hello") ... } 

जैसा कि आप उदाहरण से देख सकते हैं, पैटर्न का उपयोग करने का शब्दार्थ शास्त्रीय OOP से लगभग अलग नहीं है।

अनुकूलक

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

सामान्य तौर पर, एडेप्टर अलग-अलग कार्यों और पूरे इंटरफेस के रूप में सेवा कर सकते हैं। यदि इंटरफेस के साथ सब कुछ कम या ज्यादा स्पष्ट और अनुमानित है, तो व्यक्तिगत कार्यों के दृष्टिकोण से सूक्ष्मताएं हैं।

मान लीजिए कि हम कुछ ऐसी सेवा लिखते हैं जिसमें कुछ आंतरिक एपीआई हैं:

 type MyService interface { Create(ctx context.Context, order int) (id int, err error) } 

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

 type Endpoint func(ctx context.Context, request interface{}) (interface{}, error) type CreateRequest struct { Order int } type CreateResponse struct { ID int, Err error } func makeCreateEndpoint(s MyService) Endpoint { return func(ctx context.Context, request interface{}) (interface{}, error) { // Decode request req := request.(CreateRequest) // Call service method id, err := s.Create(ctx, req.Order) // Encode response return CreateResponse{ID: id, Err: err}, nil } } 

MakeCreateEndpoint फ़ंक्शन के तीन मानक चरण हैं:

• डिकोडिंग मान
• लागू की जा रही सेवा के आंतरिक एपीआई से एक विधि को कॉल करना
• मूल्य एन्कोडिंग

गोकिट पैकेज के सभी समापन बिंदु इस सिद्धांत पर बनाए गए हैं।

आगंतुक

"विज़िटर" टेम्पलेट उस ऑब्जेक्ट की संरचना से एल्गोरिथ्म को अलग करने का एक तरीका है जिसमें यह संचालित होता है। पृथक्करण का परिणाम मौजूदा ऑब्जेक्ट संरचनाओं में उन्हें संशोधित किए बिना नए संचालन को जोड़ने की क्षमता है। यह खुले / बंद सिद्धांत का पालन करने का एक तरीका है।

ज्यामितीय आकृतियों के उदाहरण पर प्रसिद्ध आगंतुक पैटर्न पर विचार करें।

 type Geometry interface { Visit(GeometryVisitor) (interface{}, error) } type GeometryVisitor interface { VisitPoint(p *Point) (interface{}, error) VisitLine(l *Line) (interface{}, error) VisitCircle(c *Circle) (interface{}, error) } type Point struct{ X, Y float32 } func (point *Point) Visit(v GeometryVisitor) (interface{}, error) { return v.VisitPoint(point) } type Line struct{ X1, Y1 float32 X2, Y2 float32 } func (line *Line) Visit(v GeometryVisitor) (interface{}, error) { return v.VisitLine(line) } type Circle struct{ X, Y, R float32 } func (circle *Circle) Visit(v GeometryVisitor) (interface{}, error) { return v.VisitCircle(circle) } 

मान लीजिए कि हम किसी दिए गए बिंदु से निर्दिष्ट आकार तक की दूरी की गणना के लिए एक रणनीति लिखना चाहते हैं।

 type DistanceStrategy struct { X, Y float32 } func (s *DistanceStrategy) VisitPoint(p *Point) (interface{}, error) { // Evaluate distance from point(X, Y) to point p } func (s *DistanceStrategy) VisitLine(l *Line) (interface{}, error) { // Evaluate distance from point(X, Y) to line l } func (s *DistanceStrategy) VisitCircle(c *Circle) (interface{}, error) { // Evaluate distance from point(X, Y) to circle c } func main() { s := &DistanceStrategy{X: 1, Y: 2} p := &Point{X: 3, Y: 4} res, err := p.Visit(s) if err != nil { panic(err) } fmt.Printf("Distance is %g", res.(float32)) } 

इसी तरह, हम उन अन्य रणनीतियों को लागू कर सकते हैं जिनकी हमें आवश्यकता है:

• लंबवत सीमा
• वस्तु की क्षैतिज सीमा
• न्यूनतम फैले हुए वर्ग (MBR) का निर्माण
• अन्य आदिम हमें चाहिए।

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

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

 type geometryStrategy struct{ G Geometry } func (s *geometryStrategy) VisitPoint(p *Point) (interface{}, error) { return sGVisit(&pointStrategy{Point: p}) } func (d *geometryStrategy) VisitLine(l *Line) (interface{}, error) { return sGVisit(&lineStrategy{Line: l}) } func (d *geometryStrategy) VisitCircle(c *Circle) (interface{}, error) { return sGVisit(&circleStrategy{Circle: c}) } type pointStrategy struct{ *Point } func (point *pointStrategy) Visit(p *Point) (interface{}, error) { // Evaluate distance between point and p } func (point *pointStrategy) Visit(l *Line) (interface{}, error) { // Evaluate distance between point and l } func (point *pointStrategy) Visit(c *Circle) (interface{}, error) { // Evaluate distance between point and c } type lineStrategy struct { *Line } func (line *lineStrategy) Visit(p *Point) (interface{}, error) { // Evaluate distance between line and p } func (line *lineStrategy) Visit(l *Line) (interface{}, error) { // Evaluate distance between line and l } func (line *lineStrategy) Visit(c *Circle) (interface{}, error) { // Evaluate distance between line and c } type circleStrategy struct { *Circle } func (circle *circleStrategy) Visit(p *Point) (interface{}, error) { // Evaluate distance between circle and p } func (circle *circleStrategy) Visit(l *Line) (interface{}, error) { // Evaluate distance between circle and l } func (circle *circleStrategy) Visit(c *Circle) (interface{}, error) { // Evaluate distance between circle and c } func Distance(a, b Geometry) (float32, error) { return a.Visit(&geometryStrategy{G: b}) } 

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

निष्कर्ष

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

यदि सम्मानित हाब्रोज़िटेली पैटर्न पर कोई विचार रखते हैं, तो कृपया शर्मीली न हों और इस पर अपने विचार व्यक्त करें।