एंड्रॉइड मल्टी-मॉड्यूल आर्किटेक्चर। ए टू जेड

सभी को नमस्कार!

बहुत पहले नहीं, हमने महसूस किया कि एक मोबाइल एप्लिकेशन केवल एक पतला ग्राहक नहीं है, बल्कि बहुत ही अलग तर्क की एक बड़ी संख्या है जिसे सुव्यवस्थित करने की आवश्यकता है। यही कारण है कि हम स्वच्छ वास्तुकला के विचारों से प्रेरित थे, महसूस किया कि DI क्या है, डैगर 2 का उपयोग करना सीखें, और अब हमारी आंखें बंद होने से हम किसी भी सुविधा को परतों में तोड़ने में सक्षम हैं।

लेकिन दुनिया अभी भी खड़ी नहीं है, और पुरानी समस्याओं के समाधान के साथ नए लोग आते हैं। और इस नई समस्या का नाम है मोनोमॉड्यूलरिटी। आप आमतौर पर इस समस्या के बारे में पता लगाते हैं जब विधानसभा का समय अंतरिक्ष में उड़ता है। यही कारण है कि मल्टीमॉड्यूलरिटी ( एक , दो ) के लिए संक्रमण पर कई रिपोर्ट शुरू होती हैं।
लेकिन किसी कारण से, एक ही समय में हर कोई यह भूल जाता है कि मोनोमॉड्यूलरिटी न केवल विधानसभा समय को प्रभावित करती है, बल्कि आपकी वास्तुकला को भी प्रभावित करती है। यहाँ सवालों का जवाब। आपका AppComponent कितना बड़ा है? क्या आप समय-समय पर उस कोड को देखते हैं जो A में किसी कारण से फीचर B की रिपॉजिटरी को खींचता है, हालांकि यह ऐसा नहीं होना चाहिए, ठीक है, या यह किसी भी तरह से अधिक शीर्ष-स्तर होना चाहिए? क्या सुविधाओं में किसी प्रकार का अनुबंध है? और आप सुविधाओं के बीच संचार को कैसे व्यवस्थित करते हैं? क्या कोई नियम हैं?
आपको लगता है कि हमने परतों के साथ समस्या को हल किया है, अर्थात्, ऊर्ध्वाधर रूप से सब कुछ ठीक लग रहा है, लेकिन क्षैतिज रूप से कुछ गलत हो रहा है? और सिर्फ पैकेट को तोड़ना और समीक्षा को नियंत्रित करने से समस्या हल नहीं होती है।

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

अपने लेख में मैं आपको यह बताना चाहता हूं कि मैं एक वास्तुकला की दृष्टि से बिल्कुल बहुविधता कैसे आया। किन समस्याओं ने मुझे परेशान किया, और मैंने उन्हें चरणों में हल करने का प्रयास कैसे किया। और अंत में, आप आंसू और दर्द के बिना मोनोमोड्युलरिटी से मल्टीमॉड्यूलरिटी पर स्विच करने के लिए एक एल्गोरिदम पाएंगे।

पहले सवाल का जवाब देते हुए, AppComponent कितना बड़ा है, मैं कबूल कर सकता हूं - बड़ा, वास्तव में बड़ा। और इसने मुझे लगातार सताया। यह कैसे हुआ? सबसे पहले, यह इस तरह के डि संगठन के कारण है। यह डीआई के साथ है कि हम शुरू करेंगे।

जैसे मैंने पहले DI किया था

मुझे लगता है कि कई लोगों ने अपने सिर में कुछ ऐसा बनाया है जो घटकों की निर्भरता और इसी स्कैप्स के इस आरेख के समान है:

हमारे यहाँ क्या है?

AppComponent , जिसने सिंगलटन स्कोप के साथ पूरी तरह से निर्भरता को अवशोषित किया। मुझे लगता है कि लगभग सभी के पास यह घटक है।

