SOLID: सिद्धांत, OOP के 5 नियम और डेवलपमेंट में अनुप्रयोग

SOLID क्या है? पांच सिद्धांतों का अवलोकन

SOLID — एक स्मरणीय संक्षिप्त नाम जो ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के पांच सिद्धांतों को दर्शाता है। यह शब्द Robert C. Martin द्वारा लेख «Design Principles and Design Patterns» (2000) में पेश किया गया और बाद में पुस्तक «Agile Software Development: Principles, Patterns, and Practices» (2002) में लोकप्रिय हुआ। SOLID कोई फ्रेमवर्क या लाइब्रेरी नहीं है — यह प्रथाओं का एक सेट है जो कोड को कम युग्मित, अधिक परीक्षण योग्य और बदलने में आसान बनाता है।

Clean Coder Blog, 2014 के अनुसार, प्रत्येक SOLID सिद्धांत एक विशिष्ट डिज़ाइन समस्या का समाधान करता है: SRP God वर्गों से लड़ता है, OCP कैस्केडिंग परिवर्तनों को रोकता है, LSP गलत विरासत से बचाता है, ISP बड़े इंटरफेस से बचाता है, और DIP कठोर युग्मन को कम करता है। साथ मिलकर वे Clean Architecture की नींव बनाते हैं, जिसका उपयोग Android प्रोजेक्ट्स में MVP, MVVM और MVI के साथ किया जाता है।

SRP: एकल जिम्मेदारी सिद्धांत

Single Responsibility Principle (SRP) — एकल जिम्मेदारी का सिद्धांत। सूत्रीकरण: «एक वर्ग में बदलाव का केवल एक कारण होना चाहिए»। इसका मतलब है कि प्रत्येक मॉड्यूल या वर्ग ठीक एक कार्यक्षमता या एक डोमेन इकाई के लिए जिम्मेदार है। यदि कोई वर्ग उपयोगकर्ताओं और ईमेल भेजने दोनों का प्रबंधन करता है — तो उसके पास बदलाव के दो कारण हैं, जो SRP का उल्लंघन करता है।

Robert C. Martin, 2002 के अनुसार, SRP सबसे महत्वपूर्ण और साथ ही सबसे अधिक उल्लंघन किया जाने वाला सिद्धांत है। मोबाइल डेवलपमेंट में, SRP का उल्लंघन अक्सर Activity/Fragment में UI लॉजिक, नेविगेशन, नेटवर्किंग और व्यावसायिक लॉजिक को मिलाकर किया जाता है। समाधान प्रत्येक परत को एक अलग वर्ग में निकालना है: UI लॉजिक के लिए ViewModel, डेटा के लिए Repository, नेविगेशन के लिए NavController।

SRP उदाहरण: UserManager का विभाजन

UserManager वर्ग पर विचार करें, जो प्रोफ़ाइल लोड करता है, सेटिंग्स सहेजता है और ईमेल भेजता है। ये तीन अलग-अलग जिम्मेदारियाँ हैं, जिनमें से प्रत्येक को एक अलग वर्ग में निकाला जाना चाहिए: UserProfileRepository (लोड करना), UserSettingsStorage (सहेजना) और EmailService (भेजना)। क्लाइंट कोड (ViewModel) Dependency Injection के माध्यम से तीनों का उपयोग करता है, और प्रत्येक वर्ग अलग-अलग आसानी से परीक्षण योग्य होता है और दूसरों को प्रभावित किए बिना बदला जा सकता है।

// ❌ SRP उल्लंघन: Activity नेटवर्क, DB और UI के बारे में जानती है
class ProfileActivity : AppCompatActivity() {
    fun loadProfile() {
        api.getUser() // नेटवर्क कॉल
        db.saveUser()    // DB संचालन
        updateUI()         // UI अपडेट
    }
}

// ✅ SRP पालन: परतें अलग की गई हैं
class ProfileViewModel : ViewModel() {
    private val repo = UserRepository()
    fun loadProfile() { repo.getUser() }
}

