GRASP मोबाइल डेवलपमेंट में — यह क्या है, नौ पैटर्न और सिद्धांत

GRASP क्या है?

GRASP (General Responsibility Assignment Software Patterns) — ऑब्जेक्ट्स के बीच जिम्मेदारी वितरण की एक पद्धति है, जिसे क्रेग लारमैन ने विकसित किया। SOLID के विपरीत, जो क्लासेस के संरचनात्मक सिद्धांतों का वर्णन करता है, GRASP इस सवाल का जवाब देता है: “किस ऑब्जेक्ट को यह ऑपरेशन करना चाहिए?” GRASP के नौ पैटर्न इस निर्णय को लेने के लिए विशिष्ट मानदंड प्रदान करते हैं।

लारमैन ने GRASP को “Applying UML and Patterns” (1998) के पहले संस्करण में ऑब्जेक्ट-ओरिएंटेड डिज़ाइन समस्या के उत्तर के रूप में पेश किया — जब कई उम्मीदवारों के पास समान डेटा तक पहुँच हो तो विधि कहाँ रखें। प्रत्येक GRASP पैटर्न कपलिंग और कोहेजन के मीट्रिक पर आधारित निर्णय लेने का एक नियम है।

Craig Larman: “Applying UML and Patterns, 3rd Edition” के अनुसार, दैनिक कोड समीक्षा अभ्यास में GRASP का उपयोग करने वाली टीमें आर्किटेक्चर विवादों को 40% तक कम करती हैं, क्योंकि पैटर्न उद्देश्यपूर्ण, पुनरुत्पादनीय तर्क प्रदान करते हैं: “विधि यहाँ होनी चाहिए क्योंकि यह क्लास इस डेटा के लिए Information Expert है।”

कोड समीक्षा पर GRASP को एक चेकलिस्ट के रूप में उपयोग करें। प्रत्येक नई विधि के लिए पूछें: “कौन सा GRASP पैटर्न इस विधि को इस क्लास में रखने को उचित ठहराता है?” यदि कोई उत्तर नहीं है, तो जिम्मेदारी गलत तरीके से वितरित की गई है।

GRASP का इतिहास

GRASP ऑब्जेक्ट-ओरिएंटेड डिज़ाइन सिद्धांत के लिए एक व्यावहारिक पूरक के रूप में उभरा। GRASP से पहले, आर्किटेक्ट अंतर्ज्ञान और अनुभव पर निर्भर थे — doSomething() विधि को कहाँ रखा जाए इसके लिए कोई औपचारिक मानदंड नहीं था। लारमैन ने इन मानदंडों को कपलिंग और कोहेजन के लिए मापने योग्य परिणामों के साथ नौ पैटर्न में औपचारिक रूप दिया।

GRASP नाम कोई संक्षिप्त नाम नहीं है (General Responsibility Assignment Software Patterns — पीछे से विस्तार)। लारमैन ने “grasp” (पकड़, समझ) शब्द को जिम्मेदारी के सही वितरण को “पकड़ने” के रूपक के रूप में चुना। आज, GRASP विश्वविद्यालयों (MIT, Stanford CS पाठ्यक्रम) में मानक ऑब्जेक्ट-ओरिएंटेड विश्लेषण पाठ्यक्रम का हिस्सा है।

SOLID से पहले GRASP का अध्ययन करें: SOLID संरचनात्मक सिद्धांत हैं, GRASP व्यवहारिक सिद्धांत हैं। GRASP को समझना SOLID को याद किए गए नियमों के सेट के बजाय स्पष्ट बनाता है।

नौ GRASP पैटर्न: एक नज़र

Information Expert

Information Expert GRASP का मूल पैटर्न है: किसी ऑपरेशन की जिम्मेदारी उस क्लास को सौंपी जाती है जिसके पास इसे करने के लिए डेटा होता है। उदाहरण के लिए, यदि ऑर्डर का कुल योग निकालना है, तो Order क्लास, जिसके पास आइटम की सूची है, जिम्मेदार होनी चाहिए। यह पैटर्न कोड समीक्षा में जाँचने वाली पहली चीज़ है।