फ़ीचरकंप्यूटर । प्रत्येक सुविधा अपने स्वयं के दायरे के साथ थी और AppComponent या एक वरिष्ठ सुविधा का एक उपसमुच्चय था।
सुविधाओं पर थोड़ा ध्यान दें। सबसे पहले, एक विशेषता क्या है? मैं अपने शब्दों में कोशिश करूंगा। एक विशेषता एक तार्किक रूप से पूर्ण, अधिकतम स्वतंत्र प्रोग्राम मॉड्यूल है जो एक विशिष्ट उपयोगकर्ता समस्या को हल करता है, जिसमें स्पष्ट रूप से परिभाषित बाहरी निर्भरता है, और जो किसी अन्य प्रोग्राम में फिर से उपयोग करना अपेक्षाकृत आसान है। सुविधाएँ बड़ी और छोटी हो सकती हैं। सुविधाओं में अन्य सुविधाएँ हो सकती हैं। और वे स्पष्ट रूप से परिभाषित बाहरी निर्भरताओं के माध्यम से अन्य सुविधाओं का उपयोग या चला सकते हैं। यदि हम अपना एप्लिकेशन (Android के लिए Kaspersky Internet Security) लेते हैं, तो सुविधाओं को एंटी-वायरस, एंटी-थेफ्ट आदि माना जा सकता है।

स्क्रीनकंप्यूटर । एक विशेष स्क्रीन के लिए एक घटक, अपने स्वयं के दायरे के साथ भी और इसी सुविधा घटक का एक उपसमुच्चय भी है।

अब "ऐसा क्यों" की एक सूची

क्यों सब-पार्टनर?
घटक निर्भरता में, मुझे यह तथ्य पसंद नहीं आया कि एक घटक एक बार में कई घटकों पर निर्भर हो सकता है, जो कि मुझे ऐसा लग रहा था, अंततः घटकों और उनकी निर्भरता के कारण हो सकता है। जब आपके पास एक सख्त-से-कई संबंध (एक घटक और उसके अधीनस्थ) होते हैं, तो यह अधिक सुरक्षित और अधिक स्पष्ट होता है। इसके अलावा, डिफ़ॉल्ट रूप से, माता-पिता की सभी निर्भरताएँ उपसमुदाय के लिए उपलब्ध होती हैं, जो कि अधिक सुविधाजनक भी है।

हर सुविधा के लिए गुंजाइश क्यों है?
क्योंकि तब मैं इस विचार से आगे बढ़ा कि प्रत्येक सुविधा किसी न किसी प्रकार का अपना जीवन चक्र है, जो दूसरों के समान नहीं है, इसलिए अपना स्वयं का दायरा बनाना तर्कसंगत है। कई कंजूस चीजों के लिए एक और बिंदु है, जिसका मैं नीचे उल्लेख करूंगा।

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

तो, सब कुछ तर्कसंगत लगता है। लेकिन हमेशा की तरह, जीवन अपने स्वयं के समायोजन करता है।

जीवन की समस्याएं

उदाहरण कार्य

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


इन बटनों पर क्लिक करके हम स्कैनर या एंटी-थेफ्ट की सुविधा प्राप्त करते हैं।
स्कैनर की विशेषता पर विचार करें:


"एंटीवायरस शुरू करें स्कैनिंग" पर क्लिक करके कुछ प्रकार के स्कैनिंग कार्य किए जाते हैं, "मुझे खरीदें" पर क्लिक करके हम बस खरीदना चाहते हैं, अर्थात हम खरीद की सुविधा को खींचते हैं, लेकिन "सहायता" पर हम एक सरल स्क्रीन की मदद से प्राप्त करते हैं।
एंटी-थेफ्ट का फीचर लगभग एक जैसा दिखता है।

संभावित समाधान

डीआई के संदर्भ में हम इस उदाहरण को कैसे लागू करेंगे? कई विकल्प हैं।

पहला विकल्प

एक स्वतंत्र घटक के रूप में एक खरीद सुविधा का चयन करें जो केवल AppComponent पर निर्भर करता है।


