इस पेज का अनुवाद Cloud Translation API से किया गया है.

सामान्य मॉड्यूलराइज़ेशन पैटर्न

ऐसी कोई एक मॉड्युलराइज़ेशन रणनीति नहीं है जो सभी प्रोजेक्ट के लिए सही हो. इस वजह से Gradle की लचीली प्रकृति, इस बात की कुछ सीमाएं हैं कि उसे व्यवस्थित करने के लिए किया जा सकता है. इस पेज पर, कुछ सामान्य नियमों और सामान्य बातों के बारे में खास जानकारी दी गई है पैटर्न, जिनका इस्तेमाल मल्टी मॉड्यूल Android ऐप्लिकेशन बनाते समय किया जा सकता है.

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

ज़्यादा कोहिज़न और लो कपलिंग का सिद्धांत

मॉड्यूलर कोडबेस की विशेषता बताने का एक तरीका यह है कि कपलिंग का इस्तेमाल किया जाए और कोहिज़न प्रॉपर्टी. कपलिंग मॉड्यूल से मापी जाती है कि वह कितनी डिग्री है एक-दूसरे पर निर्भर करते हैं. इस संदर्भ में, सहसंयोजन से पता चलता है कि कैसे सिंगल मॉड्यूल एक-दूसरे से जुड़े हैं. सामान्य नियम के तौर पर, आपको लो कपलिंग और ज़्यादा कोहिज़न:

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

अलग-अलग तरह के मॉड्यूल

मॉड्यूल को व्यवस्थित करने का तरीका, मुख्य रूप से आपके ऐप्लिकेशन के आर्किटेक्चर पर निर्भर करता है. तय सीमा से कम कुछ सामान्य तरह के मॉड्यूल हैं जिन्हें आप अपने ऐप्लिकेशन में शामिल करते समय, हमारा सुझाए गए ऐप्लिकेशन आर्किटेक्चर देखें.

डेटा मॉड्यूल

डेटा मॉड्यूल में आम तौर पर, रिपॉज़िटरी, डेटा सोर्स, और मॉडल क्लास होती हैं. कॉन्टेंट बनाने डेटा मॉड्यूल की तीन मुख्य ज़िम्मेदारियां हैं:

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

**पहली इमेज**. सैंपल डेटा मॉड्यूल और उनका कॉन्टेंट.

फ़ीचर मॉड्यूल

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

मुख्य शब्द: "सुविधा का मॉड्यूल" एक ऐसा शब्द है जिसका इस्तेमाल Play की सुविधा में भी किया जाता है डिलीवरी में एक मॉड्यूल की जानकारी दी गई हो, जिसे कुछ शर्तों के साथ डिलीवर किया जा सकता है या मांग पर डाउनलोड किया जा सकता है. हालांकि, इस गाइड के संदर्भ में एक सुविधा मॉड्यूल है एक ऐसा मॉड्यूल जो आपके ऐप्लिकेशन के फ़ंक्शन का एक खास हिस्सा इनकैप्सुलेट करता हो.

**दूसरी इमेज**. इस ऐप्लिकेशन के हर टैब को एक सुविधा के तौर पर बताया जा सकता है.

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

**तीसरी इमेज**. सुविधा वाले मॉड्यूल और उनके कॉन्टेंट के सैंपल.

ऐप्लिकेशन मॉड्यूल

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

**चौथी इमेज**. *डेमो* और *फ़ुल* प्रॉडक्ट फ़्लेवर मॉड्यूल डिपेंडेंसी ग्राफ़.

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

**पांचवीं इमेज**. Wear ऐप्लिकेशन डिपेंडेंसी ग्राफ़.

सामान्य मॉड्यूल

कॉमन मॉड्यूल को कोर मॉड्यूल भी कहा जाता है. इनमें कोड शामिल होता है, जो अन्य मॉड्यूल में उपलब्ध होता है जिनका अक्सर इस्तेमाल किया जाता है. वे रिडंडंसी को कम करते हैं और किसी ऐप्लिकेशन का आर्किटेक्चर. सामान्य मॉड्यूल के उदाहरण नीचे दिए गए हैं:

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

टेस्ट मॉड्यूल

टेस्ट मॉड्यूल Android के ऐसे मॉड्यूल हैं जिन्हें सिर्फ़ जांच के लिए इस्तेमाल किया जाता है. मॉड्यूल में, टेस्ट कोड, जांच के लिए संसाधन, और टेस्ट डिपेंडेंसी शामिल होती हैं, जो सिर्फ़ परीक्षण चलाने के लिए ज़रूरी है और ऐप्लिकेशन के रनटाइम के दौरान इसकी ज़रूरत नहीं होती है. टेस्ट मॉड्यूल इसलिए बनाए जाते हैं, ताकि टेस्ट के लिए बने कोड को मुख्य कोड से अलग किया जा सके जिससे मॉड्यूल कोड को मैनेज करना और बनाए रखना आसान हो जाता है.

