Android ऐप्लिकेशन को मॉड्यूलर बनाने के बारे में गाइड

कई Gradle मॉड्यूल वाले प्रोजेक्ट को मल्टी-मॉड्यूल प्रोजेक्ट कहा जाता है. इस गाइड में, कई मॉड्यूल वाले Android ऐप्लिकेशन बनाने के सबसे सही तरीके और सुझाए गए पैटर्न के बारे में बताया गया है.

बढ़ते कोडबेस की समस्या

लगातार बढ़ते कोडबेस में, स्केलेबिलिटी, कोड को पढ़ने में आसानी, और कोड की कुल क्वालिटी अक्सर समय के साथ कम हो जाती है. ऐसा इसलिए होता है, क्योंकि कोडबेस का साइज़ बढ़ता जाता है. हालांकि, कोडबेस को मैनेज करने वाले लोग, इसे आसानी से मैनेज किए जा सकने वाले स्ट्रक्चर में बदलने के लिए ज़रूरी कदम नहीं उठाते. मॉड्यूलराइज़ेशन, कोडबेस को इस तरह से व्यवस्थित करने का एक तरीका है कि उसे मैनेज करना आसान हो जाए और इन समस्याओं से बचा जा सके.

मॉड्यूलराइज़ेशन क्या है?

मॉड्यूलराइज़ेशन, कोडबेस को ऐसे हिस्सों में बांटने का तरीका है जो एक-दूसरे से कम जुड़े हों और जिनमें अलग-अलग फ़ंक्शन हों. हर हिस्सा एक मॉड्यूल होता है. हर मॉड्यूल अलग होता है और उसका एक खास मकसद होता है. किसी समस्या को छोटी और आसानी से हल की जा सकने वाली उप-समस्याओं में बांटने से, बड़े सिस्टम को डिज़ाइन करने और उसे मैनेज करने की जटिलता कम हो जाती है.

पहली इमेज: कई मॉड्यूल वाले कोडबेस का डिपेंडेंसी ग्राफ़

मॉड्यूलर बनाने के फ़ायदे

मॉड्यूलर बनाने के कई फ़ायदे हैं. हालांकि, इनमें से हर फ़ायदा, कोडबेस को मैनेज करने और उसकी क्वालिटी को बेहतर बनाने के लिए होता है. नीचे दी गई टेबल में, मुख्य फ़ायदों के बारे में बताया गया है.

फ़ायदा खास जानकारी
फिर से इस्तेमाल किया जा सकता है मॉड्यूलर बनाने की सुविधा से, कोड शेयर करने और एक ही फ़ाउंडेशन से कई ऐप्लिकेशन बनाने के अवसर मिलते हैं. मॉड्यूल, असरदार तरीके से बिल्डिंग ब्लॉक होते हैं. ऐप्लिकेशन में अलग-अलग मॉड्यूल के तौर पर व्यवस्थित की गई सुविधाएं होनी चाहिए. किसी मॉड्यूल की सुविधाएं, किसी ऐप्लिकेशन में चालू हो सकती हैं या नहीं. उदाहरण के लिए, :feature:news, ऐप्लिकेशन के फ़ुल वर्शन और Wear ऐप्लिकेशन का हिस्सा हो सकता है, लेकिन डेमो वर्शन का हिस्सा नहीं.
विज़िबिलिटी को सख्ती से कंट्रोल करना मॉड्यूल की मदद से, यह आसानी से कंट्रोल किया जा सकता है कि कोडबेस के दूसरे हिस्सों को क्या दिखाया जाए. अपने सार्वजनिक इंटरफ़ेस को मॉड्यूल के बाहर इस्तेमाल होने से रोकने के लिए, उसे छोड़कर बाकी सभी चीज़ों को internal या private के तौर पर मार्क किया जा सकता है.
ज़रूरत के मुताबिक डिलीवरी Play Feature Delivery, ऐप्लिकेशन बंडल की बेहतर सुविधाओं का इस्तेमाल करता है. इसकी मदद से, अपने ऐप्लिकेशन की कुछ सुविधाओं को किसी शर्त के साथ या मांग पर डिलीवर किया जा सकता है.

ऊपर बताए गए फ़ायदे, सिर्फ़ मॉड्यूलर कोडबेस की मदद से मिल सकते हैं. यहां बताए गए फ़ायदे, दूसरी तकनीकों से भी मिल सकते हैं. हालांकि, मॉड्यूलर बनाने की सुविधा से, इन फ़ायदों को और बेहतर तरीके से हासिल किया जा सकता है.

