Swift में SOLID सिद्धांत: सिद्धांत और व्यवहारिक गाइड

Swift में SOLID सिद्धांतों का परिचय

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

चाहे आप UIKit, SwiftUI या AppKit में लिख रहे हों, SOLID एक सार्वभौमिक नींव है। आइए विवरण में गोता लगाएँ।

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

सिद्धांत

एक क्लास में बदलाव का केवल एक ही कारण होना चाहिए। दूसरे शब्दों में, प्रत्येक मॉड्यूल सिर्फ एक कार्यक्षमता के लिए जिम्मेदार होता है। यदि आपका ViewController UI को मैनेज करता है, नेटवर्क रिक्वेस्ट को हैंडल करता है और JSON को पार्स करता है — तो यह SRP का उल्लंघन कर रहा है।

Swift में व्यवहारिक उदाहरण

आइए एक सामान्य उदाहरण देखें — यूज़र डेटा लोड करना और प्रदर्शित करना।

// ❌ खराब: SRP का उल्लंघन\nclass UserViewController: UIViewController {\n    func loadUser() {\n        // नेटवर्क रिक्वेस्ट\n        let url = URL(string: "https://api.example.com/user")!\n        URLSession.shared.dataTask(with: url) { data, _, _ in\n            let user = try? JSONDecoder().decode(User.self, from: data!)\n            DispatchQueue.main.async {\n                self.updateUI(with: user)\n            }\n        }.resume()\n    }\n    \n    func updateUI(with user: User?) {\n        // UI अपडेट\n    }\n}

// ✅ अच्छा: जिम्मेदारी को अलग करना\nclass UserService {\n    func fetchUser(completion: @escaping (User?) -> Void) {\n        let url = URL(string: "https://api.example.com/user")!\n        URLSession.shared.dataTask(with: url) { data, _, _ in\n            let user = try? JSONDecoder().decode(User.self, from: data!)\n            completion(user)\n        }.resume()\n    }\n}\n\nclass UserViewController: UIViewController {\n    let userService = UserService()\n    \n    func loadUser() {\n        userService.fetchUser { [weak self] user in\n            DispatchQueue.main.async {\n                self?.updateUI(with: user)\n            }\n        }\n    }\n    \n    private func updateUI(with user: User?) {\n        // UI अपडेट\n    }\n}

निष्कर्ष: अब UserService सिर्फ नेटवर्क के लिए जिम्मेदार है, और UserViewController सिर्फ UI के लिए। नेटवर्क लॉजिक में बदलाव कंट्रोलर को प्रभावित नहीं करता।

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

सिद्धांत

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

Swift में व्यवहारिक उदाहरण

मान लीजिए हम एक ऑनलाइन स्टोर के लिए डिस्काउंट कैलकुलेटर मॉड्यूल लिख रहे हैं।

// ❌ खराब: नई डिस्काउंट जोड़ने पर क्लास को बदलना होगा\nclass DiscountCalculator {\n    func calculate(price: Double, type: String) -> Double {\n        if type == "seasonal" {\n            return price * 0.9\n        } else if type == "loyalty" {\n            return price * 0.85\n        }\n        return price\n    }\n}

// ✅ अच्छा: विस्तार के लिए प्रोटोकॉल का उपयोग\nprotocol DiscountStrategy {\n    func applyDiscount(to price: Double) -> Double\n}\n\nstruct SeasonalDiscount: DiscountStrategy {\n    func applyDiscount(to price: Double) -> Double {\n        price * 0.9\n    }\n}\n\nstruct LoyaltyDiscount: DiscountStrategy {\n    func applyDiscount(to price: Double) -> Double {\n        price * 0.85\n    }\n}\n\nclass DiscountCalculator {\n    func calculate(price: Double, strategy: DiscountStrategy) -> Double {\n        strategy.applyDiscount(to: price)\n    }\n}

निष्कर्ष: अब नई डिस्काउंट रणनीति जोड़ने के लिए बस एक नया स्ट्रक्ट बनाएँ जो DiscountStrategy प्रोटोकॉल को फॉलो करे। मौजूदा कोड में कोई बदलाव नहीं।