SRP उल्लंघन के संकेत: एक वर्ग 200 पंक्तियों से अधिक, विभिन्न डोमेन की विधियाँ, विभिन्न कारणों से बार-बार परिवर्तन। Android डेवलपमेंट के लिए, नियम सरल है: Activity केवल स्क्रीन जीवनचक्र को संभालती है, ViewModel UI स्थिति को संभालता है, Repository डेटा स्रोतों को संभालता है।

SRP और माइक्रोसर्विस आर्किटेक्चर

SRP सिद्धांत न केवल वर्गों पर बल्कि सेवा-स्तरीय आर्किटेक्चर पर भी लागू होता है। प्रत्येक माइक्रोसर्विस एक डोमेन इकाई को संभालता है: UserService — केवल उपयोगकर्ता, PaymentService — केवल भुगतान, NotificationService — केवल सूचनाएँ। यह सेवाओं के स्वतंत्र स्केलिंग, डिप्लॉयमेंट और परीक्षण को सक्षम बनाता है। मोबाइल ऐप्लिकेशन में, माइक्रोसर्विस स्तर पर SRP API क्लाइंट को डोमेन के अनुसार अलग करने में प्रकट होता है।

OCP: खुला/बंद सिद्धांत

Open-Closed Principle (OCP) — वर्ग विस्तार के लिए खुले होने चाहिए (नया व्यवहार जोड़ा जा सकता है) और संशोधन के लिए बंद (मौजूदा कोड नहीं बदला जाता)। यह बहुरूपता, सार वर्गों और इंटरफेस के माध्यम से प्राप्त किया जाता है। किसी मौजूदा विधि में if-else जोड़ने के बजाय, एक नया इंटरफेस कार्यान्वयन बनाया जाता है।

Clean Coder Blog, 2014 के अनुसार, OCP Strategy पैटर्न के साथ सबसे अच्छा काम करता है। उदाहरण के लिए, यदि कोई ऐप विभिन्न भुगतान विधियों (Google Pay, Apple Pay, PayPal) का समर्थन करता है, तो भुगतान प्रोसेसर में switch-case जोड़ने की आवश्यकता नहीं है। प्रत्येक भुगतान विधि एक सामान्य PaymentGateway इंटरफेस को लागू करती है, और मौजूदा कोड को बदले बिना एक नया भुगतान सिस्टम एक नए वर्ग के रूप में जोड़ा जाता है।

// ✅ OCP: विस्तार के लिए खुला, संशोधन के लिए बंद
interface PaymentGateway {
    fun processPayment(amount: Double): Boolean
}

class GooglePayGateway : PaymentGateway {
    override fun processPayment(amount: Double) = true
}

// नया भुगतान सिस्टम — मौजूदा कोड बदले बिना
class ApplePayGateway : PaymentGateway {
    override fun processPayment(amount: Double) = true
}

LSP: लिस्कोव प्रतिस्थापन सिद्धांत

Liskov Substitution Principle (LSP) — Barbara Liskov का प्रतिस्थापन सिद्धांत। यदि S, T का उपप्रकार है, तो T प्रकार की वस्तुओं को S प्रकार की वस्तुओं से प्रोग्राम गुणों को बदले बिना प्रतिस्थापित किया जा सकता है। औपचारिक रूप से: आधार वर्ग का उपयोग करने वाला फ़ंक्शन उसके किसी भी उपवर्ग के साथ सही ढंग से काम करना चाहिए। यदि कोई उपवर्ग वहाँ अपवाद फेंकता है जहाँ आधार वर्ग नहीं फेंकता — LSP का उल्लंघन है।

Robert C. Martin, 2002 के अनुसार, LSP SOLID सिद्धांतों में सबसे कठिन है। उल्लंघन का क्लासिक उदाहरण Square वर्ग है जो Rectangle से विरासत प्राप्त करता है। यदि Square पर setWidth चौड़ाई और ऊँचाई दोनों सेट करता है, तो Rectangle व्यवहार की अपेक्षा करने वाला क्लाइंट कोड अप्रत्याशित परिणाम प्राप्त करता है। मोबाइल डेवलपमेंट में, LSP का उल्लंघन अक्सर ViewModel की विरासत में होता है — जब कोई चाइल्ड ViewModel अनिवार्य निर्भरताएँ जोड़ता है।