फ़ायदा खास जानकारी
विस्तार करने की क्षमता टाइटली कपल्ड कोडबेस में, एक बदलाव से कोड के ऐसे हिस्सों में बदलाव हो सकते हैं जो एक-दूसरे से जुड़े नहीं लगते. सही तरीके से मॉड्यूलर किया गया प्रोजेक्ट, समस्याओं को अलग करने के सिद्धांत को अपनाएगा. इसलिए, इसमें कूपलिंग को सीमित किया जाएगा. इससे योगदान देने वाले लोगों को ज़्यादा अधिकार मिलते हैं.
मालिकाना हक मॉड्यूल का इस्तेमाल, अपने-आप काम करने की सुविधा चालू करने के अलावा, जवाबदेही लागू करने के लिए भी किया जा सकता है. किसी मॉड्यूल का मालिकाना हक एक व्यक्ति के पास हो सकता है. वह कोड को मैनेज करने, गड़बड़ियों को ठीक करने, टेस्ट जोड़ने, और बदलावों की समीक्षा करने की ज़िम्मेदारी निभाता है.
एनकैप्सुलेशन एन्कैप्सलेशन का मतलब है कि आपके कोड के हर हिस्से को दूसरे हिस्सों के बारे में कम से कम जानकारी होनी चाहिए. अलग-अलग कोड को पढ़ना और समझना आसान होता है.
जांच की जा सकती है टेस्ट करने की सुविधा से पता चलता है कि आपके कोड की जांच करना कितना आसान है. जांचे जा सकने वाले कोड में, कॉम्पोनेंट को अलग-अलग करके आसानी से जांचा जा सकता है.
बिल्ड प्रोसेस में लगने वाला समय Gradle की कुछ सुविधाएं, जैसे कि इंक्रीमेंटल बिल्ड, बिल्ड कैश या पैरलल बिल्ड, बिल्ड की परफ़ॉर्मेंस को बेहतर बनाने के लिए मॉड्यूलरिटी का फ़ायदा ले सकती हैं.

आम तौर पर होने वाली गलतियां

आपके कोडबेस में जितने ज़्यादा मॉड्यूल होंगे, वह उतना ही बेहतर होगा. ज़्यादा जानकारी वाले कोडबेस में, छोटे-छोटे ज़्यादा मॉड्यूल होते हैं. मॉड्यूलर कोडबेस डिज़ाइन करते समय, आपको यह तय करना चाहिए कि जानकारी कितनी बारीक होनी चाहिए. ऐसा करने के लिए, अपने कोडबेस के साइज़ और उसकी जटिलता को ध्यान में रखें. बहुत ज़्यादा बारीकियों पर ध्यान देने से, ओवरहेड का बोझ बढ़ जाएगा. वहीं, बहुत ज़्यादा मोटे लेवल पर ध्यान देने से, मॉड्यूलर बनाने के फ़ायदे कम हो जाएंगे.

आम तौर पर होने वाली कुछ गड़बड़ियां यहां दी गई हैं:

  • बहुत बारीक: हर मॉड्यूल, बिल्ड की जटिलता और बॉयलरप्लेट कोड के तौर पर कुछ ओवरहेड लाता है. मुश्किल बिल्ड कॉन्फ़िगरेशन की वजह से, सभी मॉड्यूल में कॉन्फ़िगरेशन को एक जैसा बनाए रखना मुश्किल हो जाता है. बहुत ज़्यादा बोइलरप्लेट कोड होने पर, कोडबेस काफ़ी जटिल हो जाता है और उसे मैनेज करना मुश्किल हो जाता है. अगर ओवरहेड, स्केलेबिलिटी में होने वाले सुधारों को कम करता है, तो आपको कुछ मॉड्यूल को एक साथ जोड़ना चाहिए.
  • बहुत बड़े मॉड्यूल: इसके उलट, अगर आपके मॉड्यूल बहुत बड़े हो रहे हैं, तो हो सकता है कि आपके पास एक और मॉनोलिथ हो और आपको मॉड्यूलरिटी के फ़ायदे न मिलें. उदाहरण के लिए, किसी छोटे प्रोजेक्ट में डेटा लेयर को एक ही मॉड्यूल में डालना ठीक है. हालांकि, डेटाबेस के बड़े होने पर, रिपॉज़िटरी और डेटा सोर्स को स्टैंडअलोन मॉड्यूल में अलग करना ज़रूरी हो सकता है.
  • बहुत जटिल: यह ज़रूरी नहीं है कि अपने प्रोजेक्ट को मॉड्यूलर बनाएं. कोडबेस का साइज़, सबसे अहम फ़ैक्टर होता है. अगर आपको लगता है कि आपका प्रोजेक्ट किसी तय थ्रेशोल्ड से ज़्यादा नहीं बढ़ेगा, तो स्केलेबिलिटी और बिल्ड में लगने वाले समय में होने वाली बढ़ोतरी लागू नहीं होगी.

क्या मॉड्यूलर बनाने की तकनीक मेरे लिए सही है?

अगर आपको फिर से इस्तेमाल करने, 'किसको दिखे' सेटिंग को सख्ती से कंट्रोल करने या Play Feature Delivery का इस्तेमाल करने के फ़ायदे चाहिए, तो मॉड्यूल बनाना ज़रूरी है. अगर आपको ऐसा नहीं करना है, लेकिन फिर भी आपको बेहतर स्केलेबिलिटी, मालिकाना हक, एन्कैप्सलेशन या बिल्ड टाइम का फ़ायदा चाहिए, तो मॉड्यूलर बनाने पर विचार करें.

सैंपल