यह मानते हुए कि आप एक नकली ढांचे की तलाश नहीं कर रहे हैं, क्योंकि वे अल्ट्रा-सर्वव्यापी हैं और खोजने में आसान हैं , कुछ चीजें हैं जो ध्यान देने योग्य हैं:
- वहाँ "कभी नहीं" कुछ भी है जो आपको "हमेशा" करना चाहिए।
किसी तीसरे पक्ष के पुस्तकालय को लपेटना हमेशा अच्छा नहीं होता है। यदि आपका आवेदन आंतरिक रूप से एक पुस्तकालय पर निर्भर है, या यदि यह सचमुच एक या दो मुख्य पुस्तकालयों के आसपास बनाया गया है, तो इसे लपेटने में अपना समय बर्बाद न करें। यदि पुस्तकालय बदलते हैं, तो आपके आवेदन को वैसे भी बदलना होगा ।
- एकीकरण परीक्षणों का उपयोग करना ठीक है।
यह सीमाओं के आसपास विशेष रूप से सच है जो आपके आवेदन के लिए स्थिर, आंतरिक हैं, या आसानी से मजाक नहीं किया जा सकता है। उन शर्तों को पूरा कर रहे हैं, रैपिंग और मजाक होगा जटिल और थकाऊ हो। उस मामले में, मैं दोनों से बचना चाहता हूं: लपेटो मत और मॉक मत करो; सिर्फ एकीकरण परीक्षण लिखें। (यदि स्वचालित परीक्षण एक लक्ष्य है।)
- उपकरण और रूपरेखा तार्किक जटिलता को समाप्त नहीं कर सकते हैं।
सिद्धांत रूप में, एक उपकरण केवल बॉयलरप्लेट पर कट सकता है। लेकिन, एक जटिल इंटरफ़ेस लेने और इसे सरल बनाने के लिए कोई स्वचालित-सक्षम एल्गोरिदम नहीं है - अकेले इंटरफ़ेस एक्स को लेने दें और इसे अपनी आवश्यकताओं के अनुरूप करने के लिए अनुकूल करें। (केवल आप उस एल्गोरिथ्म को जानते हैं !) इसलिए, जबकि निस्संदेह ऐसे उपकरण हैं जो पतले आवरण उत्पन्न कर सकते हैं , मेरा सुझाव है कि वे पहले से ही सर्वव्यापी नहीं हैं क्योंकि, अंत में, आपको अभी भी समझदारी से कोड करने की आवश्यकता है, और इसलिए मैन्युअल रूप से, इंटरफेस के खिलाफ भले ही वह एक रैपर के पीछे छिपा हो।
उस ने कहा, ऐसी रणनीतियाँ हैं जिनका उपयोग आप कई भाषाओं में सीधे एक कक्षा में संदर्भित करने से बचने के लिए कर सकते हैं। और कुछ मामलों में, आप एक इंटरफ़ेस या पतले आवरण को "फ़ैग्न" कर सकते हैं जो वास्तव में मौजूद नहीं है। C # में, उदाहरण के लिए, मैं दो मार्गों में से एक जाऊंगा:
- एक कारखाने और अंतर्निहित टाइपिंग का उपयोग करें ।
आप इस छोटे कॉम्बो के साथ एक जटिल वर्ग को पूरी तरह से लपेटने के प्रयास से बच सकते हैं:
// "factory"
class PdfDocumentFactory {
public static ExternalPDFLibraryDocument Build() {
return new ExternalPDFLibraryDocument();
}
}
// code that uses the factory.
class CoreBusinessEntity {
public void DoImportantThings() {
var doc = PdfDocumentFactory.Build();
// ... i have no idea what your lib does, so, I'm making stuff but.
// but, you can do whatever you want here without explicitly
// referring to the library's actual types.
doc.addHeader("Wee");
doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return doc.exportBinaryStreamOrSomething();
}
}
यदि आप इन वस्तुओं को सदस्यों के रूप में संग्रहीत करने से बच सकते हैं, या तो अधिक "कार्यात्मक" दृष्टिकोण के माध्यम से या उन्हें एक शब्दकोश (या जो भी ) में संग्रहीत करके , इस दृष्टिकोण को आपके मुख्य व्यवसाय संस्थाओं के बिना संकलन-समय प्रकार की जाँच का लाभ है जो वास्तव में जानना आवश्यक है वे किस वर्ग के साथ काम कर रहे हैं
यह आवश्यक है कि संकलित समय पर, आपके कारखाने द्वारा लौटाए गए वर्ग में वास्तव में उस पर विधियां हों, जो आपके व्यावसायिक ऑब्जेक्ट का उपयोग कर रहा हो।
- डायनामिक टाइपिंग का उपयोग करें ।
यह अंतर्निहित टाइपिंग का उपयोग करने के रूप में एक ही नस में है , लेकिन इसमें एक और ट्रेडऑफ़ शामिल है: आप संकलन-प्रकार की जांच खो देते हैं और कक्षा के सदस्यों के रूप में बाहरी निर्भरता को जोड़ने और अपनी निर्भरता को इंजेक्ट करने की क्षमता प्राप्त करते हैं ।
class CoreBusinessEntity {
dynamic Doc;
public void InjectDoc(dynamic Doc) {
Doc = doc;
}
public void DoImortantThings() {
Doc.addHeader("Wee");
Doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return Doc.exportBinaryStreamOrSomething();
}
}
इन दोनों युक्तियों के साथ, जब मॉक करने का समय आता है ExternalPDFLibraryDocument, जैसा कि मैंने पहले कहा था, आपके पास करने के लिए कुछ काम है - लेकिन, यह वह काम है जिसे आपको वैसे भी करने की आवश्यकता होगी । और, इस निर्माण के साथ, आप थकाऊ रूप से 100 छोटे पतले रैपर वर्गों को परिभाषित करने से बचते रहे हैं। आपने लाइब्रेरी को बिना देखे सीधे उपयोग कर लिया है - अधिकांश भाग के लिए।
उस सभी के साथ, तीन बड़े कारण हैं जिन पर मैं अभी भी स्पष्ट रूप से तीसरे पक्ष के पुस्तकालय को लपेटने पर विचार करूंगा - जिनमें से कोई भी एक उपकरण या ढांचे का उपयोग करने में संकेत नहीं देगा:
- विशिष्ट पुस्तकालय आवेदन के लिए आंतरिक नहीं है ।
- इसे लपेटे बिना स्वैप करना बहुत महंगा होगा ।
- मुझे एपीआई ही पसंद नहीं है।
अगर मुझे उन तीनों क्षेत्रों में कुछ स्तर की चिंता नहीं है, तो आप इसे लपेटने के लिए कोई महत्वपूर्ण प्रयास नहीं करते हैं । और, अगर आपको तीनों क्षेत्रों में कुछ चिंता है, तो ऑटो-जेनरेट किया हुआ पतला रैपर वास्तव में मदद करने वाला नहीं है।
यदि आपने एक पुस्तकालय को लपेटने का निर्णय लिया है, तो आपके समय का सबसे प्रभावी और प्रभावी उपयोग आपके इच्छित इंटरफ़ेस के खिलाफ अपने आवेदन का निर्माण करना है ; मौजूदा एपीआई के खिलाफ नहीं।
एक और तरीका रखो, शास्त्रीय सलाह पर ध्यान दिया: हर निर्णय को स्थगित करें जो आप कर सकते हैं। पहले अपने आवेदन की "कोर" बनाएँ। इंटरफेस के खिलाफ कोड जो अंततः आप चाहते हैं, जो अंततः "परिधीय सामान" द्वारा पूरा किया जाएगा जो अभी तक मौजूद नहीं है। आवश्यकतानुसार अंतराल को पाट दें।
यह प्रयास समय की बचत जैसा महसूस नहीं हो सकता है ; लेकिन अगर आपको लगता है कि आपको एक रैपर की जरूरत है, तो यह सुरक्षित रूप से करने का सबसे कारगर तरीका है ।
इस पर इस तरीके से विचार करें।
आपको अपने कोड के कुछ अंधेरे कोने में इस लाइब्रेरी के खिलाफ कोड करने की आवश्यकता है - भले ही यह लिपटे हो। यदि आप परीक्षण के दौरान पुस्तकालय का मज़ाक उड़ाते हैं, तो वहाँ अनुपयोगी मैनुअल प्रयास होता है - भले ही वह लिपटा हुआ हो। लेकिन, इसका मतलब यह नहीं है कि आपको उस लाइब्रेरी को सीधे अपने आवेदन के पूरे नाम से स्वीकार करना होगा।
TLDR
यदि लाइब्रेरी रैपिंग के लायक है, तो अपने तीसरे पक्ष के लाइब्रेरी के लिए व्यापक संदर्भ से सीधे बचने के लिए रणनीति का उपयोग करें , लेकिन पतले रैपर उत्पन्न करने के लिए शॉर्टकट न लें। पहले अपने व्यावसायिक तर्क का निर्माण करें, अपने इंटरफेस के बारे में विचार-विमर्श करें, और आवश्यकतानुसार अपने एडेप्टर को व्यवस्थित रूप से उभरें।
और, अगर यह आता है, तो एकीकरण परीक्षणों से डरो मत। वे थोड़े फ़ूजीयर हैं, लेकिन वे अभी भी काम करने वाले कोड का सबूत देते हैं, और वे अभी भी आसानी से खाड़ी में प्रतिगमन बनाए रख सकते हैं।