Go में SOLID सिद्धांत: सिद्धांत से Golang में अभ्यास तक

Go में SOLID सिद्धांत: A से Z तक सिद्धांत और अभ्यास

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

1. Single Responsibility Principle (SRP) — एकल उत्तरदायित्व का सिद्धांत

सार: प्रत्येक मॉड्यूल, संरचना या फ़ंक्शन में बदलाव का केवल एक ही कारण होना चाहिए। दूसरे शब्दों में, उन्हें एक स्पष्ट रूप से परिभाषित कार्य के लिए जिम्मेदार होना चाहिए।

समस्या: अक्सर डेवलपर्स एक ही संरचना में सारा तर्क डाल देते हैं: सत्यापन, डेटाबेस में सहेजना, ईमेल भेजना, प्रतिक्रिया को फ़ॉर्मेट करना। इससे "गॉड ऑब्जेक्ट्स" (God Objects) बनते हैं जिनका परीक्षण और संशोधन करना कठिन होता है।

Go में समाधान: विभिन्न संरचनाओं और पैकेजों के बीच उत्तरदायित्व को विभाजित करें।

// ❌ बुरा: एक ही संरचना सब कुछ करती है\ntype UserService struct {\n    db *sql.DB\n    mailer *Mailer\n}\n\nfunc (s *UserService) CreateUser(name, email string) error {\n    // 1. सत्यापन\n    if !strings.Contains(email, "@") {\n        return errors.New("invalid email")\n    }\n    // 2. डेटाबेस में सहेजना\n    _, err := s.db.Exec("INSERT INTO users (name, email) VALUES ($1, $2)", name, email)\n    if err != nil {\n        return err\n    }\n    // 3. स्वागत ईमेल भेजना\n    return s.mailer.Send(email, "Welcome!", "Thank you for registering")\n}\n\n// ✅ अच्छा: उत्तरदायित्व का विभाजन\ntype UserValidator struct{}\nfunc (v *UserValidator) Validate(email string) error {\n    if !strings.Contains(email, "@") {\n        return errors.New("invalid email")\n    }\n    return nil\n}\n\ntype UserRepository struct {\n    db *sql.DB\n}\nfunc (r *UserRepository) Save(name, email string) error {\n    _, err := r.db.Exec("INSERT INTO users (name, email) VALUES ($1, $2)", name, email)\n    return err\n}\n\ntype WelcomeMailer struct {\n    mailer *Mailer\n}\nfunc (m *WelcomeMailer) Send(email string) error {\n    return m.mailer.Send(email, "Welcome!", "Thank you for registering")\n}\n\ntype UserService struct {\n    validator *UserValidator\n    repo      *UserRepository\n    mailer    *WelcomeMailer\n}\n\nfunc (s *UserService) CreateUser(name, email string) error {\n    if err := s.validator.Validate(email); err != nil {\n        return err\n    }\n    if err := s.repo.Save(name, email); err != nil {\n        return err\n    }\n    return s.mailer.Send(email)\n}

व्यावहारिक सुझाव: यदि आप "और" संयोजन का उपयोग किए बिना संक्षेप में वर्णन नहीं कर सकते कि आपका फ़ंक्शन या मेथड क्या करता है, तो संभवतः SRP का उल्लंघन हुआ है।

2. Open-Closed Principle (OCP) — खुले/बंद का सिद्धांत

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

Go में समाधान: व्यवहार को अमूर्त करने के लिए इंटरफ़ेस का उपयोग करें।

// ❌ बुरा: नए भुगतान प्रकार को जोड़ने पर ProcessPayment फ़ंक्शन को बदलना होगा\ntype PaymentProcessor struct{}\n\nfunc (p *PaymentProcessor) Process(paymentType string, amount float64) {\n    if paymentType == "credit_card" {\n        // क्रेडिट कार्ड के लिए तर्क\n    } else if paymentType == "paypal" {\n        // PayPal के लिए तर्क\n    }\n    // "crypto" जोड़ने पर — एक नया else if जोड़ना होगा\n}\n\n// ✅ अच्छा: इंटरफ़ेस कोड को बदले बिना कार्यक्षमता का विस्तार करने की अनुमति देता है\ntype PaymentMethod interface {\n    Pay(amount float64) error\n}\n\ntype CreditCard struct{}\nfunc