कोड युग्मन DRY और OOD द्वारा परिचय

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

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

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

DRY बनाम अवांछित कोड कपलिंग के बीच एक इष्टतम संतुलन कैसे बनता है?

design dry coupling

— user2549686
स्रोत

यह हमेशा नियमों का पालन न करने के लिए अच्छा है लेकिन पहले मस्तिष्क को उलझाएं।

— gnasher729

उचित पर्याप्त - इसलिए दिशानिर्देश, नियम नहीं।

— user2549686

क्या आपने DRY (या OAOO पर विकी पेज पढ़ा है, जैसा कि इसे कहा जाता है)? wiki.c2.com/?OnceAndOnlyOnce जहां पर प्रारंभिक चर्चा का एक बहुत कुछ हुआ है। (दरअसल, वार्ड ने विकी को विशेष रूप से पैटर्न और व्यवहार के बारे में चर्चा के लिए आविष्कार किया था।)

— जॉर्ग डब्ल्यू मित्तग

बहुत ही संबंधित जवाब, भले ही सवाल एक डुप्लिकेट की तरह काफी आवाज़ नहीं करता है: softwareengineering.stackexchange.com/questions/300043/…

— हल्क

जवाबों:

मान लें कि मैंने "गैसोलीन" पदानुक्रम और "इलेक्ट्रिक" पदानुक्रम में डुप्लिकेट कोड को हटा दिया, दोनों "वाहन" पदानुक्रम से उतरते हैं। अब तक सब ठीक है।

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

मुझे लगता है कि यह मुख्य कारणों में से एक है जो लोग वंशानुक्रम पर रचना की ओर बढ़ रहे हैं।

वंशानुक्रम आपको बड़े पुनर्गठन में मजबूर करता है, जब आपके द्वारा वर्णित एक वैचारिक परिवर्तन होता है।

जब पुनर्गठन 'बहुत बड़ा / कठिन' होता है तो लोग इससे बचने के लिए डुप्लिकेट कोड लिखते हैं।

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

परिणामी डिज़ाइन OOP बहस के लिए खुला है या नहीं

— ईवान
स्रोत

+1 यह इंगित करने के लिए कि विरासत समस्या है, DRY नहीं। कोड का पुन: उपयोग करने का सबसे आसान तरीका अनावश्यक निर्भरता को दूर करना है, और सभी लोग अक्सर इस तथ्य को याद करते हैं कि विरासत का उपयोग करते समय एक मूल वर्ग (और यह वंशज) सभी निर्भरताएं हैं। केवल जब आप निर्भरता को कम या समाप्त करते हैं तो क्या आप वास्तव में पुन: प्रयोज्य कोड प्राप्त करते हैं ।

— ग्रेग बरगार्ड

" क्या परिणामी डिजाइन OOP बहस के लिए खुला है "। बहस करने के लिए सब कुछ खुला है। सवाल यह है कि क्या यह समझदारी, तर्कसंगत बहस के लिए खुला है? जवाब न है। मुझे लगता है कि आपका अंतिम पैराग्राफ अन्यथा बहुत अच्छे उत्तर से अलग हो जाता है।

— डेविड अर्नो

@davidarno वास्तव में आप का पालन नहीं करते, मैंने ऑब्जेक्ट ओरिएंटेड डिज़ाइन के रूप में शीर्षक में OOD पढ़ा? इसलिए बहस के बिना सवाल को टालते हुए im

— ईवान

@ इवान: मैं डेविड अरनो के साथ यहां हूं। मुझे लगता है कि यह 2 दशकों से अधिक समय से अच्छी तरह से जाना जाता है कि विश्वास "यदि कोई विरासत नहीं है, तो यह ओओपी नहीं है" एक पतन है।

— Doc Brown

इस तरह की चर्चा मैं बचने की कोशिश कर रहा था। दोनों पक्षों पर विचार हैं, कोई निश्चित जवाब नहीं है

— ईवान

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

दुर्भाग्य से, आपका उदाहरण इसे प्रदर्शित करने के लिए अच्छी तरह से अनुकूल नहीं है - वंशानुगत उपयोग के ~~गलत रूप से~~ उपयोग में शास्त्रीय त्रुटियों के कारण वहां वर्णित समस्याएं हैं । हालाँकि, मैंने जो ऊपर लिखा है, उसके लिए यह कोई फर्क नहीं पड़ता कि आप एक सामान्य आधार वर्ग के लिए, या हेल्पर क्लास (कंपोज़िशन) में कॉमन कोड को रिफ्लेक्टर करते हैं। दोनों ही मामलों में, किसी व्यक्ति को लाइब्रेरी L में कॉमन कोड डालने के लिए बाध्य किया जा सकता है और उस लाइब्रेरी को दो पूर्व असंबंधित प्रोग्राम A और B से संदर्भित किया जा सकता है।

आइए मान लें कि ए और बी पहले पूरी तरह से असंबंधित थे, उन्हें स्वतंत्र रूप से संस्करणबद्ध, जारी और तैनात किया जा सकता है। साझा कोड L में सामान्य कोड डालकर, हालांकि, A के लिए नई आवश्यकताएं L में परिवर्तन के लिए प्रेरित कर सकती हैं, जो कि अब बी में परिवर्तन का कारण बन सकता है। इसलिए यह अतिरिक्त परीक्षणों की आवश्यकता का कारण बनता है, और शायद एक नया रिलीज और बी के लिए तैनाती चक्र।

