मोबाइल डेवलपमेंट में आर्किटेक्चर सिद्धांत: ये क्या हैं, कितने प्रकार के हैं और कैसे लागू करें

SOLID सिद्धांत

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

आइए प्रत्येक सिद्धांत की जाँच करें। Single Responsibility Principle (SRP) — प्रत्येक वर्ग में बदलाव का केवल एक ही कारण होना चाहिए। Open/Closed Principle (OCP) — वर्ग विस्तार के लिए खुले हैं लेकिन संशोधन के लिए बंद हैं। Liskov Substitution Principle (LSP) — उपप्रकार की वस्तुओं को तर्क को तोड़े बिना आधार प्रकार की वस्तुओं को प्रतिस्थापित करना चाहिए। Interface Segregation Principle (ISP) — कई विशिष्ट इंटरफ़ेस एक सामान्य इंटरफ़ेस से बेहतर हैं। Dependency Inversion Principle (DIP) — ठोस कार्यान्वयन पर नहीं, बल्कि अमूर्तताओं पर निर्भर रहें।

SonarQube विश्लेषण (2025) के अनुसार, SOLID सिद्धांतों का उल्लंघन 68% वाणिज्यिक प्रोजेक्ट्स में होता है। सबसे आम समस्याएँ SRP उल्लंघन (35%) और ISP उल्लंघन (22%) हैं। IT Sectr में, हम आर्किटेक्चर समीक्षा चरण में SOLID लागू करते हैं — इससे समस्याओं को तकनीकी ऋण में बदलने से पहले पहचानने में मदद मिलती है।

Single Responsibility Principle (SRP)

SRP (एकल जिम्मेदारी का सिद्धांत) — सबसे महत्वपूर्ण और साथ ही सबसे अधिक बार उल्लंघन किया जाने वाला SOLID सिद्धांत। यह कहता है: एक वर्ग में बदलाव का केवल एक ही कारण होना चाहिए। यदि एक वर्ग बहुत अधिक करता है, तो इसका परीक्षण, संशोधन और समझना कठिन होता है।

एक सामान्य उल्लंघन एक वर्ग है जो एक साथ डेटा संसाधित करता है, उसे डेटाबेस में सहेजता है और ईमेल सूचनाएँ भेजता है। नीचे दिया गया उदाहरण Kotlin में SRP उल्लंघन दिखाता है और इसे कैसे ठीक किया जाए।

// SRP उल्लंघन — वर्ग तीन अलग-अलग काम करता है
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. डेटा सत्यापन
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. डेटाबेस में सहेजें
        val user = User(email, name)
        database.save(user)
        
        // 3. सूचना भेजें
        emailService.sendWelcomeEmail(email, name)
    }
}

// सुधार — तीन वर्गों में विभाजन
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

सुधारे गए संस्करण में, प्रत्येक वर्ग अपने कार्य के लिए जिम्मेदार है: UserValidator — सत्यापन के लिए, UserRepository — सहेजने के लिए, NotificationService — सूचनाओं के लिए। यह कोड को परीक्षण योग्य और पुन: प्रयोज्य बनाता है — आप सत्यापन तर्क को बदले बिना डेटाबेस कार्यान्वयन को बदल सकते हैं।

GRASP और Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — वस्तुओं के बीच जिम्मेदारी वितरण के नौ आर्किटेक्चर सिद्धांत, क्रेग लारमैन द्वारा वर्णित। SOLID के विपरीत, GRASP इस प्रश्न का उत्तर देता है «किस वर्ग में यह विधि होनी चाहिए?»। मुख्य पैटर्न: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, न्यूनतम युग्मन का सिद्धांत) — एक सरल नियम: एक वस्तु को केवल अपने तत्काल पड़ोसियों के साथ संवाद करना चाहिए। a.getB().getC().doSomething() नहीं लिखना चाहिए — यह वर्गों के बीच मजबूत युग्मन बनाता है। LoD पुन: प्रयोज्यता में सुधार करता है और परीक्षण को सरल बनाता है।

