🍍 💪🏿 🐣 "नया" होना या न होना ... 👉🏿 🌵 🍥

फिर से हैलो। Android विकास पर बुनियादी और उन्नत पाठ्यक्रमों की शुरुआत की प्रत्याशा में , हमने आपके लिए एक और दिलचस्प अनुवाद तैयार किया है।

निर्भरता इंजेक्शन हमें नए ऑपरेटरों और आवेदन तर्क को अलग करने की आवश्यकता है। यह अलगाव आपको अपने कोड में कारखानों का उपयोग करने के लिए प्रोत्साहित करता है जो आपके आवेदन को लिंक करने के लिए जिम्मेदार हैं । हालाँकि, कारखानों को लिखने के बजाय, हमबाध्यकारी लेने केलिए स्वत: निर्भरता इंजेक्शन , जैसे GUICE काउपयोगकरेंगे। लेकिन क्या निर्भरता इंजेक्शन वास्तव में हमें सभी नए ऑपरेटरों से बचा सकता है?
आइए दो चरम सीमाओं को देखें। मान लें कि आपके पास एक MusicPlayer वर्ग है जिसे AudioDevice मिलना चाहिए। यहां हम निर्भरता इंजेक्शन का उपयोग करना चाहते हैं और MusicPlayer कंस्ट्रक्टर में एक AudioDevice का अनुरोध कर सकते हैं। यह हमें एक परीक्षण-अनुकूल ऑडियोडेविस जोड़ने की अनुमति देगा, जिसका उपयोग हम यह दावा करने के लिए कर सकते हैं कि सही ध्वनि हमारे म्यूज़िकपेयर से निकलती है। यदि हम अंतर्निहित ऑपरेटर का निर्माण करने के लिए नए ऑपरेटर का उपयोग करते हैं, तो हम कुछ परीक्षण कठिनाइयों का सामना करेंगे। तो चलिए AudioDevice या MusicPlayer जैसी वस्तुओं को “इंजेक्टेबल” कहते हैं। इंजेक्टेबल वे ऑब्जेक्ट हैं जो आप कंस्ट्रक्टरों में अनुरोध करेंगे और उम्मीद करेंगे कि निर्भरता को लागू करने की रूपरेखा आपको उनके साथ प्रदान करेगी।

अब दूसरे अति पर। मान लें कि आपके पास एक इंटिमेट प्राइमर है, लेकिन आप इसे इंटेगर में ऑटो-पैक करना चाहते हैं, सबसे सरल है कि नए इंटेगर (5) को कॉल करें, और यही अंत है। लेकिन अगर निर्भरता इंजेक्शन नया "नया" है, तो हम नए इन-लाइन क्यों कहते हैं? क्या इससे हमारे परीक्षण को ठेस पहुंचेगी? यह पता चलता है कि निर्भरता को इंजेक्ट करने के लिए रूपरेखा आपको वह इंटीजर नहीं दे सकती है जिसकी आपको आवश्यकता है, क्योंकि वे समझ नहीं पाते हैं कि इंटेगर किस तरह का है। यह एक खिलौना उदाहरण का एक सा है, तो चलो कुछ और जटिल देखें।

मान लीजिए कि एक उपयोगकर्ता ने लॉगिन फ़ील्ड में एक ईमेल पता दर्ज किया है, और आपको नया ईमेल कॉल करना होगा («a@b.com») क्या हम इसे इस तरह छोड़ सकते हैं, या हमें अपने निर्माता में ईमेल का अनुरोध करना चाहिए? फिर से, निर्भरता इंजेक्शन फ्रेमवर्क आपको ईमेल प्रदान नहीं कर सकता है, क्योंकि आपको सबसे पहले उस स्ट्रिंग को प्राप्त करना होगा जिसमें ईमेल स्थित है। और चुनने के लिए बहुत सारे स्ट्रिंग एस हैं। जैसा कि आप देख सकते हैं, कई वस्तुएं हैं जो निर्भरता इंजेक्शन ढांचा कभी भी प्रदान नहीं कर सकती हैं। चलो उन्हें "न्यूएबल" कहते हैं, क्योंकि आपको मैन्युअल रूप से उनके लिए नया कॉल करने के लिए मजबूर किया जाएगा ।

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

आइए MusicPlayer और Song के उदाहरण को देखें

class Song {
  Song(String name, byte[] content);
}
class MusicPlayer {
  @Injectable
  MusicPlayer(AudioDevice device);
  play(Song song);
}

ध्यान दें कि सॉन्ग केवल ऑब्जेक्ट्स पर सवाल उठाता है जो न्यूएबल हैं। इससे एक टेस्ट में सॉन्ग को इंस्टेंट करना बहुत आसान हो जाता है। MusicPlayer अपने ऑडियोडेविस तर्क की तरह पूरी तरह से इंजेक्टेबल है, इसलिए इसे निर्भरता इंजेक्शन के लिए रूपरेखा से प्राप्त किया जा सकता है।