तो आप इस स्थिति को कैसे संभाल सकते हैं, अगर आप DRY सिद्धांत से हटने को तैयार नहीं हैं? इसे प्राप्त करने के लिए कुछ प्रसिद्ध रणनीति हैं:

या तो एक ही उत्पाद के हिस्से के रूप में ए, बी और एल रखें, एक सामान्य संस्करण संख्या के साथ, एक सामान्य निर्माण, रिहाई और तैनाती की प्रक्रिया, जिसमें उच्च स्तर का स्वचालन होता है।
या छोटे संस्करण संख्याओं (कोई असंगत परिवर्तन नहीं) और प्रमुख संस्करण संख्याओं (शायद ब्रेकिंग वाले परिवर्तन), और A और B प्रत्येक को L की एक भिन्न संस्करण रेखा को संदर्भित करने दें।
जितना संभव हो उतना एलआईडी बनाओ, और पीछे की संगतता के लिए देखभाल करें। L में अधिक मॉड्यूल को बिना संशोधन (OCP) के पुन: उपयोग किया जा सकता है, कम से कम ब्रेकिंग परिवर्तन होंगे। और "एसओएलआईडी" में अन्य सिद्धांत उस लक्ष्य का समर्थन करने में मदद कर रहे हैं।
विशेष रूप से एल के लिए स्वत: परीक्षण का उपयोग करें, लेकिन ए और बी के लिए भी।
सावधान रहें कि आप एल में क्या तर्क रखते हैं। व्यावसायिक तर्क जो एक प्रणाली में केवल एक ही स्थान पर मौजूद होना चाहिए, एक अच्छा उम्मीदवार है। जो चीजें सिर्फ "समान दिखती हैं" और भविष्य में अलग-अलग हो सकती हैं वे खराब उम्मीदवार हैं।

ध्यान दें कि जब ए और बी अलग-अलग, असंबंधित टीमों द्वारा विकसित, बनाए और विकसित किए जाते हैं, तो DRY सिद्धांत काफी कम महत्वपूर्ण हो जाता है - DRY में स्थिरता और अपवित्रता के बारे में है, लेकिन दो अलग-अलग टीमों को व्यक्तिगत रखरखाव के प्रयास प्रदान करना कभी-कभी अपने उत्पादों को बांधने से अधिक प्रभावी हो सकता है। फिर से थोड़ा सा पुन: जुड़ने के कारण।

तो अंत में, यह एक व्यापार है। यदि आप बड़े सिस्टम में DRY सिद्धांत का पालन करना चाहते हैं, तो आपको मजबूत, पुन: प्रयोज्य घटकों को बनाने में अधिक प्रयास करने की आवश्यकता है - आमतौर पर आपकी अपेक्षा से अधिक। आपको अपने फैसले पर भरोसा करना होगा कि कब वह इसके लायक है, और कब नहीं।

— डॉक्टर ब्राउन
स्रोत

DRY अभी तक एक और संरचनात्मक नियम है। इसका मतलब है कि यदि आप इसे चरम सीमा पर ले जाते हैं तो यह उतना ही बुरा है जितना कि आप इसे अनदेखा करते हैं। यहां आपको संरचनात्मक दिमाग सेट से बाहर निकालने का एक रूपक है।

अपने जुड़वा बच्चों को प्यार करो। क्लोन को मार डालो।

जब आप आँख बंद करके कॉपी और पेस्ट करते हैं तो कीबोर्ड टाइपिंग से बचने के लिए। निश्चित रूप से वे वही करते हैं जो आप चाहते हैं लेकिन वे आपको कम करते हैं क्योंकि अब उस व्यवहार को बदलना इतना महंगा है।

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

आप उनके डीएनए (कोड) को अपनी पसंद के अनुसार स्कैन कर सकते हैं। क्लोन और जुड़वाँ के अलावा यह बताना मुश्किल है कि आप क्या करते हैं। आपको उन संदर्भों को समझने की आवश्यकता है जो वे रहते हैं। वे क्यों पैदा हुए थे। उनका अंतिम भाग्य क्या है।

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

इससे नफरत है, आप चाहते हैं कि आप कंपनी का नाम वहां रखें।

बी इसे प्यार करता है, आप इसे अकेले छोड़ना चाहते हैं और कंपनी का नाम स्प्लैश स्क्रीन में जोड़ सकते हैं।

सी सिर्फ एक कैलकुलेटर चाहता है और सोचा कि संदेश आपके लिए शुरुआत करने का एक तरीका था।

एक बात जिस पर आपको यकीन है, इन लोगों के पास इस परियोजना के बारे में बहुत अलग विचार हैं। कभी-कभी वे सहमत होते हैं। कभी-कभी वे आपको अलग-अलग दिशाओं में खींचने जा रहे हैं।

जब आप कोड को डुप्लिकेट करते हैं क्योंकि आप उस कोड के लिए स्वतंत्र रूप से भिन्न होने की क्षमता पैदा कर रहे हैं, तो आप एक जुड़वा पैदा कर रहे हैं। जब आप कोड को डुप्लिकेट करते हैं क्योंकि टाइपिंग एक दर्द है और कॉपी और पेस्ट आसान है तो आप बुराई क्लोन बना रहे हैं।

A, B, और C अलग-अलग स्वामी हैं जिन्हें आपके कोड की सेवा करनी चाहिए। कोड की कोई एक पंक्ति लंबे समय तक एक से अधिक मास्टर की सेवा नहीं दे सकती है।

— candied_orange
स्रोत

सबसे पहले, सभी टिप्पणियों के लिए सभी को बहुत धन्यवाद।

— user2549686