ISP — यह क्या है, डेवलपमेंट में इंटरफ़ेस पृथक्करण सिद्धांत

ISP (Interface Segregation Principle) क्या है?

ISP (Interface Segregation Principle) इंटरफ़ेस पृथक्करण का सिद्धांत है जो सभी क्लाइंट द्वारा उपयोग न की जाने वाली विधियों वाले “मोटे” इंटरफ़ेस बनाने पर रोक लगाता है। एक इंटरफ़ेस में दर्जनों विधियों के बजाय, कई छोटे इंटरफ़ेस डिज़ाइन किए जाते हैं, प्रत्येक अपने क्लाइंट समूह के लिए।

यह सिद्धांत रॉबर्ट मार्टिन द्वारा “इंटरफ़ेस प्रदूषण” की समस्या के समाधान के रूप में प्रस्तुत किया गया था, जब एक वर्ग को उन विधियों को लागू करने के लिए मजबूर किया जाता है जिनकी उसे आवश्यकता नहीं है, सिर्फ इसलिए कि वे एक सामान्य इंटरफ़ेस में घोषित हैं। स्थैतिक रूप से टाइप की गई भाषाओं में, इसके परिणामस्वरूप खाली कार्यान्वयन या अपवाद फेंकना होता है — ISP उल्लंघन का सीधा संकेत।

ISP और SRP एक दूसरे के पूरक हैं: SRP वर्ग की जिम्मेदारी के बारे में है, ISP इंटरफ़ेस अनुबंधों के बारे में है। SRP कहता है “एक वर्ग — बदलाव का एक कारण”, ISP कहता है “एक इंटरफ़ेस — एक क्लाइंट परिदृश्य”। साथ में वे एक मॉड्यूलर आर्किटेक्चर बनाते हैं जहाँ सिस्टम के प्रत्येक तत्व की स्पष्ट सीमाएँ होती हैं।

मोटे इंटरफ़ेस और उनके परिणाम

Fat Interface — एक इंटरफ़ेस जिसमें किसी विशिष्ट क्लाइंट की आवश्यकता से अधिक विधियाँ होती हैं। उदाहरण के लिए, work, eat, sleep विधियों वाला Worker इंटरफ़ेस। एक रोबोट कर्मचारी को eat और sleep लागू नहीं करना चाहिए, लेकिन मजबूर किया जाता है। समाधान — Workable, Eatable, Sleepable में विभाजित करना। प्रत्येक क्लाइंट को वही मिलता है जो उसे चाहिए।

मोबाइल डेवलपमेंट में, मोटे इंटरफ़ेस डेलिगेट प्रोटोकॉल और DataSource में पाए जाते हैं। एक प्रोटोकॉल में दो अलग-अलग परिदृश्यों (संपादन + प्रदर्शन) के लिए विधियाँ हो सकती हैं, भले ही कोई विशिष्ट स्क्रीन उनमें से केवल एक का उपयोग करती हो।

इंटरफ़ेस पृथक्करण सिद्धांत कैसे काम करता है

ISP को लागू करना प्रत्येक इंटरफ़ेस के क्लाइंट का विश्लेषण करने से शुरू होता है। यदि दो क्लाइंट एक इंटरफ़ेस की विधियों के विभिन्न सेटों का उपयोग करते हैं — तो इंटरफ़ेस को विभाजित किया जाना चाहिए। प्रत्येक नया इंटरफ़ेस उन विधियों को समूहित करता है जो एक परिदृश्य के अंतर्गत एक साथ कॉल की जाती हैं।

विभाजन तंत्र: मूल इंटरफ़ेस को कई संकीर्ण इंटरफ़ेस में तोड़ा जाता है, प्रत्येक सामान्य भाग (यदि कोई हो) को इनहेरिट करता है। क्लाइंट सामान्य इंटरफ़ेस के बजाय आवश्यक संकीर्ण इंटरफ़ेस पर निर्भर हो जाते हैं। मूल इंटरफ़ेस को लागू करने वाले वर्ग अब केवल उन संकीर्ण इंटरफ़ेस को लागू करते हैं जिनकी उन्हें वास्तव में आवश्यकता है।

एक महत्वपूर्ण स्पष्टीकरण: विभाजन की डिग्री क्लाइंट की संख्या और उनके परिदृश्यों द्वारा निर्धारित की जाती है। ISP अधिकतम विभाजन (प्रत्येक में एक विधि वाले माइक्रो-इंटरफ़ेस) की आवश्यकता नहीं रखता। इससे अत्यधिक जटिलता होगी। लक्ष्य क्लाइंट की अनावश्यक विधियों पर निर्भरता को समाप्त करना है, न कि प्रत्येक इंटरफ़ेस के आकार को न्यूनतम करना।