अब देखते हैं कि अगर MusicPlayer नियम को तोड़ता है और इसके निर्माण में Newable का अनुरोध करता है तो क्या होता है।

class Song {
  String name;
  byte[] content;
  Song(String name, byte[] content);
}
class MusicPlayer {
  AudioDevice device;
  Song song;
  @Injectable
  MusicPlayer(AudioDevice device, Song song);
  play();
}

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

अब देखते हैं कि अगर सॉन्ग नियम को तोड़ता है और इसके निर्माण में इंजेक्शन लगाने का अनुरोध करता है।

class MusicPlayer {
  AudioDevice device;
  @Injectable
  MusicPlayer(AudioDevice device);
}
class Song {
  String name;
  byte[] content;
  MusicPlayer palyer;
  Song(String name, byte[] content, MusicPlayer player);
  play();
}
class SongReader {
  MusicPlayer player
  @Injectable
  SongReader(MusicPlayer player) {
    this.player = player;
  }
  Song read(File file) {
    return new Song(file.getName(),
                    readBytes(file),
                    player);
  }
}

पहली नज़र में, सब कुछ ठीक है। लेकिन सोचिए कि गाने कैसे बनाए जाएंगे। संभवतः, गाने डिस्क पर संग्रहीत हैं, इसलिए हमें SongReader की आवश्यकता है। SongReader को MusicPlayer से अनुरोध करना होगा ताकि Song के लिए नया कॉल करते समय, वह MusicPlayer पर Song की निर्भरता को पूरा कर सके। क्या आपने यहाँ कुछ गलत देखा है? MusicRlayer के बारे में SongReader को क्या डर है? यह Demeter कानून का उल्लंघन है। SongReader को MusicPlayer के बारे में नहीं पता होना चाहिए। कम से कम क्योंकि SongReader MusicPlayer के साथ तरीकों को कॉल नहीं करता है। वह केवल MusicPlayer के बारे में जानता है क्योंकि Song ने Newable / Injectable जुदाई का उल्लंघन किया है। SongReader सॉन्ग में त्रुटि के लिए भुगतान करता है। चूँकि वह स्थान जहाँ त्रुटि की जाती है और जहाँ परिणाम सामने आते हैं, वही बात नहीं है, यह त्रुटि बहुत ही सूक्ष्म है और इसका निदान करना कठिन है। इसका मतलब यह भी है कि कई लोगों से यह गलती होने की संभावना है।

परीक्षण के संदर्भ में, यह एक वास्तविक दर्द है। मान लीजिए कि आपके पास SongWriter है और यह सुनिश्चित करना चाहता है कि यह Song को डिस्क पर सही ढंग से क्रमबद्ध करता है। आपको एक MockMusicPlayer बनाने की आवश्यकता है ताकि आप इसे सॉन्ग को पास कर सकें ताकि आप इसे सोंगवर्टर को पास कर सकें। हम भी यहाँ MusicPlayer में क्यों आते हैं? आइए इसे दूसरे तरीके से देखें। गीत वह है जिसे आप क्रमबद्ध करना चाहते हैं, और ऐसा करने का सबसे आसान तरीका जावा क्रमांकन का उपयोग करना है। इस प्रकार, हम न केवल सॉन्ग, बल्कि म्यूजिकपेयर और ऑडियोडेविस को भी सीरियल करते हैं। न तो MusicPayer और न ही AudioDevice को क्रमबद्ध किया जाना चाहिए। जैसा कि आप देख सकते हैं, छोटे परिवर्तन परीक्षण क्षमता को बहुत सुविधाजनक बनाते हैं।

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

अब कुछ अति सूक्ष्म पर ध्यान दें। न्यूजेबल के लिए इंजेक्शन के बारे में जानना सामान्य है। जो सामान्य नहीं है वह यह है कि न्यूबल में एक क्षेत्र के रूप में इंजेक्टेबल का संदर्भ है। दूसरे शब्दों में, सॉन्ग MusicPlayer के बारे में जान सकता है। उदाहरण के लिए, इंजेक्टेबल म्यूज़िकप्लेयर को स्टैग के माध्यम से न्यूबल सॉन्ग में भेजना सामान्य है। क्योंकि स्टैक से गुजरना निर्भरता इंजेक्शन के लिए रूपरेखा से स्वतंत्र है। इस उदाहरण में पसंद करें:

class Song {
  Song(String name, byte[] content);
  boolean isPlayable(MusicPlayer player);
}

समस्या तब होती है जब सॉन्ग का म्यूज़िकप्लेयर का लिंक फील्ड होता है। लिंक फ़ील्ड्स को कंस्ट्रक्टर के माध्यम से सेट किया जाता है, जो कॉल करने वाले के लिए Demeter कानून का उल्लंघन और हमारे परीक्षणों के लिए कठिनाइयों का कारण होगा ।

"नया" होना या न होना ...

पाठ्यक्रमों के बारे में अधिक जानें

More articles: