युग्मन। सर्वोत्तम प्रथाएं


11

इस सूत्र से मैंने शुरुआत की

सिंगलटन पैटर्न

इसने मुझे यह सोचने के लिए प्रेरित किया कि मेरी कक्षाएं कैसे युग्मित हैं और ढीले युग्मन को प्राप्त करने के लिए सबसे अच्छा कैसे है। कृपया ध्यान रखें कि मैं एक नया प्रोग्रामर हूं (मेरी पहली नौकरी में 4 महीने) और यह वास्तव में पहला विचार है जो मैंने इसे दिया है, और अवधारणा को समझने के लिए बहुत उत्सुक हूं।

तो, क्या वास्तव में ढीले युग्मन बनाम भारी युग्मन का गठन करता है? मेरे वर्तमान (और पहली परियोजना) में, मैं एसी # विनफॉर्म प्रोजेक्ट पर काम कर रहा हूं, जहां जीयूआई खंड ऑब्जेक्ट बनाता है और उनकी घटनाओं के अधीन होता है, जब उन्हें ट्रिगर किया जाता है, तो जीयूआई एक और ऑब्जेक्ट बनाता है (इस उदाहरण में, डेटाटेग्यूव्यू (एक वर्ग) कि मैंने बनाया है कि एक मानक डेटाग्रिडव्यू के चारों ओर लपेटता है और अतिरिक्त कार्यक्षमता जोड़ता है) और इसे जीयूआई से जोड़ता है। क्या यह खराब युग्मन या अच्छा है?

मैं वास्तव में बुरी आदतों में नहीं पड़ना चाहता हूं और खराब तरीके से कोडिंग शुरू कर रहा हूं, इसलिए मैं आपकी प्रतिक्रियाओं की सराहना करूंगा।

जवाबों:


11

अपने कोड को शिथिल बनाने के लिए यहां कुछ सरल बातें याद रखने योग्य हैं:

भाग 1:

तकनीकी रूप से "पृथक्करण की चिंता" के रूप में जाना जाता है। प्रत्येक वर्ग की एक विशिष्ट भूमिका होती है, उसे व्यावसायिक तर्क या अनुप्रयोग तर्क को संभालना चाहिए। कोशिश करें और कक्षा को साफ करें जो दोनों जिम्मेदारियों को जोड़ती है। यानी एक वर्ग जो डेटा (व्यापक अवधि) का डेटा अनुप्रयोग तर्क है, जबकि एक वर्ग जो डेटा का उपयोग करता है वह व्यावसायिक तर्क है।

व्यक्तिगत रूप से मैं इसे (अपनी छोटी दुनिया में) के रूप में संदर्भित करता हूं create it or use it। एक वर्ग को एक वस्तु का निर्माण करना चाहिए या एक ऐसी वस्तु का उपयोग करना चाहिए जो इसे दोनों को कभी नहीं करना चाहिए।

भाग 2:

चिंता के अलगाव को कैसे लागू किया जाए।
शुरुआती बिंदु के रूप में दो सरल तकनीकें हैं:

नोट: डिजाइन पैटर्न निरपेक्ष नहीं हैं।
उन्हें स्थिति के अनुसार अनुकूलित किया जाना चाहिए लेकिन एक अंतर्निहित विषय है जो सभी अनुप्रयोगों के समान है। इसलिए नीचे दिए गए उदाहरणों को न देखें और कहें कि मुझे इस पर सख्ती से अमल करना चाहिए; ये सिर्फ उदाहरण हैं (और उस पर थोड़े विपरीत हैं)।

निर्भरता इंजेक्शन :

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

class Tokenizer
{
    public:
        Tokenizer(std::istream& s)
            : stream(s)
        {}
        std::string nextToken() { std::string token; stream >> token;return token;}
    private:
        std::istream& stream;
};

यहाँ हम एक टोकनर में स्ट्रीम इंजेक्ट करते हैं। टोकेनाइज़र को यह पता नहीं होता है कि यह स्ट्रीम किस प्रकार की है जब तक यह std :: istream के इंटरफ़ेस को लागू करता है।

सेवा लोकेटर पैटर्न :