ISP उल्लंघन के संकेत

ISP उल्लंघन के मुख्य संकेतों में शामिल हैं: खाली विधियों (नकली कार्यान्वयन) वाले इंटरफ़ेस को लागू करने वाले वर्ग, कार्यान्वयन में UnsupportedOperationException फेंकना, बड़ी संख्या में पैरामीटर या रिटर्न प्रकार जो कुछ क्लाइंट द्वारा उपयोग नहीं किए जाते, और इंटरफ़ेस में बार-बार बदलाव जो केवल कुछ क्लाइंट को प्रभावित करते हैं।

Android डेवलपमेंट में, ISP उल्लंघन का एक विशिष्ट उदाहरण OnItemClickListener इंटरफ़ेस है, जिसमें क्लिक, लॉन्ग क्लिक और स्वाइप के लिए विधियाँ शामिल हैं। यदि कोई विशिष्ट स्क्रीन केवल क्लिक का उपयोग करती है — तो शेष विधियाँ खाली रहती हैं। समाधान — OnItemClickListener, OnItemLongClickListener, OnItemSwipeListener में विभाजित करना।

iOS डेवलपमेंट में, ISP उल्लंघन UIKit डेलिगेट में प्रकट होता है: एक प्रोटोकॉल में विभिन्न घटक अवस्थाओं के लिए विधियाँ होती हैं। UITableViewDelegate में प्रदर्शन, चयन, संपादन और स्वाइप-एक्शन के लिए विधियाँ शामिल हैं। डेवलपर अक्सर दर्जनों खाली विधियों के साथ पूरे प्रोटोकॉल को लागू करते हैं। जिम्मेदारी समूहों द्वारा कई प्रोटोकॉल में विभाजन समस्या का समाधान करता है।

अप्रयुक्त विधियों पर निर्भरता

समस्या केवल कोड सौंदर्यशास्त्र की नहीं है। जब कोई इंटरफ़ेस बदलता है (एक नई विधि जोड़ी जाती है), सभी कार्यान्वित करने वाले वर्गों को अपडेट किया जाना चाहिए — यहाँ तक कि वे भी जिन्हें नई विधि की आवश्यकता नहीं है। दर्जनों स्क्रीन वाले मोबाइल डेवलपमेंट में, यह कैस्केडिंग परिवर्तनों की ओर ले जाता है। ISP प्रत्येक क्लाइंट को उन परिवर्तनों से अलग करता है जो उससे संबंधित नहीं हैं।

अंतर्निहित ISP उल्लंघन कॉन्फ़िगरेशन पैरामीटर के माध्यम से होता है। यदि कोई विधि कई फ़ील्ड वाली वस्तु स्वीकार करती है, और क्लाइंट उनमें से केवल 2-3 का उपयोग करता है — तो यह विभाजन का संकेत है। विकल्प: पैरामीटर के न्यूनतम सेट वाली कई विशेषीकृत विधियाँ।

Android डेवलपमेंट में, ISP का उल्लंघन तब होता है जब सभी ऐप्लिकेशन सेटिंग्स को पढ़ने और लिखने के लिए एक SharedPreferencesManager का उपयोग किया जाता है। Fragment जिसे केवल थीम पढ़ने की आवश्यकता है, उसे विभिन्न डेटा प्रकारों के लिए दर्जनों विधियों वाले वैश्विक प्रबंधक पर निर्भरता मिलती है। ThemePreferenceProvider, AuthPreferenceProvider, FeatureFlagProvider में विभाजन — कॉन्फ़िगरेशन सेवा स्तर पर ISP का अनुप्रयोग। प्रत्येक प्रदाता में ठीक वही विधियाँ होती हैं जिनकी उसके क्लाइंट को आवश्यकता है।

मोबाइल ऐप्लिकेशन में ISP के उदाहरण

डेटा के साथ काम करने के लिए इंटरफ़ेस वाला Android उदाहरण देखें। ISP उल्लंघन — सभी CRUD संचालनों के लिए एक इंटरफ़ेस, हालाँकि सभी क्लाइंट को सभी संचालनों की आवश्यकता नहीं है।

// ISP उल्लंघन: मोटा इंटरफ़ेस
interface UserRepository {
    fun getAll(): List<User>
    fun getById(id: Int): User
    fun save(user: User)
    fun delete(id: Int)
}

// ISP लागू करने के बाद: संकीर्ण इंटरफ़ेस
interface UserReader {
    fun getAll(): List<User>
    fun getById(id: Int): User
}

interface UserWriter {
    fun save(user: User)
    fun delete(id: Int)
}

// ReadOnlyViewModel लेखन विधियों पर निर्भर नहीं करता
class ReadOnlyViewModel(
    private val reader: UserReader
)