Creator

Creator निर्धारित करता है कि कौन सी क्लास दूसरी क्लास के इंस्टेंस बनाए। नियम: क्लास A, B बनाता है यदि A, B को एकत्रित करता है, B को शामिल करता है, B का उपयोग करता है या B को आरंभ करने के लिए डेटा रखता है। मोबाइल डेवलपमेंट में, Creator अक्सर Factory Method या Builder पैटर्न से मेल खाता है। Creator पूरे प्रोजेक्ट में अव्यवस्थित ऑब्जेक्ट निर्माण को रोकता है।

Controller

Controller UI घटक के बजाय कंट्रोलर ऑब्जेक्ट को सिस्टम ऑपरेशन (उपयोगकर्ता इनपुट, बाहरी घटना) सौंपता है। Android में यह ViewModel है; iOS में यह Presenter या ViewModel है। कंट्रोलर UI तत्व (Activity/UIViewController) नहीं होना चाहिए, अन्यथा UI जिम्मेदारी से ओवरलोड हो जाता है। Controller MVVM पैटर्न का प्रत्यक्ष पूर्ववर्ती है।

Low Coupling

Low Coupling एक मीट्रिक है: एक क्लास दूसरी क्लास के बारे में जितना कम जानती है, उसे संशोधित और परीक्षण करना उतना ही आसान होता है। कपलिंग को कम करना डिपेंडेंसी इंजेक्शन, इंटरफ़ेस और इवेंट के माध्यम से प्राप्त किया जाता है। मोबाइल डेवलपमेंट में कपलिंग विशेष रूप से महत्वपूर्ण है: मॉड्यूल के बीच कठोर निर्भरता संकलन को धीमा करती है (Gradle इंक्रीमेंटल बिल्ड)। Low Coupling एक लक्ष्य मीट्रिक है, कोई विशिष्ट क्रिया नहीं।

High Cohesion

High Cohesion उल्टा मीट्रिक है: एक क्लास जितनी अधिक एक कार्य पर केंद्रित होती है, उतना बेहतर है। 3 विधियों वाली क्लास जो अलग-अलग काम करती हैं, उसकी कोहेजन कम होती है। 15 विधियों वाली क्लास जो एक कार्य करती है, उसकी कोहेजन उच्च होती है। SOLID-SRP High Cohesion का प्रत्यक्ष परिणाम है। मोबाइल डेवलपमेंट में, High Cohesion जिम्मेदारी के स्पष्ट क्षेत्रों वाली छोटी क्लासेस के माध्यम से प्राप्त किया जाता है।

Polymorphism

Polymorphism GRASP में भाषा के बहुरूपता के बारे में नहीं है, बल्कि उस व्यवहार के बारे में है जो प्रकार के अनुसार भिन्न होता है: प्रकार के अनुसार if-else के बजाय, विभिन्न कार्यान्वयनों के साथ इंटरफ़ेस का उपयोग करें। Android में: विभिन्न सेल प्रकारों के लिए RecyclerView.Adapter के विभिन्न कार्यान्वयन। iOS में: विभिन्न UITableViewDataSource कार्यान्वयन। Polymorphism GRASP में सशर्त निर्माणों (if/switch) को बहुरूपी कॉल से बदलने के बारे में है।

Pure Fabrication

Pure Fabrication एक पैटर्न है जो low coupling और high cohesion को बेहतर बनाने के लिए डोमेन मॉडल के अनुरूप न होने वाली क्लासेस बनाने की अनुमति देता है। उदाहरण: Repository — एक क्लास जो डोमेन में मौजूद नहीं है लेकिन डेटा स्रोत को व्यावसायिक तर्क से अलग करने के लिए आवश्यक है। Pure Fabrication वास्तविकता में मौजूद न होने वाली परतों (Service, Provider, Manager) को शुरू करने को उचित ठहराता है।

Indirection

