HI
RU
EN
ES
ZH
FR
DE
PT
AR
Go में SOLID सिद्धांत: सिद्धांत और व्यावहारिक गाइड
\n\nSOLID पाँच मूलभूत ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सिद्धांतों का संक्षिप्त नाम है, जो लचीला, रखरखाव योग्य और स्केलेबल कोड बनाने में मदद करते हैं। हालाँकि Go एक क्लासिक OOP भाषा नहीं है (इसमें पारंपरिक अर्थों में क्लास और इनहेरिटेंस नहीं है), ये सिद्धांत Go में डेवलपमेंट के दौरान लागू और अत्यंत उपयोगी हैं। इस लेख में, हम प्रत्येक सिद्धांत को विशिष्ट उदाहरणों के साथ समझेंगे, दिखाएंगे कि उन्हें Go में कैसे लागू करें, और बताएंगे कि यह क्यों महत्वपूर्ण है।
\n\n1. Single Responsibility Principle (SRP) — एकल उत्तरदायित्व का सिद्धांत
\n\nसार: प्रत्येक मॉड्यूल, क्लास या फंक्शन में बदलाव का केवल एक ही कारण होना चाहिए। दूसरे शब्दों में, एक इकाई को कार्यक्षमता के केवल एक हिस्से के लिए जिम्मेदार होना चाहिए।
\n\nGo में, यह अक्सर तब टूटता है जब एक स्ट्रक्चर (struct) बहुत सारे कार्य करता है: डेटाबेस के साथ काम करना, ईमेल भेजना, रिपोर्ट बनाना।
\n\nखराब उदाहरण (SRP का उल्लंघन):
\ntype User struct {\n Name string\n Email string\n}\n\nfunc (u *User) Save() error {\n // डेटाबेस में सेव करने की लॉजिक\n return nil\n}\n\nfunc (u *User) SendWelcomeEmail() error {\n // ईमेल भेजने की लॉजिक\n return nil\n}\n\nfunc (u *User) GenerateReport() string {\n // रिपोर्ट बनाने की लॉजिक\n return "report"\n}\nअच्छा उदाहरण (SRP का पालन):
\ntype User struct {\n Name string\n Email string\n}\n\ntype UserRepository struct{}\n\nfunc (r *UserRepository) Save(u *User) error {\n // केवल सेव करना\n return nil\n}\n\ntype EmailService struct{}\n\nfunc (s *EmailService) SendWelcome(u *User) error {\n // केवल ईमेल भेजना\n return nil\n}\n\ntype ReportGenerator struct{}\n\nfunc (g *ReportGenerator) Generate(u *User) string {\n // केवल रिपोर्ट जनरेट करना\n return "report"\n}\nनिष्कर्ष: प्रत्येक स्ट्रक्चर अपने कार्य के लिए जिम्मेदार है। सेव लॉजिक में बदलाव से ईमेल भेजना प्रभावित नहीं होगा।
\n\n2. Open-Closed Principle (OCP) — खुले/बंद का सिद्धांत
\n\nसार: सॉफ्टवेयर इकाइयाँ (क्लास, मॉड्यूल, फंक्शन) विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद। यानी, आपको मौजूदा कोड को बदले बिना नई कार्यक्षमता जोड़ने में सक्षम होना चाहिए।
\n\nGo में, यह इंटरफेस के माध्यम से बेहतरीन रूप से लागू किया जाता है।
\n\nखराब उदाहरण (OCP का उल्लंघन):
\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 // नया प्रकार जोड़ने पर इस मेथड को बदलना होगा\n}\nअच्छा उदाहरण (OCP का पालन):
\ntype PaymentMethod interface {\n Pay(amount float64) error\n}\n\ntype CreditCard struct{}\n\nfunc (c *CreditCard) Pay(amount float64) error {\n // क्रेडिट कार्ड के लिए लॉजिक\n return nil\n}\n\ntype PayPal struct{}\n\nfunc (p *PayPal) Pay(amount float64) error {\n // PayPal के लिए लॉजिक\n return nil\n}\n\nfunc ProcessPayment(method PaymentMethod, amount float64) error {\n return method.Pay(amount)\n}\nनिष्कर्ष: अब, भुगतान का नया तरीका जोड़ने के लिए (जैसे, ApplePay), बस Pay() मेथड वाली एक नई स्ट्रक्चर बनाएँ, मौजूदा कोड को बिना छुए।
3. Liskov Substitution Principle (LSP) — बारबरा लिस्कोव का प्रतिस्थापन सिद्धांत
\n\nसार: प्रोग्राम में ऑब्जेक्ट्स को उनके उपप्रकारों के इंस्टेंस से बदला जा सकना चाहिए, बिना प्रोग्राम की शुद्धता को बदले। Go में इसका मतलब है कि यदि कोई फंक्शन एक इंटरफेस स्वीकार करता है, तो उस इंटरफेस का कोई भी कार्यान्वयन सही ढंग से काम करना चाहिए, बिना अपेक्षाओं का उल्लंघन किए।
\n\nखराब उदाहरण (LSP का उल्लंघन):
\ntype Bird interface {\n Fly() error\n}\n\nt 