टेस्ट मॉड्यूल के लिए इस्तेमाल के उदाहरण

इन उदाहरणों में ऐसी स्थितियों के बारे में बताया गया है जिनमें टेस्ट मॉड्यूल लागू किए जा रहे हैं खास तौर से फ़ायदेमंद हो सकता है:

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

**छठी इमेज**. टेस्ट मॉड्यूल का इस्तेमाल, ऐसे मॉड्यूल को अलग करने के लिए किया जा सकता है जो आम तौर पर एक-दूसरे पर निर्भर होते हैं.

मॉड्यूल कम्यूनिकेशन के लिए मॉड्यूल

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

**सातवीं इमेज**. साइक्लिक डिपेंडेंसी की वजह से, मॉड्यूल के बीच सीधा और दो-तरफ़ा कम्यूनिकेशन नहीं हो सकता. दो अन्य स्वतंत्र मॉड्यूल के बीच डेटा फ़्लो को कंट्रोल करने के लिए, मीडिएट करने वाला मॉड्यूल ज़रूरी है.

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

navController.navigate("checkout/$bookId")

चेकआउट डेस्टिनेशन को आर्ग्युमेंट के तौर पर, किताब का आईडी मिलता है. इसका इस्तेमाल यह करने के लिए किया जाता है किताब के बारे में जानकारी फ़ेच कर सकता है. सेव किए गए स्टेट हैंडल का इस्तेमाल इन कामों के लिए किया जा सकता है किसी डेस्टिनेशन सुविधा के ViewModel में नेविगेशन आर्ग्युमेंट फिर से पाएं.

class CheckoutViewModel(savedStateHandle: SavedStateHandle, …) : ViewModel() {

   val uiState: StateFlow<CheckoutUiState> =
      savedStateHandle.getStateFlow<String>("bookId", "").map { bookId ->
          // produce UI state calling bookRepository.getBook(bookId)
      }
      …
}

आपको ऑब्जेक्ट को नेविगेशन आर्ग्युमेंट के तौर पर पास नहीं करना चाहिए. इसके बजाय, आसान आईडी का इस्तेमाल करें जिनकी मदद से डेटा लेयर से अपने पसंदीदा संसाधनों को ऐक्सेस और लोड किया जा सकता है. इस तरह, कपलिंग को कम रखा जा सकता है और सच्चाई के एक ही सोर्स का उल्लंघन नहीं होता सिद्धांत.

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

**आठवीं इमेज**. सुविधा वाले दो मॉड्यूल, जो शेयर किए गए डेटा मॉड्यूल पर निर्भर करते हैं.

डिपेंडेंसी इन्वर्ज़न

डिपेंडेंसी इन्वर्सेशन तब होता है, जब अपने कोड को इस तरह से व्यवस्थित किया जाता है कि ऐब्स्ट्रैक्ट जो उन्हें अच्छे तरीके से लागू करने के लिए डिज़ाइन नहीं किया गया है.

ऐब्स्ट्रैक्शन: एक कॉन्ट्रैक्ट जो यह तय करता है कि आपके एक-दूसरे से इंटरैक्ट करते हैं. ऐब्स्ट्रैक्शन मॉड्यूल, इसका एपीआई तय करता है जिसमें इंटरफ़ेस और मॉडल मौजूद हों.
कंक्रीट लागू करना: ऐसे मॉड्यूल जो ऐब्स्ट्रक्शन मॉड्यूल पर निर्भर करते हैं और अमूर्तीकरण के व्यवहार को लागू करें.

ऐब्स्ट्रक्शन मॉड्यूल में बताए गए व्यवहार पर निर्भर करने वाले मॉड्यूल को सिर्फ़ एक-एक करके टाइप करने के बजाय, ऐब्स्ट्रैक्ट को इस्तेमाल करने का विकल्प होता है.

**नौवीं इमेज**. लो लेवल के मॉड्यूल पर सीधे तौर पर निर्भर करने वाले हाई लेवल मॉड्यूल के बजाय, हाई लेवल और लागू करने वाले मॉड्यूल, ऐब्स्ट्रक्शन मॉड्यूल पर निर्भर करते हैं.

उदाहरण