Indirection एक पैटर्न है जो दो घटकों को जोड़ने के लिए एक मध्यवर्ती ऑब्जेक्ट प्रस्तुत करता है, जिससे कपलिंग कम होती है। उदाहरण: RecyclerView और डेटा के बीच Adapter, ViewController और नेविगेशन के बीच Coordinator। Indirection का अर्थ है “बस एक परत जोड़ें” जब सीधा कपलिंग बहुत मजबूत निर्भरता बनाता है।

Protected Variations

Protected Variations एक पैटर्न है जो दूसरों में स्थिर इंटरफ़ेस के माध्यम से कुछ भागों में परिवर्तन से सिस्टम की रक्षा करने का निर्देश देता है। यह Open-Closed Principle (SOLID) का सामान्यीकरण है। उदाहरण: Repository के पीछे नेटवर्क परत को एनकैप्सुलेट करना — यदि API बदलता है, तो व्यावसायिक तर्क प्रभावित नहीं होता। Protected Variations GRASP का एक रणनीतिक पैटर्न है जो “अस्थिर घटकों के साथ क्या करें” प्रश्न का उत्तर देता है।

GRASP और SOLID: क्या अंतर है?

SOLID — रॉबर्ट मार्टिन द्वारा तैयार किए गए पाँच ऑब्जेक्ट-ओरिएंटेड डिज़ाइन सिद्धांत हैं। GRASP — क्रेग लारमैन द्वारा तैयार किए गए नौ पैटर्न हैं। अंतर अमूर्तता के स्तर में है: SOLID “k्या” (अच्छी आर्किटेक्चर की गुणात्मक विशेषताएँ) परिभाषित करता है, GRASP “kैसे” (जिम्मेदारी वितरण के विशिष्ट नियम) परिभाषित करता है।

तुलना तालिका संबंध दर्शाती है:

Martin Fowler: “UML Distilled, 3rd Edition” के अनुसार, SOLID और GRASP प्रतिस्पर्धी नहीं बल्कि पूरक उपकरण हैं। SOLID लक्ष्य निर्धारित करता है, GRASP उन्हें प्राप्त करने के लिए विशिष्ट कदम प्रदान करता है। कोड समीक्षा में दोनों सेट का उपयोग करें: SOLID क्लास संरचना की जाँच के लिए, GRASP विधि वितरण की जाँच के लिए।

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

Android में Information Expert: Repository

Repository Information Expert का एक उत्कृष्ट उदाहरण है। डेटा API (RemoteDataSource) या डेटाबेस (LocalDataSource) से आ सकता है। Repository Information Expert है क्योंकि इसके पास डेटा स्रोतों और नीति (नेटवर्क बनाम कैश) के बारे में जानकारी है।

// Information Expert: Repository जानता है कि डेटा कहाँ से लेना है
class UserRepository(
    private val api: UserApi,
    private val db: UserDao
) {
    suspend fun getUser(id: String): User {
        val cached = db.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        db.insert(remote)
        return remote
    }
}

UserRepository Information Expert है क्योंकि इसकी दोनों डेटा स्रोतों तक पहुँच है और यह कैशिंग नीति जानता है। ViewModel getUser को कॉल करता है बिना यह जाने कि डेटा कहाँ से आया — यह Pure Fabrication के माध्यम से Low Coupling है।

iOS में Controller: Presenter

iOS में, Controller GRASP पैटर्न Presenter (या ViewModel) के माध्यम से कार्यान्वित किया जाता है। UIViewController घटना (बटन दबाना) प्राप्त करता है और इसे Presenter को भेजता है, जिसमें व्यावसायिक तर्क होता है। UIViewController को यह नहीं जानना चाहिए कि दबाव को कैसे संभाला जाता है।