सेवा लोकेटर पैटर्न निर्भरता इंजेक्शन पर थोड़ा बदलाव है। एक ऐसी वस्तु देने के बजाय जिसका वह उपयोग कर सकता है, आप उसे एक ऐसी वस्तु देते हैं, जिसे आप जिस वस्तु का उपयोग करना चाहते हैं, उसका पता लगाना (बनाना) जानते हैं।

class Application
{
     public:
         Application(Persister& p)
             : persistor(p)
         {}

         void save()
         {
             std::auto_ptr<SaveDialog> saveDialog = persistor.getSaveDialog();
             saveDialog.DoSaveAction();
         }

         void load()
         {
             std::auto_ptr<LoadDialog> loadDialog = persistor.getLoadDialog();
             loadDialog.DoLoadAction();
         }
    private:
        Persister& persistor;
};

यहां हम एप्लिकेशन ऑब्जेक्ट को एक पर्सिस्टर ऑब्जेक्ट पास करते हैं। जब आप एक सेव / लोड एक्शन करते हैं तो यह एक ऑब्जेक्ट बनाने के लिए पर्सिस्टर का उपयोग करता है जो वास्तव में जानता है कि एक्शन कैसे करना है। नोट: फिर से फ़िसिस्टर एक इंटरफ़ेस है और आप स्थिति के आधार पर विभिन्न कार्यान्वयन प्रदान कर सकते हैं।

जब potentiallyआप किसी क्रिया को तुरंत करते हैं तो हर बार एक अनोखी वस्तु की आवश्यकता होने पर यह उपयोगी होता है ।

व्यक्तिगत रूप से मुझे लगता है कि यह इकाई परीक्षण लिखने में विशेष रूप से उपयोगी है।

पैटर्न का नोट:

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

अनुभव के साथ आप महसूस करेंगे कि आप पहले से ही इन पैटर्नों का उपयोग कर रहे हैं कि आपने उनके औपचारिक नामों का उपयोग नहीं किया है। उनके नाम मानकीकृत करने से (और हर कोई उन्हें सीखने के लिए) हम पाते हैं कि यह विचारों को संप्रेषित करना आसान और तेज है।


3
@ डेरेन यंग: इसे स्वीकार करने के लिए धन्यवाद। लेकिन आपका सवाल केवल तीन घंटे का है। मैं एक दिन में वापस आऊंगा या यह सत्यापित करूंगा कि अन्य लोगों ने बेहतर उत्तर नहीं दिए हैं।
मार्टिन

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

@ डेरेन यंग: जैसा कि सभी प्रोग्रामिंग के साथ लाइन ग्रे है और धुंधली को अच्छी तरह से परिभाषित नहीं किया गया है। आपके कोड को पढ़े बिना सटीक प्रतिक्रिया देना कठिन है। लेकिन जब मैं बात करता हूं तो मैं managing the dataचर (वास्तविक डेटा नहीं) का उल्लेख कर रहा हूं। इसलिए पॉइंटर्स जैसी चीजों को प्रबंधित करने की आवश्यकता है ताकि वे लीक न हों। लेकिन डेटा को इंजेक्ट किया जा सकता है या डेटा पुनर्प्राप्त कैसे किया जा सकता है (ताकि आपकी कक्षा को विभिन्न डेटा पुनर्प्राप्ति विधियों के साथ फिर से उपयोग किया जा सके)। मुझे खेद है कि मैं अधिक सटीक नहीं हो सकता।
मार्टिन

1
@ डेरेन यंग: जैसा कि उनके जवाब में @StuperUser ने नोट किया है। ओवरबोर्ड मत जाओ (AKA minutae of loose coupling(प्यार शब्द मीनुता))। प्रोग्रामिंग का रहस्य यह सीखना है कि तकनीकों का उपयोग कब करना है। अति प्रयोग से कोड की उलझन पैदा हो सकती है।
मार्टिन जॉर्ज

@ मार्टिन - सलाह के लिए धन्यवाद। मुझे लगता है कि जहां मैं वर्तमान में संघर्ष कर रहा हूं ..... मैं अपने कोड की वास्तुकला के बारे में लगातार चिंता करता हूं और यह भी जानने की कोशिश कर रहा हूं कि मैं सी # का उपयोग कर रहा हूं। मुझे लगता है कि यह अनुभव और इस सामान को सीखने की मेरी इच्छा के साथ आएगा। मैं आपकी टिप्पणियों की सराहना करता हूं।
डैरेन यंग

