अलग-अलग परियोजनाओं में कक्षा कार्यान्वयन से अलग इंटरफ़ेस?

Question

हम एक मध्यम आकार की परियोजना (6 महीने से अधिक समय में 3 डेवलपर्स) पर काम करते हैं और निम्नलिखित निर्णय लेने की आवश्यकता है: हम ठोस कार्यान्वयन से अलग इंटरफेस रखना चाहते हैं। पहला इंटरफ़ेस को एक अलग फ़ाइल में स्टोर करना है।

हम आगे बढ़ना चाहते हैं और डेटा को और भी अलग करना चाहते हैं: हम एक परियोजना में एक इंटरफेस के साथ एक प्रोजेक्ट (सीएसपीआरओजे) रखना चाहते हैं। सीएस फ़ाइल और सहायता कक्षाओं के साथ एक और सीएस फ़ाइल (जैसे कुछ सार्वजनिक वर्गों का उपयोग किया जाता है इस इंटरफेस के भीतर, कुछ enums आदि)। फिर, हम एक कारखाना पैटर्न, ठोस इंटरफेस कार्यान्वयन और अन्य "कार्यकर्ता" कक्षाओं के साथ एक और परियोजना (सीएसपीआरजे) चाहते हैं।

किसी भी वर्ग है जो एक वस्तु इस इंटरफेस को लागू पहली परियोजना है, जो इंटरफेस और सार्वजनिक कक्षाएं, नहीं कार्यान्वयन में ही होता है को शामिल करना चाहिए बनाना चाहता है।

इस समाधान का एक बड़ा नुकसान है: यह असेंबली की संख्या को 2 से गुणा करता है, क्योंकि आपके पास प्रत्येक "सामान्य" प्रोजेक्ट के लिए इंटरफेस वाला एक प्रोजेक्ट होगा और एक कार्यान्वयन के साथ होगा।

आप क्या सलाह देंगे? क्या आपको लगता है कि सभी इंटरफेस को अपनी परियोजना में एक इंटरफ़ेस की बजाय एक अलग परियोजना में रखना अच्छा विचार है?

Answer 1

मैं इस तरह इंटरफेस के बीच अंतर होगा:

1. स्टैंडअलोन इंटरफेस जिसका उद्देश्य आप अपने प्रोजेक्ट के बाकी के बारे में बात बिना वर्णन कर सकते हैं। इन्हें एक समर्पित "इंटरफेस असेंबली" में रखें, जिसे शायद आपकी परियोजना में अन्य सभी असेंबली द्वारा संदर्भित किया गया है। विशिष्ट उदाहरण: ILogger, IFileSystem, IServiceLocator।

2. कक्षा युग्मित इंटरफेस जो वास्तव में केवल आपके प्रोजेक्ट के वर्गों के संदर्भ में समझ में आता है। इन्हें उसी वर्ग में रखो जो कक्षाओं के साथ मिलकर हैं।

   एक उदाहरण: मान लीजिए आपके डोमेन मॉडल एक Banana वर्ग है। यदि आप IBananaRepository इंटरफ़ेस के माध्यम से केले पुनर्प्राप्त करते हैं, तो वह इंटरफ़ेस केले के साथ कसकर जोड़ता है। केले के बारे में कुछ जानने के बिना इंटरफ़ेस को कार्यान्वित करना या उपयोग करना असंभव है। इसलिए यह केवल तार्किक है कि इंटरफेस Banana के समान असेंबली में रहता है।

   पिछले उदाहरण एक तकनीकी युग्मन है, लेकिन युग्मन सिर्फ एक तार्किक हो सकता है। उदाहरण के लिए, IFecesThrowingTarget इंटरफ़ेस केवल Monkey कक्षा के सहयोगी के रूप में समझ सकता है भले ही इंटरफ़ेस घोषणा के Monkey पर कोई तकनीकी लिंक न हो।

मेरा जवाब धारणा पर निर्भर करते हैं कि यह वर्गों के लिए कुछ युग्मन के लिए ठीक है है।एक इंटरफेस के पीछे छिपा एक गलती होगी। Sometimes it's okay to just "new up" a class, इसे इंजेक्शन देने या फैक्ट्री के माध्यम से इसे बनाने के बजाय।

