HI
RU
EN
ES
ZH
FR
DE
PT
AR
Kotlin में SOLID सिद्धांत: उन्नत स्तर पर सिद्धांत और अभ्यास
\n\nSOLID ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के सिद्धांतों का एक मूलभूत सेट है, जिसे रॉबर्ट मार्टिन द्वारा प्रस्तुत किया गया था। Kotlin के संदर्भ में, जो OOP और फंक्शनल प्रोग्रामिंग की सर्वोत्तम विशेषताओं को जोड़ता है, ये सिद्धांत कार्यान्वयन के लिए नई संभावनाएँ प्राप्त करते हैं। इस लेख में, हम भाषा की अनूठी क्षमताओं: इनलाइन-फ़ंक्शन, डेलिगेशन, सील्ड-क्लासेस और एक्सटेंशन-फ़ंक्शन का उपयोग करके प्रत्येक सिद्धांत को उन्नत स्तर पर देखेंगे।
\n\n1. Single Responsibility Principle (SRP) और डेलिगेशन
\n\nएकल उत्तरदायित्व का सिद्धांत कहता है: एक क्लास में बदलाव का केवल एक ही कारण होना चाहिए। Kotlin में SRP का पालन करने के लिए अक्सर डेलिगेशन (Delegation) पैटर्न का उपयोग किया जाता है। कीवर्ड by किसी इंटरफ़ेस के कार्यान्वयन को स्वचालित रूप से किसी अन्य ऑब्जेक्ट को सौंपने की अनुमति देता है।
समस्या: क्लास UserService व्यावसायिक तर्क, लॉगिंग और ईमेल भेजने दोनों के लिए जिम्मेदार है।
// ❌ SRP का उल्लंघन\nclass UserService {\n fun registerUser(email: String, password: String) {\n // व्यावसायिक तर्क\n println("User registered")\n // लॉगिंग\n log("User registered: $email")\n // ईमेल भेजना\n sendEmail(email, "Welcome!")\n }\n\n private fun log(message: String) { /* ... */ }\n private fun sendEmail(to: String, body: String) { /* ... */ }\n}\nडेलिगेशन का उपयोग कर समाधान:
\n\n// ✅ डेलिगेशन के माध्यम से SRP का पालन\ninterface Logger {\n fun log(message: String)\n}\n\ninterface EmailSender {\n fun send(to: String, body: String)\n}\n\nclass ConsoleLogger : Logger {\n override fun log(message: String) = println("LOG: $message")\n}\n\nclass SmtpEmailSender : EmailSender {\n override fun send(to: String, body: String) = println("Sending email to $to: $body")\n}\n\nclass UserService(\n private val logger: Logger,\n private val emailSender: EmailSender\n) : Logger by logger, EmailSender by emailSender { // 👈 डेलिगेशन\n\n fun registerUser(email: String, password: String) {\n println("User registered")\n log("User registered: $email")\n send(email, "Welcome!")\n }\n}\n\n// उपयोग\nfun main() {\n val service = UserService(ConsoleLogger(), SmtpEmailSender())\n service.registerUser("user@example.com", "pass123")\n}\nby का उपयोग बॉयलरप्लेट कोड से बचने और जिम्मेदारियों को स्पष्ट रूप से अलग करने की अनुमति देता है। क्लास UserService अब केवल पंजीकरण के लिए जिम्मेदार है, जबकि लॉगिंग और भेजना अलग-अलग क्लासेस को सौंपा गया है।
2. Open-Closed Principle (OCP) और सील्ड-क्लासेस
\n\nखुले/बंद का सिद्धांत: क्लासेस विस्तार के लिए खुले होने चाहिए, लेकिन संशोधन के लिए बंद होने चाहिए। Kotlin में इसके लिए सील्ड-क्लासेस और एक्सटेंशन-फ़ंक्शन आदर्श रूप से उपयुक्त हैं।
\n\nसमस्या: फ़ंक्शन processPayment प्रकार की जाँच के साथ when का उपयोग करता है, और भुगतान का एक नया तरीका जोड़ने पर इसे संशोधित करना पड़ता है।
// ❌ OCP का उल्लंघन\nfun processPayment(type: String, amount: Double) {\n when (type) {\n "card" -> println("Processing card payment: $amount")\n "paypal" -> println("Processing PayPal payment: $amount")\n else -> throw IllegalArgumentException("Unknown payment type")\n }\n}\nसील्ड-क्लासेस के साथ समाधान:
\n\n// ✅ OCP का पालन\nsealed class PaymentMethod {\n data class Card(val number: String, val cvv: String) : PaymentMethod()\n data class PayPal(val email: String) : PaymentMethod()\n object Cash : PaymentMethod()\n}\n\n// फ़ंक्शन संशोधन के लिए बंद है\nfun processPayment(method: PaymentMethod, amount: Double) {\n // जब नए उपवर्ग दिखाई देंगे, कंपाइलर उनके प्रसंस्करण की मांग करेगा\n 