6

मैं एक ASP.NET डेवलपर हूं, इसलिए WinForms कपलिंग के बारे में ज्यादा नहीं जानता, लेकिन N-Tier वेब ऐप्स से थोड़ा बहुत पता है, तो UI, डोमेन, डेटा एक्सेस लेयर (DAL) के 3 स्तरीय एप्लिकेशन आर्किटेक्चर को ग्रहण करता है।

ढीली युग्मन सार के बारे में है।

जैसा कि @MKO बताता है कि यदि आप किसी अन्य के साथ असेंबली को बदल सकते हैं (उदाहरण के लिए एक नया UI प्रोजेक्ट जो आपके डोमेन प्रोजेक्ट का उपयोग करता है, एक नया DAL जो एक डेटाबेस के बजाय एक स्प्रेडशीट को बचाता है) तो ढीली युग्मन है। यदि आपका डोमेन और डीएएल श्रृंखला से आगे की परियोजनाओं पर निर्भर करते हैं, तो युग्मन शिथिल हो सकता है।

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

जैसे UI प्रोजेक्ट में कोई ऑब्जेक्ट डोमेन प्रोजेक्ट में रिपॉजिटरी ऑब्जेक्ट कहता है।
आप एक बना सकते हैं नकली कि औजार भंडार है कि परीक्षण का उपयोग करता है के तहत कोड है, तो परीक्षण (के लिए विशेष व्यवहार लिखने के रूप में एक ही इंटरफ़ेस वस्तु स्टब्स उत्पादन कोड है कि बचाता है / हटाए को रोकने के लिए / बुलाया जा रहा हो जाता है और mocks कि स्टब्स के रूप में कार्य और ट्रैक रखने परीक्षण उद्देश्यों के लिए नकली वस्तु की स्थिति)।
साधन का एकमात्र उत्पादन कोड कहा जा रहा है अब केवल आपके UI ऑब्जेक्ट में है, आपका परीक्षण केवल उस पद्धति के विरुद्ध होगा और कोई भी परीक्षण विफलता उस पद्धति के दोष को अलग कर देगी।

इसके अलावा, वीएस में विश्लेषण मेनू में (आपके पास संस्करण के आधार पर) आपकी परियोजना के लिए कोड मेट्रिक्स की गणना करने के लिए उपकरण हैं, जिनमें से एक क्लास कपलिंग है, एमएसडीएन प्रलेखन में इस पर अधिक जानकारी होगी।

मत बहुत ढीला संयोजन के minutae में फंस हालांकि, वहाँ है कि अगर कोई मौका नहीं है कि चीजें पुन: उपयोग करने के लिए (एक से अधिक यूआई के साथ जैसे एक डोमेन परियोजना) कर रहे हैं और उत्पाद के जीवन छोटा है, तो ढीला संयोजन कम हो जाता है प्राथमिकता (इसे अभी भी ध्यान में रखा जाएगा), लेकिन यह अभी भी आर्किटेक्ट / टेक लीड की जवाबदेही होगी जो आपके कोड की समीक्षा करेंगे।


3

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


3

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

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

और अंत में, आप इस खंड को IoC पर काफी उपयोगी पा सकते हैं , आम तकनीकों के लिए एक प्रवेश बिंदु के रूप में।

वास्तव में, मुझे स्टैकओवरफ्लो पर एक सवाल मिला , जहां मैं ठोस समस्या पर एसओएलआईडी के आवेदन को प्रदर्शित करता हूं। एक दिलचस्प पढ़ा जा सकता है।


1

विकिपीडिया के अनुसार:

कंप्यूटिंग और सिस्टम डिजाइन में एक शिथिल युग्मित प्रणाली वह है जहां इसके प्रत्येक घटक के पास है, या अन्य अलग-अलग घटकों की परिभाषाओं का बहुत कम या कोई ज्ञान नहीं है।

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

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