ऐसे फ़ीचर मॉड्यूल के बारे में सोचें जिसे काम करने के लिए डेटाबेस की ज़रूरत होती है. फ़ीचर मॉड्यूल आपको डेटाबेस के लागू होने के तरीके से जुड़ी कोई समस्या है. भले ही, वह कोई लोकल रूम डेटाबेस या रिमोट Firestore इंस्टेंस. इसे सिर्फ़ ऐप्लिकेशन डेटा को स्टोर करने और पढ़ने की ज़रूरत होती है.

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

कंक्रीट इंप्लीमेंटेशन मॉड्यूल का इस्तेमाल करके, एब्स्ट्रक्शन मॉड्यूल में तय किए गए एपीआई. ऐसा करने के लिए, मॉड्यूल, ऐब्स्ट्रक्शन मॉड्यूल पर भी निर्भर करता है.

डिपेंडेंसी इंजेक्शन

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

releaseImplementation(project(":database:impl:firestore"))

debugImplementation(project(":database:impl:room"))

androidTestImplementation(project(":database:impl:mock"))

फ़ायदे

अपने एपीआई और उन्हें लागू करने के तरीकों को अलग-अलग करने के फ़ायदे यहां दिए गए हैं:

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

कब अलग करें

इन तरीकों में अपने एपीआई को लागू करने के तरीके से अलग करना बेहतर होता है ये मामले:

अलग-अलग तरह की सुविधाएं: अगर सिस्टम के अलग-अलग हिस्सों को कई तरीकों से, साफ़ एपीआई की मदद से अलग-अलग लागू करना. उदाहरण के लिए, आपके पास ऐसा रेंडरिंग सिस्टम हो सकता है जो OpenGL का इस्तेमाल करता हो या Vulkan या कोई ऐसा बिलिंग सिस्टम जो Play या आपकी इन-हाउस बिलिंग के साथ काम करता हो एपीआई.
एक से ज़्यादा ऐप्लिकेशन: अगर आपको एक से ज़्यादा ऐप्लिकेशन बनाने हैं, तो साझा क्षमताओं का उपयोग करते हैं, तो आप सामान्य API और हर प्लैटफ़ॉर्म के हिसाब से उसे लागू करना.
स्वतंत्र टीमें: इस बंटवारे की मदद से, अलग-अलग डेवलपर या टीमों को ये काम करने की अनुमति मिलती है कोड बेस के अलग-अलग हिस्सों पर एक साथ काम कर सकते हैं. डेवलपर को इन चीज़ों पर ध्यान देना चाहिए और उन्हें सही तरीके से इस्तेमाल करने पर ध्यान दें. उन्हें जिन चीज़ों की अन्य मॉड्यूल के लागू होने की जानकारी के बारे में चिंता करें.
बड़ा कोड बेस: जब कोड बेस बड़ा या जटिल होता है, तो एपीआई को अलग किया जाता है लागू करने से कोड ज़्यादा आसानी से मैनेज किया जा सकता है. इसकी मदद से, कोडबेस को ज़्यादा विस्तृत, समझने लायक, और मैनेज किए जा सकने वाली इकाइयों में बदल देना चाहिए.

कैसे लागू करें?

डिपेंडेंसी इन्वर्सेशन लागू करने के लिए, यह तरीका अपनाएं:

ऐब्स्ट्रक्शन मॉड्यूल बनाएं: इस मॉड्यूल में एपीआई (इंटरफ़ेस) होने चाहिए और मॉडल) से मेल खाना चाहिए, जो आपकी सुविधा के व्यवहार को परिभाषित करता है.
लागू करने के लिए मॉड्यूल बनाना: लागू करने वाले मॉड्यूल को एपीआई मॉड्यूल को लागू करना और एब्स्ट्रक्शन का व्यवहार लागू करना.

10 इमेज. लागू करने वाले मॉड्यूल, ऐब्स्ट्रक्शन मॉड्यूल पर निर्भर करते हैं.
ऐब्स्ट्रक्शन मॉड्यूल पर निर्भर हाई लेवल मॉड्यूल बनाएं: के बजाय किसी खास मॉड्यूल या मॉड्यूल के आधार पर, अपने मॉड्यूल को इन चीज़ों पर निर्भर होना चाहिए: ऐब्स्ट्रक्शन मॉड्यूल. हाई लेवल मॉड्यूल को लागू करने के बारे में जानने की ज़रूरत नहीं है जानकारी के लिए, उन्हें सिर्फ़ कॉन्ट्रैक्ट (एपीआई) की ज़रूरत होती है.

