डैगर 2 @Binds बनाम @Provides

Dagger 2.12 की शुरुआत (क्षमा करें, मुझे इसके कुछ समय पहले पता है .. लेकिन अभी भी इसे समझने लायक है), @Binds नामक इस नई सुविधा को Daggers में जोड़ा गया है। इसके बारे में पहले से ही कुछ ब्लॉग हैं। हालाँकि उन्हें पढ़ना मुझे अभी भी आश्चर्यचकित करता है कि पुराने वफादार @Provides को इससे क्या फायदा है जो हमारे मॉड्यूल में है।

जैसा कि मेरा लक्ष्य चीजों को यथासंभव स्पष्ट करना है, इसलिए मैं इस पर अपनी जांच करने के बाद यह लिख रहा हूं, एक तरह से जो मेरे सवालों को साफ करता है।

कोडिंग की अवधि में क्या भिन्न है

@Provides

@Module
वर्ग MyModule {
    @Provides
    मज़ा getInjectClass (इंजेक्टऑब्जेक्ट: InjectClass): InjectInterface {
        इंजेक्ट करें
    }
}

class InjectClass @Inject constructor (): InjectInterface
इंटरफ़ेस InjectInterface

@Binds

@Module
सार वर्ग MyModule {
    @Binds
    अमूर्त मज़ा getInjectClass (इंजेक्टऑब्जेक्ट: InjectClass):
        InjectInterface
}

class InjectClass @Inject constructor (): InjectInterface
इंटरफ़ेस InjectInterface

ऊपर से, @Provides पर @Binds का कोई स्पष्ट स्पष्ट लाभ नहीं है। एक अमूर्त वर्ग और कार्य में बदल गया, जबकि दूसरा एक ठोस है। यह किसी भी वाचालता (या बॉयलरप्लेट) को कम नहीं करता है।

तो @Binds का क्या फायदा?

यह जानने के लिए, आइए कुछ इतिहास देखें

ऐतिहासिक रूप से ...

डैगर के बहुत प्रारंभिक चरण में, @Module जैसी कोई चीज़ नहीं है। @Module वास्तव में Dagger 2 को काम करने के लिए आवश्यक नहीं है (दुनिया का सबसे छोटा डैगर 2 कोड देखें)।

हालांकि लोग शिकायत करते हैं और संबंधित आश्रितों को एक साथ समूह बनाना चाहते हैं। इसलिए डैगर 2 डेवलपर ने @Module के नाम से प्रसिद्ध इस फीचर कॉल को बनाया और बनाया, जिसके कई लोगों के अनुसार इसके लाभ हैं।

बहरहाल, @Provides के साथ @Module का अस्तित्व उत्पन्न कोड में कुछ ओवरहेड का परिचय देता है। इसलिए @Binds को मदद के लिए पेश किया गया था।

इसे मुझे साबित करें…

उपरोक्त कोड का उपयोग करना, (साथ में @Component जो ऊपर दिए गए कोड स्निपेट में नहीं दिखाया गया है) ... अलग से जांच करें

अतिरिक्त मॉड्यूल कारखाना कक्षाएं

नीचे उत्पन्न कक्षाएं हैं।

ध्यान दें कि @Provides MyModule_GetInjectClassFactory वर्ग बनाता है, जो @Binds में मौजूद नहीं है

वर्ग कैसा दिखता है? वाह, काफ़ी कोड ..

इसके अलावा, यह केवल एक InjectClass के लिए है। लेकिन अगर हमारे पास उनके मॉड्यूल में 1 से अधिक हैं, तो उनमें से प्रत्येक स्वयं एक कारखाना वर्ग उत्पन्न करेगा

@Provides
मजेदार getInjectClass (इंजेक्टऑब्जेक्ट: InjectClass): InjectInterface {
    इंजेक्ट करें
}
@Provides
मज़ा getInjectClass2 (injectObject2: InjectClass2): InjectInterface2 {
    इंजेक्टओबजेक्ट २
}
@Provides
मज़ा getInjectClass3 (injectObject3: InjectClass3): InjectInterface3 {
    इंजेक्ट करेंऑबजेक्ट 3
}

कल्पना कीजिए कि हमारे डेक्सकाउंट और ऐप के आकार में कैसे जोड़ा जाएगा !!

मॉड्यूल आवरण की अतिरिक्त परत

अतिरिक्त मॉड्यूल फैक्टर वर्ग के अलावा, यदि हम बनाए गए हमारे DaggerMyComponent वर्ग की जांच करते हैं, तो हमें कोड आकार अलग दिखाई देगा।

@Provides कोड की 52 लाइनें उत्पन्न करता है, और @Binds केवल 29 लाइनें (~ 40% की कमी) कोड उत्पन्न करता है।

यदि आप कोड का पता लगाते हैं तो आप नीचे दिए गए प्रवाह को देखेंगे।

InjectObject बनाने में कितना संक्षिप्त @Binds देखो?

संक्षेप में, न केवल @ बाइंड्स लाइनों की संख्या को कम करते हैं, यह ऑब्जेक्ट निर्माण के साथ-साथ ऑपरेशन प्रवाह को भी कम करता है।

तो चलो सब कुछ @Binds में बदल गया है?

दुर्भाग्य से, @Binds केवल नीचे के नियमों के आधार पर काम करता है

@ बाइंड विधियों में केवल एक पैरामीटर होना चाहिए जिसका प्रकार वापसी प्रकार के लिए उपलब्ध है

तो केवल एक ही पैरामीटर, और टाइप रिटर्न आमतौर पर दिए गए पैरामीटर ऑब्जेक्ट का इंटरफ़ेस है।

यह कहने के बाद कि, अन्य टिप्स @Provides के लिए स्थिर फ़ंक्शन का उपयोग करने पर विचार कर रहे हैं जो कुछ उत्पन्न कोड को कम करने में भी मदद करेगा।

अधिक जानकारी प्राप्त करने के लिए नीचे दिए गए ब्लॉग के भाग 1 अनुभाग को देखें (ऊपर पढ़ने के बाद, आपको नीचे दिए गए ब्लॉग की स्पष्ट समझ मिल सकती है)

मुझे उम्मीद है कि यह पोस्ट आपके लिए उपयोगी है। आप यहाँ मेरे अन्य रोचक विषयों की जाँच कर सकते हैं।

Android, Kotlin आदि संबंधित विषयों पर छोटे सुझावों और सीखने के लिए मुझे माध्यम, ट्विटर या फेसबुक पर फॉलो करें। ~ Elye ~