आपके विशेष उदाहरण में, ईवेंट हैंडलिंग सामान GUI और अंतर्निहित डेटा के बीच कुछ अलगाव प्रदान करता है। हालाँकि, यह ध्वनि करता है जैसे कि पृथक्करण के अन्य क्षेत्र हैं जिन्हें आप देख सकते हैं। आपकी विशेष स्थिति के अधिक विवरण के बिना विशिष्ट होना मुश्किल है। हालाँकि, आप एक 3-स्तरीय वास्तुकला के साथ शुरुआत कर सकते हैं जो अलग हो जाती है:

  • डेटा भंडारण और पुनर्प्राप्ति तर्क
  • व्यापार का तर्क
  • UI को चलाने के लिए तर्क आवश्यक है

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

यदि आप शिथिल युग्मित प्रणालियों को डिजाइन करने के बारे में गंभीर हैं, तो SOLID सिद्धांतों और डिज़ाइन पैटर्न पर पढ़ें।

हालांकि, महसूस करने के लिए महत्वपूर्ण बात यह है कि ये पैटर्न और सिद्धांत बस यही हैं - पैटर्न और सिद्धांत। वे नियम नहीं हैं। इसका मतलब है कि उन्हें व्यावहारिक और समझदारी से लागू करने की आवश्यकता है

जहां पैटर्न का संबंध है, यह समझना महत्वपूर्ण है कि पैटर्न में से किसी एक का "सही" कार्यान्वयन नहीं है। और न ही वे अपने स्वयं के कार्यान्वयन को डिजाइन करने के लिए कुकी-कटर टेम्पलेट हैं। वे आपको यह बताने के लिए हैं कि एक अच्छा समाधान किस आकार का हो सकता है, और आपको अन्य डेवलपर्स के साथ डिजाइन निर्णयों को संप्रेषित करने के लिए एक सामान्य भाषा प्रदान करता है।

शुभकामनाएं।


1

निर्भरता इंजेक्शन, रणनीति पैटर्न और घटनाओं का उपयोग करें। सामान्य तौर पर: डिज़ाइन पैटर्न पर पढ़ा जाता है, वे ढीले युग्मन और निर्भरता कम करने के बारे में हैं। मैं कहता हूँ कि घटनाओं के बारे में बहुत कम के रूप में युग्मित कर रहे हैं, जबकि आप पर निर्भरता इंजेक्शन और रणनीति पेटेंट कुछ इंटरफेस की आवश्यकता होगी।

विभिन्न पुस्तकालयों / विधानसभाओं में कक्षाएं लगाने के लिए एक अच्छी चाल है, और क्या वे संभव के रूप में कुछ अन्य पुस्तकालयों पर निर्भर हैं, जो आपको कम निर्भरता का उपयोग करने के लिए रिफ्लेक्टर के लिए मजबूर करेगा


4
क्या कंडोम में कुछ अमूर्त आईटी शब्द है या क्या मुझे बस सजा नहीं मिल रही है?
डैरेन यंग

3
यह निर्भरता इंजेक्शन कंटेनर का दूसरा नाम है।
Mchl

2
साथ ही वायरस के प्रसार को रोकने का एक शानदार तरीका है। क्या हम एक ही चीज के बारे में बात कर रहे हैं?
सोवा

1
भारी युग्मन अक्सर बैकेंड पर किया जाता है
होमडे

1
एक हेडलाइन सेट करना शायद ही कभी गाली देना हो
होमडे

0

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

init, open, close

बनाम

setTheFoo, setBar, initX, getConnection, close

पहला स्पष्ट है और अच्छा एपीआई जैसा दिखता है। गलत क्रम में कॉल करने पर दूसरी त्रुटि हो सकती है।

मुझे कॉल करने वालों को संशोधित करने और पुन: स्थापित करने के बारे में बहुत चिंता नहीं है। मैं इसे बहुत कुछ नया और कुछ 15 साल पुराना कोड बनाए रखता हूं। जब मैं परिवर्तन करता हूं तो मैं आमतौर पर कंपाइलर त्रुटियां चाहता हूं। कभी-कभी मैं जानबूझकर उस कारण से एक एपीआई तोड़ सकता हूं। यह मुझे प्रत्येक फोन करने वाले पर विचार करने का मौका देता है। मैं निर्भरता इंजेक्शन का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि मैं ब्लैक बॉक्स के बिना अपने कोड के माध्यम से नेत्रहीन ट्रेस करने में सक्षम होना चाहता हूं और मैं चाहता हूं कि कंपाइलर संभव के रूप में कई त्रुटियों को पकड़ सके।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.