11वीं इमेज. हाई लेवल मॉड्यूल, ऐब्स्ट्रैक्ट पर आधारित होते हैं, न कि लागू करने पर.
लागू करने के लिए मॉड्यूल उपलब्ध कराएं: आखिर में, आपको अपनी डिपेंडेंसी के लिए लागू किया जा सकता है. लागू करने का तरीका इन बातों पर निर्भर करता है सेटअप करना होगा, लेकिन ऐप्लिकेशन मॉड्यूल आम तौर पर ऐसा करने के लिए अच्छी जगह है. लागू करने के लिए, इसे आपके चुने गए इवेंट पर निर्भर करता है बिल्ड वैरिएंट या टेस्टिंग सोर्स सेट हो.

12 इमेज. ऐप्लिकेशन मॉड्यूल असल में लागू करता है.

सबसे सही तरीके

जैसा कि शुरुआत में बताया गया है, विज्ञापन बनाने का कोई एक सही तरीका नहीं है मल्टी-मॉड्यूल ऐप्लिकेशन. जैसे कई सॉफ़्टवेयर आर्किटेक्चर मौजूद हैं, उनकी मौजूदगी में भी काम कर सकते हैं. फिर भी, निम्न सामान्य सुझावों की मदद से आपके कोड को पढ़ने लायक और मैनेज किया जा सकता है. साथ ही, जिसे टेस्ट किया जा सकता है.

अपना कॉन्फ़िगरेशन एक जैसा रखें

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

वर्शन कैटलॉग डिपेंडेंसी की एक सुरक्षित सूची है को सिंक के दौरान Gradle ने जनरेट किया. यह एक केंद्रीय स्थान है जहां आप डिपेंडेंसी. यह एक प्रोजेक्ट के सभी मॉड्यूल के लिए उपलब्ध होता है.
अलग-अलग मॉड्यूल के बीच बिल्ड लॉजिक शेयर करने के लिए, कॉन्वेंशन प्लगिन का इस्तेमाल करें.

एक्सपोज़र कम से कम करें

मॉड्यूल का सार्वजनिक इंटरफ़ेस छोटा होना चाहिए और ज़रूरी. इसके बाहर लागू करने की कोई भी जानकारी लीक नहीं होनी चाहिए. दायरा कम से कम संभव कोशिश की. Kotlin के private या internal का इस्तेमाल करें विज़िबिलिटी स्कोप का इस्तेमाल करके एलान वाले मॉड्यूल-निजी को बनाया जा सकता है. जब एलान किया जा रहा हो डिपेंडेंसी का इस्तेमाल करें, तो api के बजाय implementation को प्राथमिकता दें. बाद वाला आपके मॉड्यूल के उपभोक्ताओं को ट्रांज़िटिव डिपेंडेंसी दिखाता है. इसका इस्तेमाल किया जा रहा है लागू करने पर बिल्ड टाइम बेहतर हो सकता है, क्योंकि इससे मॉड्यूल की संख्या कम होती है जिन्हें फिर से बनाने की ज़रूरत है.

Kotlin और Java मॉड्यूल

Android Studio तीन तरह के मॉड्यूल के साथ काम करता है:

ऐप्लिकेशन मॉड्यूल आपके ऐप्लिकेशन का एंट्री पॉइंट है. इनमें ये चीज़ें शामिल हो सकती हैं सोर्स कोड, संसाधन, एसेट, और AndroidManifest.xml. किसी ऐप्लिकेशन मॉड्यूल एक Android ऐप्लिकेशन बंडल (एएबी) या Android ऐप्लिकेशन पैकेज है (APK).
लाइब्रेरी मॉड्यूल का कॉन्टेंट, ऐप्लिकेशन मॉड्यूल जैसा ही है. वे हैं का इस्तेमाल दूसरे Android मॉड्यूल में, डिपेंडेंसी के तौर पर किया जाता है. लाइब्रेरी मॉड्यूल का आउटपुट एक Android संग्रह (एएआर) है, जो ऐप्लिकेशन के मॉड्यूल की तरह है, लेकिन ये एक Android संग्रह (AAR) फ़ाइल में इकट्ठा किया जाता है, जिसे बाद में अन्य डिपेंडेंसी के तौर पर मॉड्यूल का इस्तेमाल करें. लाइब्रेरी मॉड्यूल की मदद से ये काम किए जा सकते हैं कई ऐप्लिकेशन मॉड्यूल में, एक ही लॉजिक और रिसॉर्स को इनकैप्सुलेट करके फिर से इस्तेमाल किया जा सकता है.
Kotlin और Java लाइब्रेरी में कोई भी Android संसाधन, एसेट या मेनिफ़ेस्ट फ़ाइलें अपलोड करें.

चूंकि Android मॉड्यूल ओवरहेड के साथ आते हैं, इसलिए आमतौर पर आप Kotlin या Java की तरह.