IT Sectr में, हम कोड समीक्षा के दौरान LoD अनुपालन की जाँच करते हैं। यदि कोई विधि तीन या अधिक वस्तुओं से «गुज़रती» है, तो यह संकेत है कि आर्किटेक्चर को सरल बनाने की आवश्यकता है। LoD का उल्लंघन बड़े प्रोजेक्ट्स में सबसे आम Code Smell में से एक है।

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) और YAGNI (You Ain't Gonna Need It) — तीन बुनियादी आर्किटेक्चर सिद्धांत जो हर डेवलपर को ज्ञात हैं। अपनी सरलता के बावजूद, इनका उल्लंघन लगातार होता रहता है।

DRY — कोड दोहराएँ नहीं। यदि एक ही तर्क दो स्थानों पर दिखाई देता है, तो इसे एक सामान्य विधि या वर्ग में निकालें। दोहराव बग का मुख्य स्रोत है: एक स्थान पर सुधार दूसरे स्थान पर लागू करना भूल जाते हैं। DRY का मतलब यह नहीं है कि समान कोड नहीं हो सकता — महत्वपूर्ण यह है कि व्यावसायिक तर्क दोहराया न जाए।

KISS — जितना सरल, उतना बेहतर। कई अमूर्तताओं और वंशानुक्रमों वाले जटिल समाधान अक्सर अत्यधिक होते हैं। एक सरल समाधान से शुरू करें और केवल आवश्यकता होने पर इसे जटिल बनाएँ। YAGNI — उस कार्यक्षमता के लिए कोड न लिखें जिसकी «कभी बाद में» आवश्यकता हो सकती है। इससे कोडबेस फूल जाता है और रखरखाव जटिलता बढ़ जाती है।

DRY — Don't Repeat Yourself

DRY — यह सिर्फ कॉपी-पेस्ट की अनुपस्थिति नहीं है। यह एक सिद्धांत है जिसके अनुसार ज्ञान या तर्क के प्रत्येक टुकड़े का सिस्टम में एक एकल, स्पष्ट प्रतिनिधित्व होना चाहिए। दोहराव स्पष्ट (कॉपी किया गया कोड) और अंतर्निहित (विभिन्न परतों में समान तर्क) हो सकता है।

IT Sectr में, हम दोहराव का पता लगाने के लिए कोड विश्लेषण मीट्रिक का उपयोग करते हैं। SonarQube और Detekt जैसे उपकरण दोहराए गए कोड का प्रतिशत दिखाते हैं। 5% से अधिक मान रिफैक्टरिंग का कारण है। हालांकि, यह याद रखना महत्वपूर्ण है: DRY को गलत अमूर्तताओं की कीमत पर हासिल नहीं किया जाना चाहिए — कभी-कभी समान कोड के दो टुकड़ों को वैसे ही छोड़ देना बेहतर होता है यदि उन्हें संयोजित करने से समझना जटिल हो जाए।

Separation of Concerns और Modularity

Separation of Concerns (SoC) — एक आर्किटेक्चर सिद्धांत जहाँ सिस्टम को स्वतंत्र भागों (concerns) में विभाजित किया जाता है, प्रत्येक अपने कार्य को हल करता है। एक क्लासिक उदाहरण परतों में विभाजन है: प्रस्तुति, व्यावसायिक तर्क, डेटा एक्सेस। प्रत्येक परत केवल अपने नीचे वाली परत पर निर्भर करती है।

Modularity (मॉड्यूलरिटी) — वह डिग्री जिस तक सिस्टम को मॉड्यूल में विभाजित किया जा सकता है। मॉड्यूल एक अच्छी तरह से परिभाषित इंटरफ़ेस के साथ तार्किक रूप से संबंधित वर्गों का एक समूह है। मॉड्यूल शिथिल रूप से युग्मित (low coupling) और दृढ़ता से सामंजस्यपूर्ण (high cohesion) होने चाहिए।

Cohesion vs Coupling

Cohesion (सामंजस्य) — एक माप कि एक ही मॉड्यूल के भीतर तत्व एक-दूसरे से कितने संबंधित हैं। उच्च सामंजस्य अच्छा है: एक वर्ग एक काम करता है और उसे अच्छी तरह करता है। Low coupling (निम्न युग्मन) — एक माप कि मॉड्यूल एक-दूसरे से कितने स्वतंत्र हैं। निम्न युग्मन अच्छा है: एक मॉड्यूल में बदलाव दूसरे को नहीं तोड़ता।

आदर्श आर्किटेक्चर उच्च सामंजस्य और निम्न युग्मन है। व्यवहार में, इसका मतलब है: एक वर्ग में ऐसी विधियाँ होती हैं जो समान डेटा पर काम करती हैं (सामंजस्य), और केवल अमूर्तताओं पर निर्भर करती हैं, ठोस कार्यान्वयन पर नहीं (युग्मन)। असंतुलन «गॉड ऑब्जेक्ट» या «स्पेगेटी कोड» की ओर ले जाता है।

तकनीकी ऋण और Code Smell

तकनीकी ऋण (Technical Debt) — वार्ड कनिंघम द्वारा प्रस्तुत एक रूपक जो «ब्याज» का वर्णन करता है जो टीम उप-इष्टतम आर्किटेक्चर निर्णयों और आर्किटेक्चर सिद्धांतों के उल्लंघन के लिए चुकाती है। वित्तीय ऋण की तरह, तकनीकी ऋण जानबूझकर (हमने जल्दी करने का फैसला किया, बाद में फिर से करेंगे) और अनजाने (अनुभव की कमी के कारण खराब आर्किटेक्चर) हो सकता है।

Code Smell — कोड में गहरी समस्याओं के सतही संकेत। यह शब्द मार्टिन फाउलर ने अपनी पुस्तक «Refactoring» में लोकप्रिय बनाया। विशिष्ट Code Smell: लंबी विधियाँ, बड़े वर्ग, लंबी कॉल श्रृंखलाएँ, कोड दोहराव, टिप्पणियों का अत्यधिक उपयोग (स्पष्ट कोड के बजाय)।

IT Sectr में, तकनीकी ऋण को Jira में अलग-अलग कार्यों के रूप में ट्रैक किया जाता है। प्रत्येक स्प्रिंट में, हम रिफैक्टरिंग और ऋण चुकाने के लिए 20% समय आवंटित करते हैं। तकनीकी ऋण के साथ व्यवस्थित कार्य एकमात्र तरीका है जिससे उस स्थिति से बचा जा सकता है जहाँ एक नई सुविधा जोड़ने में उसे शुरू से विकसित करने से अधिक समय लगता है।