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

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

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

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

मॉड्यूलरिटी क्या है?

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

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

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

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

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

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

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

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

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

आम तौर पर होने वाली कुछ समस्याएं यहां दी गई हैं:

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

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

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

सैंपल