Swift में SOLID सिद्धांत: A से Z तक सिद्धांत और व्यवहार

परिचय: क्यों SOLID गुणवत्तापूर्ण Swift कोड की नींव है

प्रत्येक iOS/macOS डेवलपर को देर-सबेर ऐसी स्थिति का सामना करना पड़ता है जब कोड "स्पेगेटी" बन जाता है: एक जगह बदलाव पूरे एप्लिकेशन को तोड़ देता है, और परीक्षण एक बुरा सपना बन जाता है। यहीं पर SOLID सिद्धांत मदद करते हैं - रॉबर्ट मार्टिन द्वारा प्रतिपादित ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के पाँच मौलिक नियम।

इस लेख में, हम Swift उदाहरणों के साथ प्रत्येक SOLID सिद्धांत का विश्लेषण करेंगे, दिखाएंगे कि उनका उल्लंघन कैसे समस्याएँ पैदा करता है, और तैयार समाधान देंगे। आप ऐसा कोड लिखना सीखेंगे जिसे बनाए रखना, विस्तारित करना और परीक्षण करना आसान हो।

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

सिद्धांत

SRP कहता है: एक क्लास में बदलाव का केवल एक ही कारण होना चाहिए। दूसरे शब्दों में, प्रत्येक क्लास ठीक एक कार्यक्षमता के लिए जिम्मेदार होती है।

SRP का उल्लंघन (खराब कोड)

class UserManager {    func createUser(name: String, email: String) {        // उपयोगकर्ता बनाना        saveToDatabase(user: User(name: name, email: email))        sendWelcomeEmail(to: email)        logEvent("User created: \\(name)")    }        private func saveToDatabase(user: User) { /* ... */ }    private func sendWelcomeEmail(to email: String) { /* ... */ }    private func logEvent(_ message: String) { /* ... */ }}

यहाँ UserManager निर्माण, सहेजने, ईमेल भेजने और लॉगिंग के लिए जिम्मेदार है - बदलाव के चार कारण।

सुधार (अच्छा कोड)

class UserService {    private let repository: UserRepository    private let emailService: EmailService    private let logger: Logger        init(repository: UserRepository, emailService: EmailService, logger: Logger) {        self.repository = repository        self.emailService = emailService        self.logger = logger    }        func createUser(name: String, email: String) {        let user = User(name: name, email: email)        repository.save(user)        emailService.sendWelcome(to: email)        logger.log("User created: \\(name)")    }}

class UserRepository {    func save(_ user: User) { /* केवल सहेजना */ }}class EmailService {    func sendWelcome(to email: String) { /* केवल भेजना */ }}class Logger {    func log(_ message: String) { /* केवल लॉगिंग */ }}

अब प्रत्येक क्लास की एक ही जिम्मेदारी है, जिससे परीक्षण और रखरखाव आसान हो जाता है।

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

सिद्धांत

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

OCP का उल्लंघन

class PaymentProcessor {    func process(payment: Any, type: String) {        if type == "card" {            // कार्ड प्रोसेसिंग        } else if type == "paypal" {            // PayPal प्रोसेसिंग        } // नया प्रकार जोड़ने पर — इस क्लास को बदलना होगा    }}

प्रोटोकॉल के माध्यम से सुधार

protocol PaymentMethod {    func process(amount: Double)}

class CardPayment: PaymentMethod {    func process(amount: Double) { /* कार्ड प्रोसेसिंग */ }}

class PayPalPayment: PaymentMethod {    func process(amount: Double) { /* PayPal प्रोसेसिंग */ }}

class PaymentProcessor {    func process(payment: PaymentMethod, amount: Double) {        payment.process(amount: amount)    }}

// मौजूदा कोड को बदले बिना नया प्रकार जोड़नाclass ApplePayPayment: PaymentMethod {    func process(amount: Double) { /* Apple Pay प्रोसेसिंग */ }}

अब भुगतान का नया तरीका जोड़ने के लिए, बस PaymentMethod प्रोटोकॉल को लागू करने वाली एक नई क्लास बनानी होगी।

3.