// ❌ LSP उल्लंघन: Square Rectangle के व्यवहार को तोड़ता है
open class Rectangle(open var width: Int, open var height: Int)

class Square(side: Int) : Rectangle(side, side) {
    override var width
        get() = super.width
        set(value) { super.setBoth(value, value) }
}

ISP: इंटरफेस पृथक्करण सिद्धांत

Interface Segregation Principle (ISP) — क्लाइंट को उन इंटरफेस पर निर्भर नहीं होना चाहिए जिनका वे उपयोग नहीं करते। एक «मोटे» इंटरफेस के बजाय, कई संकीर्ण विशिष्ट इंटरफेस बनाएँ। यदि कोई वर्ग किसी इंटरफेस को लागू करता है लेकिन कुछ विधियाँ UnsupportedOperationException फेंकती हैं या खाली रहती हैं — यह ISP उल्लंघन का स्पष्ट संकेत है।

DigitalOcean, 2024 के अनुसार, ISP ViewModel और Repository डिज़ाइन करते समय मोबाइल डेवलपमेंट में विशेष रूप से प्रासंगिक है। सभी CRUD विधियों वाले एकल UserRepository इंटरफेस के बजाय, QueryUserRepository (केवल पढ़ना) और CommandUserRepository (लिखना) बनाना बेहतर है। तब केवल पढ़ने वाला क्लाइंट (UI तत्व) केवल Query इंटरफेस पर निर्भर होता है और लिखने की विधियों के बारे में कुछ नहीं जानता।

// ❌ मोटा इंटरफेस — क्लाइंट अनावश्यक विधियों को लागू करने के लिए मजबूर
interface UserOperations {
    fun getUser(id: String): User
    fun saveUser(user: User)
    fun deleteUser(id: String)
    fun exportUsers(): File
}

// ✅ ISP: अलग किए गए इंटरफेस
interface UserReader { fun getUser(id: String): User }
interface UserWriter { fun saveUser(user: User) }
interface UserDeleter { fun deleteUser(id: String) }

DIP: निर्भरता उलटाव सिद्धांत

Dependency Inversion Principle (DIP) — उच्च-स्तरीय मॉड्यूल को निम्न-स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों को एब्स्ट्रैक्शन (इंटरफेस) पर निर्भर होना चाहिए। एब्स्ट्रैक्शन को विवरण पर निर्भर नहीं होना चाहिए — विवरण को एब्स्ट्रैक्शन पर निर्भर होना चाहिए। यह «Dependency Injection» (DI) नहीं है, हालाँकि DI, DIP को लागू करने का एक सामान्य तरीका है।

Robert C. Martin, 2019 के अनुसार, DIP Clean Architecture की नींव है। ViewModel (उच्च-स्तरीय) को सीधे RetrofitApi (विवरण) का उदाहरण नहीं बनाना चाहिए। इसके बजाय, ViewModel UserRepository इंटरफेस पर निर्भर होता है, और Retrofit के साथ ठोस UserRepositoryImpl कंस्ट्रक्टर के माध्यम से पास किया जाता है। Android में, DIP को Hilt/Dagger या Koin के माध्यम से लागू किया जाता है: सभी निर्भरताएँ DI कंटेनर के माध्यम से प्रदान की जाती हैं।

// ✅ DIP: Module एब्स्ट्रैक्शन पर निर्भर करता है, विवरण पर नहीं
class UserRepositoryImpl(
    private val api: UserApi,   // इंटरफेस पर निर्भर
    private val db: UserDao     // इंटरफेस पर निर्भर
) : UserRepository {

    override suspend fun getUser(id: String): User {
        return api.fetchUser(id)
    }
}

// Hilt DI: विवरण DI मॉड्यूल के माध्यम से जुड़े हैं
@Module
object NetworkModule {
    @Provides
    fun provideUserApi(retrofit: Retrofit): UserApi =
        retrofit.create(UserApi::class.java)
}

मोबाइल डेवलपमेंट में SOLID का अनुप्रयोग

मोबाइल डेवलपमेंट में SOLID सभी स्तरों पर लागू होता है: एप्लिकेशन आर्किटेक्चर से लेकर व्यक्तिगत वर्गों तक। Android प्रोजेक्ट्स में, Clean Architecture कोड को तीन परतों में विभाजित करती है: domain (व्यावसायिक लॉजिक — फ्रेमवर्क से स्वतंत्र), data (रिपॉजिटरी, API, DB) और presentation (UI, ViewModel)। Domain परत SOLID सिद्धांतों का उपयोग करती है: उपयोग केस (SRP), रिपॉजिटरी इंटरफेस (DIP), एंटिटी वर्ग (OCP + LSP)।

Android Developers Guide, 2025 के अनुसार, Android में SRP ViewModel, Repository और Mapper को अलग करने में प्रकट होता है। OCP — DataSource इंटरफेस के माध्यम से नए डेटा स्रोत जोड़ते समय। LSP — विभिन्न रिपॉजिटरी में एकसमान Result हैंडलिंग में। ISP — CQRS दृष्टिकोण में (पढ़ने/लिखने वाली रिपॉजिटरी को अलग करना)। DIP — निर्भरता इंजेक्शन के लिए Hilt/Koin के माध्यम से।

SOLID लागू करते समय सामान्य गलतियाँ

SOLID गलतियाँ अक्सर कोड के अत्यधिक जटिलीकरण से संबंधित होती हैं। पहली — संदर्भ पर विचार किए बिना सिद्धांतों का शाब्दिक पालन करना। सिर्फ «स्वच्छ» ISP के लिए एक UserService वर्ग को 10 इंटरफेस और 15 वर्गों में विभाजित करना ओवरइंजीनियरिंग है। SOLID एक उपकरण है, लक्ष्य नहीं। दूसरी गलती — SRP को «एक विधि = एक जिम्मेदारी» समझना। एक वर्ग में कई विधियाँ हो सकती हैं यदि वे सभी जिम्मेदारी के एक ही क्षेत्र से संबंधित हों।

Simple Thread, 2024 के अनुसार, तीसरी गलती — Android में ViewModel की विरासत में LSP की अनदेखी करना। यदि आधार ViewModel LiveData की अपेक्षा करता है लेकिन चाइल्ड StateFlow का उपयोग करता है — LiveData पर सब्सक्राइब किया गया क्लाइंट कोड अपडेट प्राप्त नहीं करेगा। चौथी — परीक्षण के लिए DIP का उल्लंघन: RepositoryImpl सीधे OkHttpClient का उदाहरण बनाता है, जिससे यूनिट परीक्षण असंभव हो जाता है।

सुनहरे नियम: SOLID तब लागू करें जब यह किसी वास्तविक समस्या (बार-बार बदलाव, परीक्षण कठिनाई, दोहराव) का समाधान करता हो। सरल CRUD स्क्रीन के लिए, सभी पाँच सिद्धांतों का सख्त पालन अत्यधिक है। व्यावसायिक लॉजिक, वित्तीय गणनाओं और API इंटरैक्शन के लिए, SOLID आवश्यक है।

SOLID और Clean Architecture संबंध

Clean Architecture (Robert C. Martin, 2012) — एप्लिकेशन परत स्तर पर SOLID का प्रत्यक्ष अनुप्रयोग। SRP उपयोग केस सीमाएँ निर्धारित करता है (प्रत्येक उपयोग केस — एक वर्ग)। OCP रिपॉजिटरी इंटरफेस के माध्यम से लागू किया जाता है (Data Layer Domain को संशोधित किए बिना बदल सकता है)। ISP उपयोग केस को इनपुट/आउटपुट सीमाओं में पृथक्करण प्रदान करता है। DIP — निर्भरता की दिशा Domain परत के अंदर की ओर। LSP गारंटी देता है कि कोई भी रिपॉजिटरी कार्यान्वयन उपयोग केस को तोड़े बिना बदला जा सकता है।