मीडिया के साथ काम करने के लिए प्रोटोकॉल पृथक्करण वाला iOS उदाहरण:

// ISP उल्लंघन: सभी मीडिया कार्य के लिए एक प्रोटोकॉल
protocol MediaService {
    func play(url: URL)
    func pause()
    func stop()
    func upload(data: Data) async -> URL
    func download(url: URL) async -> Data
}

// ISP के बाद: जिम्मेदारी के अनुसार प्रोटोकॉल में पृथक्करण
protocol MediaPlayer {
    func play(url: URL)
    func pause()
    func stop()
}

protocol MediaTransfer {
    func upload(data: Data) async -> URL
    func download(url: URL) async -> Data
}

// PlayerViewModel डाउनलोड विधियों पर निर्भर नहीं करता
class PlayerViewModel {
    private let player: MediaPlayer
}

व्यावहारिक निष्कर्ष: ISP क्लाइंट को इंटरफ़ेस के असंबंधित भागों में परिवर्तनों से बचाता है। UserRepository को UserReader और UserWriter में विभाजित करने का मतलब है कि save में परिवर्तन ReadOnlyViewModel को प्रभावित नहीं करते, और इसके विपरीत। प्रत्येक क्लाइंट उस कार्यक्षमता से अलग होता है जिसका वे उपयोग नहीं करते और सिस्टम के अन्य भागों में संशोधन करने पर परिवर्तनों की आवश्यकता नहीं होती।

ISP और SOLID: अन्य सिद्धांतों से संबंध

ISP और SRP — एक प्राकृतिक जोड़ी। SRP परिभाषित करता है कि एक वर्ग के पास बदलाव का एक कारण होना चाहिए। ISP उसी तर्क को इंटरफ़ेस पर लागू करता है: एक इंटरफ़ेस को एक क्लाइंट परिदृश्य की सेवा करनी चाहिए। एक वर्ग कई संकीर्ण इंटरफ़ेस लागू कर सकता है (प्रत्येक एक जिम्मेदारी के अनुरूप), जो कई जिम्मेदारियों वाले एक मोटे इंटरफ़ेस से अधिक स्वच्छ है।

ISP और OCP भी संबंधित हैं: संकीर्ण इंटरफ़ेस का विस्तार करना आसान है। संकीर्ण इंटरफ़ेस में नई विधि जोड़ने से केवल उसके क्लाइंट प्रभावित होते हैं। मोटे इंटरफ़ेस में विधि जोड़ने से सभी क्लाइंट प्रभावित होते हैं — यदि क्लाइंट अपना कार्यान्वयन बदलने के लिए मजबूर होते हैं तो संभावित रूप से OCP का उल्लंघन होता है।

ISP और DIP एक साथ काम करते हैं: DIP को एब्स्ट्रक्शन पर निर्भरता की आवश्यकता है। ISP इन एब्स्ट्रक्शन को संकीर्ण और केंद्रित बनाता है। विस्तृत इंटरफ़ेस पर निर्भरता अभी भी एक एब्स्ट्रक्शन पर निर्भरता है, लेकिन ISP के दृष्टिकोण से एक “खराब” एब्स्ट्रक्शन। चार सिद्धांत (SRP, OCP, ISP, DIP) “मॉड्यूलरिटी पिरामिड” बनाते हैं: SRP और ISP सीमाएँ परिभाषित करते हैं, OCP और DIP विस्तार और युग्मन के तरीके परिभाषित करते हैं।

घटक आर्किटेक्चर में ISP का अनुप्रयोग

घटक आर्किटेक्चर मोबाइल प्रोजेक्ट्स (मॉड्यूल, फ़ीचर, लेयर) में सार्वजनिक API स्तर पर ISP से लाभान्वित होता है। प्रत्येक मॉड्यूल अपने उपभोक्ताओं के लिए एक सामान्य फ़ेसड के बजाय संकीर्ण इंटरफ़ेस निर्यात करता है। यह उपभोक्ताओं को प्रभावित किए बिना मॉड्यूल के आंतरिक कार्यान्वयन को बदलने की अनुमति देता है जो इसकी केवल एक भाग कार्यक्षमता का उपयोग करते हैं।

Clean Architecture वाले Android प्रोजेक्ट्स में, ISP UseCases पर लागू किया जाता है: प्रत्येक UseCase एकल invoke या execute विधि वाला एक अलग इंटरफ़ेस है। क्लाइंट (ViewModel) पूरे रिपॉज़िटरी के बजाय केवल अपने आवश्यक UseCase पर निर्भर करता है। यह निर्भरताओं को पारदर्शी और परीक्षण योग्य बनाता है।