Answer 2

हाँ, मुझे लगता है कि यह एक अच्छा विचार है। असल में, हम इसे यहाँ हर समय करते हैं, और हम अंत में एक सरल कारण की वजह से यह करना है:

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

सामान्य तौर पर, मुझे लगता है कि आप और अधिक शिथिल युग्मित कर रहे हैं जब आप एक अलग परियोजना में इंटरफेस शब्दों में कहें, तो बस के साथ जाने के लिए और करते हैं। वास्तव में 2 असेंबली होने में कोई समस्या नहीं है, है ना?

अलावा:

बस मेरे मन को पार कर: एक अलग विधानसभा में इंटरफेस डाल करके, आप अतिरिक्त इंटरफेस का पुन: उपयोग करने के लिए यदि उनमें से कुछ काफी सामान्य हैं सक्षम होने का लाभ मिलता है।

Answer 3

मैं तब तक नहीं करूँगा जब तक कि यह आपके एप्लिकेशन के आर्किटेक्चर के लिए सिद्ध लाभ प्रदान न करे।

यह good to keep an eye on the number of assemblies you're creating है। यहां तक ​​कि यदि एक इंटरफेस और इसके कार्यान्वयन एक ही असेंबली में हैं, तो भी आप एक छोटे से अनुशासन के साथ सही तरीके से निर्णय लेने वाले निर्णय को प्राप्त कर सकते हैं।

Answer 4

मुझे लगता है कि आपको पहले यह विचार करना चाहिए कि क्या सभी इंटरफेस आपकी परियोजना के 'सार्वजनिक इंटरफ़ेस' से संबंधित हैं या नहीं।

वे कई परियोजनाओं, निष्पादनयोग्य और/या सेवाओं द्वारा साझा करने हैं, तो मुझे लगता है कि यह उन्हें एक अलग विधानसभा में लाना उचित है।

हालांकि, यदि वे आपकी सुविधा के लिए केवल और वहां आंतरिक उपयोग के लिए हैं, तो आप उन्हें कार्यान्वयन के समान असेंबली में रखना चुन सकते हैं, इस प्रकार कुल मिलाकर असेंबली अपेक्षाकृत कम रख सकते हैं।

Answer 5

दृष्टिकोण के लिए पेशेवर और विपक्ष हैं, और आपको निर्णय को गुस्सा करने की भी आवश्यकता होगी कि यह आपके वास्तुशिल्प दृष्टिकोण में सबसे अच्छा कैसे फिट बैठता है।

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

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

एक अर्द्ध यादृच्छिक टिप्पणी पर, अच्छी तरह से अपने इंटरफेस दस्तावेज़ के लिए सुनिश्चित करें। GhostDoc का उपयोग करके इंटरफेस से दस्तावेज़ीकरण विरासत एक सुंदर चीज़ है।

Answer 6

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

यहां बहुत सारे विचार हैं - क्या आप डेवलपर्स के लिए लाइब्रेरी लिख रहे हैं, क्या आप डीएलएल को ग्राहकों को ऑफसेट करने के लिए तैनात कर रहे हैं, क्या आप रिमोटिंग (धन्यवाद, मैक्सिमिलियन मेयरल) या डब्लूसीएफ सेवाओं आदि लिख रहे हैं। कोई भी नहीं है सही जवाब - यह निर्भर करता है।

सामान्य तौर पर मैं जेफ स्टर्नल से सहमत - तोड़ नहीं है विधानसभाओं जब तक यह एक सिद्ध लाभ प्रदान करता है।

Answer 7

यदि इंटरफ़ेस का कार्यान्वयन बहुत निर्भरता (अन्य असेंबली आदि पर) समाप्त होता है, तो एक पृथक असेंबली में इंटरफ़ेस होने से उच्च स्तर के उपभोक्ताओं के लिए जीवन हो सकता है।

वे अनजाने में विशिष्ट कार्यान्वयन की निर्भरताओं पर निर्भर होने के बिना इंटरफेस का संदर्भ दे सकते हैं।