कन्स्ट्रक्टर-आधारित और सेटर-आधारित इंजेक्शन मिश्रण एक बुरी चीज है?

Question

मेरे पास CSV फ़ाइल ऑपरेशन से उत्पादों के आयात के लिए एक वर्ग है जिसके लिए लगभग 7 पैरामीटर की आवश्यकता होती है। यह एक जानकारी है जिसे आयातक के लिए निश्चित रूप से जरूरी है।

इन सभी पैरामीटरों का जीवन जीवन एक ही है। अंत में हमारे पास Immutable Object होना चाहिए।

मैं उन सभी को कन्स्ट्रक्टर में सूचीबद्ध करने के लिए बहुत डर गया था क्योंकि इसकी पठनीयता को प्रभावित किया गया था और उनमें से 3 को सेटर्स इंजेक्शन में स्थानांतरित करने का फैसला किया गया था। लेकिन जाहिर है यह एक सुरुचिपूर्ण समाधान नहीं है।

सवाल:

1) एक बुरा व्यवहार मिश्रण निर्माता आधारित और सेटर आधारित इंजेक्शन है?

2) इस विशेष समस्या को कैसे हल किया जा सकता है?

मैं मार्टिन फाउलर द्वारा "पैरामीटर ऑब्जेक्ट पेश करने" को लागू करने के बारे में सोच रहा था, लेकिन इसमें कोई समस्या है।

4 पैरामीटर्स को पैरामीटर ऑब्जेक्ट में आसानी से स्थानांतरित किया जा सकता है (ग्राहक आईडी, प्रोजेक्टआईडी, भाषा आईडी आदि) - सभी पूर्णांक।

अन्य 3 पैरामीटर एक वस्तु है जिसे मैं इंजेक्ट करता हूं (यह नकली इकाई-परीक्षणों के लिए आवश्यक है)।

Answer 1

कन्स्ट्रक्टर इंजेक्शन और प्रॉपर्टी इंजेक्शन को मिश्रण करना जरूरी नहीं है, लेकिन यह सामान्य नहीं हो सकता है। एक समग्र रणनीति के रूप में, संपत्ति इंजेक्शन से बचें क्योंकि यह सही ढंग से कार्यान्वित करना अधिक कठिन है (यह काउंटर-अंतर्ज्ञानी लग सकता है, लेकिन यह सच है)।

प्रत्येक पैटर्न का उपयोग कब करना है यह समझना महत्वपूर्ण है।

• कन्स्ट्रक्टर इंजेक्शन आपका डिफ़ॉल्ट इंजेक्शन पैटर्न होना चाहिए। यह कार्यान्वित करने के लिए अति-आसान है और इनवेरिएंट की गारंटी दे सकता है: इसे उपभोक्ता के आविष्कारों को सुनिश्चित करने के लिए केवल पढ़ने के लिए फ़ील्ड को असाइन करें।
• संपत्ति इंजेक्शन का उपयोग तब किया जा सकता है जब आपके पास स्थानीय डिफ़ॉल्ट कार्यान्वयन हो, लेकिन आप Open/Closed Principle का पालन करना चाहते हैं और उन्नत उपयोगकर्ताओं को वैकल्पिक कार्यान्वयन प्रदान करके कक्षा का विस्तार करने की अनुमति देते हैं।

आप क्योंकि निर्माता सौंदर्य प्रसाधन की संपत्ति इंजेक्शन लागू नहीं किया जाना चाहिए।

जब आपको बहुत अधिक निर्भरताओं की आवश्यकता होती है, तो यह एक संकेत है कि आप Single Responsibility Principle का उल्लंघन कर रहे हैं - कक्षा बस एक बार में बहुत अधिक करने की कोशिश कर रही है।

बजाय एक पैरामीटर ऑब्जेक्ट (अन्यथा एक अच्छा सुझाव) शुरू करने की

, एक बेहतर विकल्प एक को समेकित करना सेवा कि इन निर्भरता की बातचीत orchestrates में निर्भरता के दो या अधिक संपुटित है।

कल्पना कीजिए कि अपने प्रारंभिक निर्माता इस तरह दिखता है:

public MyClass(IDep1 dep1, IDep2 dep2, IDep3 dep3, IDep4 dep4, IDep5 dep5) 

विश्लेषण का एक सा लागू करने के बाद, आप यह पता लगाने की है कि इस मामले में IDep1, IDep3 और IDep4 एक खास तरह से एक साथ इस्तेमाल किया जाएगा।

public class AggService : IAggService 
{ 
    public AggService(IDep1 dep1, IDep3 dep3, IDep4 dep4) 
    { 
     // ... 
    } 

    // ... 
} 

अब आप यह करने के लिए मूल निर्माता पुनर्लेखन कर सकते हैं:: यह आपको एक एकत्रीकरण सेवा है कि समझाया इन इस तरह पेश करने की अनुमति देगा

public MyClass(IAggService aggSrvc, IDep2 dep2, IDep5 dep5) 

और बहुत आगे है ...

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