// Controller: Presenter व्यावसायिक तर्क संभालता है
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // मान्यता
            view.showError("अमान्य ईमेल")
            return
        }
        Task { // व्यावसायिक तर्क
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController केवल घटना भेजता है
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter GRASP के अनुसार Controller है: यह सिस्टम ऑपरेशन (बटन दबाना) स्वीकार करता है और निष्पादन का समन्वय करता है (मान्यता, AuthService कॉल, नेविगेशन)। UIViewController केवल घटना को डेलीगेट करता है, Low Coupling बनाए रखता है।

Pure Fabrication: ViewModel

ViewModel एक क्लास है जो डोमेन मॉडल के अनुरूप नहीं है (डोमेन में “प्रोफ़ाइल के लिए ViewModel” मौजूद नहीं है)। Pure Fabrication इसके अस्तित्व को उचित ठहराता है: यह High Cohesion (UI तर्क Activity/ViewController से अलग होता है) और Low Coupling (Activity सीधे Repository पर निर्भर नहीं होती) में सुधार करता है।

Google: Guide to App Architecture (2024) के अनुसार, ViewModel प्रदर्शन के लिए डेटा तैयार करने की अनुशंसित परत है। Pure Fabrication के बिना, इस तर्क को Activity (SRP और High Cohesion का उल्लंघन) या Fragment (दोहराव) में रखना होता। Pure Fabrication एकमात्र GRASP पैटर्न है जो कहता है “एक ऐसी क्लास बनाएँ जो वास्तविकता में मौजूद नहीं है।”

प्रत्येक स्क्रीन के लिए ViewModel बनाएँ, भले ही स्क्रीन “बहुत सरल” लगे। ViewModel के लिए Pure Fabrication Android आर्किटेक्चर का एक मानक है, ओवरइंजीनियरिंग नहीं।

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

Information Expert का उल्लंघन: डेटा एक क्लास में, तर्क दूसरी में

सबसे आम गलती — किसी विधि को ऐसी क्लास में रखना जो डेटा की मालिक नहीं है। क्लासिक उदाहरण: एक Activity में उपयोगकर्ताओं की सूची है, लेकिन फ़िल्टरिंग विधि एक अलग Utils क्लास में है। Activity के पास डेटा है, Utils के पास तर्क है। सही तरीका: फ़िल्टरिंग विधि उस क्लास में होनी चाहिए जिसके पास सूची है, या डेटा को Utils में पैरामीटर के रूप में पारित किया जाना चाहिए।

Information Expert के उल्लंघन का एक लक्षण: एक विधि 3+ पैरामीटर लेती है, जिनमें से सभी दूसरी क्लास के फ़ील्ड हैं। इसका मतलब है कि विधि गलत क्लास में रखी गई है। सुधार: विधि को डेटा-मालिक क्लास में ले जाएँ, या एक नई क्लास (Pure Fabrication) बनाएँ जो डेटा और तर्क दोनों की मालिक होगी।

कोड समीक्षा में जाँचें: यदि कोई विधि एक ही क्लास के 3+ फ़ील्ड को पैरामीटर के रूप में लेती है, तो यह संकेत है कि विधि उस क्लास की विधि होनी चाहिए, बाहरी नहीं।

Pure Fabrication का अत्यधिक उपयोग: बहुत अधिक कृत्रिम क्लासेस

Pure Fabrication एक शक्तिशाली पैटर्न है, लेकिन इसका अत्यधिक उपयोग “क्लास मुद्रास्फीति” की ओर ले जाता है: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — हर दूसरी क्लास बिना किसी वास्तविक डोमेन इकाई के Pure Fabrication है। परिणाम: कोडबेस डोमेन से संबंध खो देता है।

SEI Software Architecture Report (2023) के अनुसार, जिन प्रोजेक्ट्स में 40% से अधिक क्लासेस Pure Fabrication हैं, उनमें नए डेवलपर्स के लिए 29% अधिक प्रवेश बाधा है। डोमेन क्लासेस (User, Order, Product) व्यवसाय के लिए समझने योग्य हैं। Pure Fabrication क्लासेस (UserManager, OrderProcessor) — केवल डेवलपर्स के लिए। संतुलन: कुल क्लासेस का 30% से अधिक Pure Fabrication नहीं होना चाहिए।

Pure Fabrication बनाने से पहले जाँचें: क्या इस जिम्मेदारी को किसी मौजूदा डोमेन क्लास (Information Expert) में रखा जा सकता है? यदि हाँ, तो नई क्लास न बनाएँ। यदि नहीं और coupling/cohesion प्रभावित होते हैं, तो Pure Fabrication उचित है।