लेकिन फिर हमें इस समस्या का सामना करना पड़ रहा है: एक ही बार में दो अलग-अलग ग्राफ़ (घटकों) से निर्भरता को एक कक्षा में कैसे इंजेक्ट किया जाए? केवल गंदे बैसाखी के माध्यम से, जो निश्चित रूप से, ऐसी चीज है।

दूसरा विकल्प

हम उपसमुदाय में खरीद सुविधा का चयन करते हैं, जो AppComponent पर निर्भर करता है। और स्कैनर और एंटी-थेफ्ट के घटकों को खरीद घटक से सब-कमर्स बनाया जा सकता है।


लेकिन, जैसा कि आप समझते हैं, अनुप्रयोगों में काफी समान स्थिति हो सकती है। और इसका मतलब यह है कि घटकों की निर्भरता की गहराई वास्तव में बहुत बड़ी और जटिल हो सकती है। और ऐसा ग्राफ आपके आवेदन को अधिक सुसंगत और समझने योग्य बनाने की तुलना में अधिक भ्रामक होगा।

तीसरा विकल्प

हम एक अलग घटक में नहीं, बल्कि एक अलग डैगर मॉड्यूल में खरीद सुविधा का चयन करते हैं। आगे दो तरीके संभव हैं।

पहला तरीका
आइए सभी निर्भरता के लिए सिंगलटन स्कोप की विशेषताएं जोड़ें और AppComponent से कनेक्ट करें।


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

दूसरा तरीका
यह एक एकल दायरे के लिए सभी सुविधाओं की कमी है, उदाहरण के लिए PerFeature ।


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

वास्तुदोष

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

इंटरमीडिएट के निष्कर्ष

तो, हम अंत में क्या चाहते हैं? हम किन समस्याओं को हल करना चाहते हैं? चलिए सीधे उस बिंदु पर जाते हैं, जो DI से शुरू होकर वास्तुकला की ओर बढ़ता है:

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

मैंने विशेष रूप से बहु-प्रतिरूपता के बारे में बहुत अंत में ही बात की थी। हम उसके पास पहुंचेंगे, हम खुद से आगे नहीं बढ़ेंगे।

"एक नए तरीके से रहना"

अब हम उपरोक्त विशलिस्ट को धीरे-धीरे लागू करने का प्रयास करेंगे।
चलो चलते हैं!

DI संवर्द्धन

उसी डीआई से शुरू करते हैं।

बड़ी संख्या में स्कोप से इनकार

जैसा कि मैंने ऊपर लिखा था, मेरे दृष्टिकोण से पहले यह था: हर सुविधा के लिए अपना स्वयं का दायरा। वास्तव में, इससे कोई विशेष लाभ नहीं हैं। केवल बड़ी संख्या में स्कोप और सिरदर्द की एक निश्चित मात्रा प्राप्त करें।
यह श्रृंखला काफी पर्याप्त है: सिंगलटन - PerFeature - PerScreen ।

घटक निर्भरता के पक्ष में उपकेंद्रों का परित्याग

पहले से ही एक और अधिक दिलचस्प बिंदु। सब -कंप्यूटरों के साथ , आपको अधिक सख्त पदानुक्रम लगता है, लेकिन साथ ही आपने पूरी तरह से हाथ बांध दिए हैं और किसी भी तरह से पैंतरेबाज़ी करने का कोई तरीका नहीं है। इसके अलावा, AppComponent सभी विशेषताओं के बारे में जानता है, और आपको एक विशाल जनरेटेड क्लास DaggerAppComponent भी मिलता है।
घटक निर्भरता के साथ , आपको एक सुपर शांत लाभ मिलता है। घटक निर्भरता में, आप घटकों को निर्दिष्ट नहीं कर सकते हैं , लेकिन स्वच्छ इंटरफेस (डेनिस और वोलोडा के लिए धन्यवाद)। इसके लिए धन्यवाद, आप अपनी पसंद के किसी भी इंटरफ़ेस को लागू कर सकते हैं, डैगर सब कुछ खा जाएगा। भले ही एक ही गुंजाइश वाला घटक यह कार्यान्वयन हो:

@Component( dependencies = FeatureDependencies.class, modules = FeatureModule.class ) @PerFeature public abstract class FeatureComponent { // ... } public interface FeatureDependencies { SomeDependency someDependency(); } @Component( modules = AnotherFeatureModule.class ) @PerFeature public abstract class AnotherFeatureComponent implements FeatureDependencies { // ... } 

DI संवर्द्धन से लेकर वास्तु संवर्द्धन तक

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

 public interface PurchaseFeatureDependencies { HttpClientApi httpClient(); } 

या स्कैनर सुविधा की बाहरी निर्भरता का इंटरफ़ेस:

 public interface ScannerFeatureDependencies { DbClientApi dbClient(); HttpClientApi httpClient(); SomeUtils someUtils(); //       PurchaseInteractor purchaseInteractor(); } 

जैसा कि डीआई पर अनुभाग में पहले ही उल्लेख किया गया है, निर्भरता किसी के द्वारा भी लागू की जा सकती है और जैसा आप चाहते हैं, ये शुद्ध इंटरफेस हैं, और हमारी विशेषताएं इस अतिरिक्त ज्ञान से मुक्त हो जाती हैं।

"शुद्ध" सुविधा का एक अन्य महत्वपूर्ण घटक एक स्पष्ट एपीआई की उपस्थिति है, जिसके द्वारा बाहरी दुनिया सुविधा तक पहुंच सकती है।
यहां खरीदारी के एप के फीचर्स दिए गए हैं:

 public interface PurchaseFeatureApi { PurchaseInteractor purchaseInteractor(); } 

यही है, बाहरी दुनिया एक PurchaseInteractor प्राप्त कर सकती है और इसके माध्यम से खरीदारी करने का प्रयास कर सकती है। दरअसल, ऊपर हमने देखा कि खरीद को पूरा करने के लिए स्कैनर को एक खरीद- बिक्रीकर्ता की आवश्यकता थी।

और यहाँ स्कैनर की एपीआई विशेषताएं हैं:

 public interface ScannerFeatureApi { ScannerStarter scannerStarter(); } 

और तुरंत मैं ScannerStarter का इंटरफ़ेस और कार्यान्वयन लाता हूं:

 public interface ScannerStarter { void start(Context context); } @PerFeature public class ScannerStarterImpl implements ScannerStarter { @Inject public ScannerStarterImpl() { } @Override public void start(Context context) { Class<?> cls = ScannerActivity.class; Intent intent = new Intent(context, cls); intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(intent); } } 

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

जैसा कि आप कल्पना कर सकते हैं, कुछ बिंदु होना चाहिए जो सुविधाओं, इसके कार्यान्वयन और निर्भरता की आवश्यक सुविधाओं को जोड़ता है। यह बिंदु डैगर घटक है।

मुझे लगता है कि आपके लिए कुछ नया नहीं है।

बहु-प्रतिरूपता के लिए संक्रमण

तो, आप और मैं इसकी निर्भरता और बाहरी एपीआई के एपीआई के माध्यम से सुविधा की सीमाओं को स्पष्ट रूप से परिभाषित करने में सक्षम थे। हमने यह भी पता लगाया कि कैसे इसे डैगर में क्रैंक किया जाता है। और अब हम अगले तार्किक और दिलचस्प कदम पर आते हैं - मॉड्यूल में विभाजन।
तुरंत एक परीक्षण मामला खोलें - यह आसान हो जाएगा।
आइए तस्वीर को सामान्य रूप से देखें:

और उदाहरण के पैकेज संरचना को देखें:

अब हर वस्तु पर ध्यान से बात करें।

सबसे पहले, हम चार बड़े ब्लॉकों को देखते हैं: एप्लिकेशन , एपीआई , इंप्ल और बर्तन । APIs , Impl, और Utils में, आप देख सकते हैं कि सभी मॉड्यूल कोर या या फीचर पर शुरू होते हैं। पहले उनके बारे में बात करते हैं।

कोर और फीचर में अलग होना

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

अब चार बड़े ब्लॉकों के बारे में: एप्लीकेशन, एपीआई, इम्पल और यूटिल्स

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

इसके अलावा, एपीआई मॉड्यूल किसी के बारे में कुछ नहीं जानता है, यह एक बिल्कुल अलग मॉड्यूल है।

utils
ऊपर दिए गए नियम के एकमात्र अपवाद को कुछ पूरी तरह से उपयोगितावादी चीजों के रूप में माना जा सकता है, जो इसे एपीआई और कार्यान्वयन में तोड़ने का कोई मतलब नहीं है।

impl
यहां हमारे पास कोर-इम्पैक्ट और फीचर-इम्प्लीमेंट में एक उपखंड है।
कोर-इम्प्लांट में मॉड्यूल भी पूरी तरह से स्वतंत्र हैं। उनका एकमात्र निर्भरता एपि मॉड्यूल है । एक उदाहरण के लिए, core-db-impl मॉड्यूल के build.gradle पर एक नज़र डालें:

 // bla-bla-bla dependencies { implementation project(':core-db-api') // bla-bla-bla } 

अब फीचर-इम्प्लांट के बारे में । एप्लिकेशन लॉजिक में शेर का हिस्सा पहले से ही है। सुविधा-निहित समूह के मॉड्यूल API या Utils समूह के मॉड्यूल के बारे में जान सकते हैं, लेकिन वे निश्चित रूप से Impl समूह के अन्य मॉड्यूल के बारे में कुछ भी नहीं जानते हैं।
जैसा कि हम याद करते हैं, बाहरी निर्भरता में सुविधा के सभी बाहरी निर्भरताएं जमा होती हैं। उदाहरण के लिए, स्कैन की एक विशेषता के लिए, यह एपीआई इस प्रकार दिखता है:

 public interface ScannerFeatureDependencies { // core-db-api DbClientApi dbClient(); // core-network-api HttpClientApi httpClient(); // core-utils SomeUtils someUtils(); // feature-purchase-api PurchaseInteractor purchaseInteractor(); } 

तदनुसार, build.gradle सुविधा-स्कैनर-इम्प्लान्ट इस तरह होगा:

 // bla-bla-bla dependencies { implementation project(':core-utils') implementation project(':core-network-api') implementation project(':core-db-api') implementation project(':feature-purchase-api') implementation project(':feature-scanner-api') // bla-bla-bla } 

आप पूछ सकते हैं, एपीई मॉड्यूल में बाहरी निर्भरता की एपीआई क्यों नहीं है? तथ्य यह है कि यह कार्यान्वयन का एक विवरण है। यही है, यह एक विशेष कार्यान्वयन है जिसे कुछ विशिष्ट निर्भरताओं की आवश्यकता है। निर्भरता एपीआई स्कैनर के लिए यहाँ है:


लघु वास्तुदोष
आइए उपरोक्त सभी को पचाएं और अपने लिए फीचर -...- इम्प्लांट-मॉड्यूल और अन्य मॉड्यूल पर उनकी निर्भरता के बारे में कुछ वास्तु बिंदुओं को समझें ।
मुझे एक मॉड्यूल के लिए दो सबसे लोकप्रिय निर्भरता मैपिंग पैटर्न मिले:

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

हमारे उदाहरण में, मैं एपीआई और केवल एपी (अच्छी तरह से, बर्तन-समूह) मॉड्यूल के ज्ञान की वकालत करता हूं। सुविधाओं को कार्यान्वयन के बारे में कुछ भी नहीं पता है।

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

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

आवेदन

ऐसा लगता है कि हमारे पास सुविधाओं, मॉड्यूल, उनकी निर्भरता के साथ एक पतला और समझने योग्य चित्र है और यह सब है। अब हम एक चरमोत्कर्ष पर आते हैं - यह एपीआई और उनके कार्यान्वयन का एक संयोजन है, जो सभी आवश्यक निर्भरताओं को प्रतिस्थापित करता है, आदि, लेकिन Gredloi मॉड्यूल के दृष्टिकोण से। कनेक्शन बिंदु आमतौर पर ऐप ही है।
वैसे, हमारे उदाहरण में, यह बिंदु अभी भी सुविधा-स्कैनर-उदाहरण है । उपरोक्त दृष्टिकोण आपको अपनी प्रत्येक सुविधा को एक अलग एप्लिकेशन के रूप में चलाने की अनुमति देता है, जो सक्रिय विकास के दौरान बिल्ड समय को बहुत बचाता है। ब्यूटी!

शुरुआत के लिए, आइए विचार करें कि ऐप के माध्यम से सब कुछ पहले से ही प्यार किए गए स्कैनर के उदाहरण के साथ कैसे होता है।

इसके आधार पर, हम एक डैगर घटक बना सकते हैं जो बाहरी निर्भरता के एप को लागू करता है:

 @Component(dependencies = { CoreUtilsApi.class, CoreNetworkApi.class, CoreDbApi.class, PurchaseFeatureApi.class }) @PerFeature interface ScannerFeatureDependenciesComponent extends ScannerFeatureDependencies { } 

मैंने इस इंटरफ़ेस को सुविधा के लिए ScannerFeatureComponent में रखा:

 @Component(modules = { ScannerFeatureModule.class, ScreenNavigationModule.class }, dependencies = ScannerFeatureDependencies.class) @PerFeature public abstract class ScannerFeatureComponent implements ScannerFeatureApi { // bla-bla-bla @Component(dependencies = { CoreUtilsApi.class, CoreNetworkApi.class, CoreDbApi.class, PurchaseFeatureApi.class }) @PerFeature interface ScannerFeatureDependenciesComponent extends ScannerFeatureDependencies { } } 

अब App। ऐप को उन सभी मॉड्यूल के बारे में पता है जिनकी इसे ज़रूरत है ( कोर-, फ़ीचर-, एपीआई, इम्प्लान्ट )

 // bla-bla-bla dependencies { implementation project(':core-utils') implementation project(':core-db-api') implementation project(':core-db-impl') implementation project(':core-network-api') implementation project(':core-network-impl') implementation project(':feature-scanner-api') implementation project(':feature-scanner-impl') implementation project(':feature-antitheft-api') implementation project(':feature-antitheft-impl') implementation project(':feature-purchase-api') implementation project(':feature-purchase-impl') // bla-bla-bla } 

इसके बाद, एक सहायक वर्ग बनाएं। उदाहरण के लिए, FeatureProxyInjector । यह सभी घटकों को सही ढंग से आरंभ करने में मदद करेगा, और यह इस वर्ग के माध्यम से है कि हम सुविधाओं की ओर मुड़ेंगे। आइए देखें कि स्कैनर सुविधा घटक को कैसे आरंभ किया जाता है:

 public class FeatureProxyInjector { // another... public static ScannerFeatureApi getFeatureScanner() { return ScannerFeatureComponent.initAndGet( DaggerScannerFeatureComponent_ScannerFeatureDependenciesComponent.builder() .coreDbApi(CoreDbComponent.get()) .coreNetworkApi(CoreNetworkComponent.get()) .coreUtilsApi(CoreUtilsComponent.get()) .purchaseFeatureApi(featurePurchaseGet()) .build() ); } } 

बाह्य रूप से, हम फ़ीचर इंटरफ़ेस ( ScannerFeatureApi ) देते हैं, और अंदर हम केवल संपूर्ण कार्यान्वयन निर्भरता ग्राफ़ ( ScannerFeatureComponent.initAndGet (...) विधि के माध्यम से ) को आरंभ करते हैं।
DaggerPurchaseComponent_PurchaseFeatureDependenciesComponent , Dagger द्वारा बनाई गई PurchaseFeatureD dependenciesComponent का कार्यान्वयन है, जिसके बारे में हमने ऊपर बात की थी, जहाँ हम बिल्डर में एपीआई-मॉड्यूल के कार्यान्वयन को प्रतिस्थापित करते हैं।
यह सब जादू है। फिर से उदाहरण देखें।

उदाहरण की बात कर रहे हैं। उदाहरण के लिए, हमें सभी बाहरी निर्भरताओं को भी पूरा करना होगा : फ़ीचर-स्कैनर-इम्पैक्ट । लेकिन चूंकि यह एक उदाहरण है, इसलिए हम डमी कक्षाओं को स्थानापन्न कर सकते हैं।
यह कैसा दिखेगा:

 //     ScannerFeatureDependencies public class ScannerFeatureDependenciesFake implements ScannerFeatureDependencies { @Override public DbClientApi dbClient() { return new DbClientFake(); } @Override public HttpClientApi httpClient() { return new HttpClientFake(); } @Override public SomeUtils someUtils() { return CoreUtilsComponent.get().someUtils(); } @Override public PurchaseInteractor purchaseInteractor() { return new PurchaseInteractorFake(); } } //  -  Application-   public class ScannerExampleApplication extends Application { @Override public void onCreate() { super.onCreate(); ScannerFeatureComponent.initAndGet( // ,     =) new ScannerFeatureDependenciesFake() ); } } 

और स्कैनर सुविधा उदाहरण में ही प्रकट के माध्यम से लॉन्च की गई है, ताकि अतिरिक्त खाली गतिविधि को अवरुद्ध न करें:

 <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.scanner_example"> <application android:name=".ScannerExampleApplication" android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme"> <!--   --> <activity android:name="com.example.scanner.presentation.view.ScannerActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest> 

मोनोमॉड्यूलरिटी से मल्टीमॉड्यूलरिटी में संक्रमण का एल्गोरिदम

जीवन एक कठोर चीज है। और वास्तविकता यह है कि हम सभी लिगेसी के साथ काम करते हैं। अगर कोई अब एक नया प्रोजेक्ट देख रहा है, जहां आप तुरंत सब कुछ आशीर्वाद दे सकते हैं, तो मैं आपसे ईर्ष्या करता हूं, भाई। लेकिन मेरे साथ ऐसा नहीं है, और वह आदमी भी गलत है =)।

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

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

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

   //     ScannerFeatureDependencies  app- public class ScannerFeatureDependenciesLegacy implements ScannerFeatureDependencies { @Override public DbClientApi dbClient() { return new DbClientLegacy(); } @Override public HttpClientApi httpClient() { // -  // ,      return NetworkFabric.createHttpClientLegacy(); } @Override public SomeUtils someUtils() { return new SomeUtils(); } @Override public PurchaseInteractor purchaseInteractor() { return new PurchaseInteractorLegacy(); } } //  -   ScannerFeatureComponent.initAndGet( new ScannerFeatureDependenciesLegacy() ); 

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

यहाँ इस तरह के एक सरल लेकिन काम करने वाला एल्गोरिदम है जो आपको अपने लक्ष्य की ओर कदम बढ़ाने की अनुमति देता है।

अतिरिक्त सुझाव

कितनी बड़ी / छोटी सुविधाएँ होनी चाहिए?
यह सब परियोजना आदि पर निर्भर करता है। लेकिन बहु-प्रतिरूपता के लिए संक्रमण की शुरुआत में, मैं आपको बड़े टुकड़ों में विभाजित करने की सलाह देता हूं। आगे, यदि आवश्यक हो, तो आप इन मॉड्यूल से अधिक मॉड्यूल का चयन करेंगे। लेकिन पीसना नहीं है। : / = .

app-
app , . , , - , , . , app , , , . app , , api- impl- , app .
:adapter , api impl, app api. , . clean_app . , Moxy, MoxyReflector, , - :stub-moxy-java . , .
. , . , app , , .

. , , , , DI.
, , (Mobius 2018 Piter, ).
Gradle. api implementation gradle . , .
, , ! !