क्या पुन: प्रयोज्य लगभग अच्छी डिजाइन का पर्याय है?

Question

पुन: प्रयोज्य अच्छा सॉफ्टवेयर डिजाइन की एक विशेषता है ।

क्या पुन: प्रयोज्यता अच्छे सॉफ्टवेयर डिजाइन के लिए एक स्वीकार्य चमक ("अर्थ का संक्षिप्त अंकन") है? क्यों?

Comments

मैं तर्क दूंगा कि लचीलापन अधिक महत्वपूर्ण है। एक अंतर्निहित वास्तुकला होने से वास्तविकता को समायोजित करने की कोशिश की जाती है कि कुछ संभवतः बदल जाएगा या बाद में जोड़ देगा मेरी राय है। Reusablity लगभग उस बिंदु पर मुफ्त में आती है।

— पेमदास

आपके लचीलेपन का उपयोग वास्तव में पुन: प्रयोज्य की तरह लगता है।

— मैथ्यू रोडटस

"पुन: प्रयोज्यता संभावना कोड का एक खंड है जिसे फिर से मामूली या कोई संशोधन के साथ नई कार्यक्षमता जोड़ने के लिए उपयोग किया जा सकता है" - en.wikipedia.org/wiki/Rususability

— मैथ्यू रोडेटस

मैं प्रभावित हूं कि नीचे दिए गए अधिकांश उत्तर नहीं कहते हैं । यह अब कुछ साल पहले (अच्छी तरह से ... 5-10 साल) के मामले में होगा, जब पुन: प्रयोज्य सभी क्रोध कुछ अत्यधिक वांछनीय था।

— मार्टिन विकमैन

@MartinWickman पुन: प्रयोज्य अच्छा है, लेकिन यह मुफ़्त नहीं है।

— कालेब

Answer 1

नहीं।

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

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

मैं एक अलग "ग्लोस" का उपयोग करूंगा: टेस्टिबिलिटी।

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

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

कृपया, किसी घटक के "पुन: प्रयोज्य" के रूप में जंगली अनुमान लगाने की कोशिश न करें, विशेष रूप से "विशेष डिजाइन" के सबूत के रूप में उपयोग करने के लिए नहीं। यह एक ऐसी चीज है जिसे आप केवल एक बार देख सकते हैं।

Comments

अच्छा उत्तर। आपने उस प्रश्न का उत्तर दिया जो मुझे पूछा जाना चाहिए: "अच्छे सॉफ्टवेयर डिजाइन के लिए एक अच्छा चमक क्या है?"

— मैथ्यू रोडेटस

+1: विशेष रूप से "पुन: प्रयोज्यता काफी हद तक एक भ्रम है"।

— क्रामि

यह केवल अच्छे डिजाइन का एक संकेतक है यदि पुन: प्रयोज्य एक लक्ष्य है। यह अक्सर है एक लक्ष्य है, अगर एक अंतर्निहित एक है, लेकिन समय बिताने और मेकअप घटकों के लिए पैसे पुन: प्रयोज्य जब वे होने की जरूरत नहीं है बस बेकार है।

— कालेब

Answer 2

नहीं।

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

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

Comments

स्वचालित परीक्षण के बारे में क्या? इकाई पुन: उपयोग का एक रूप नहीं है?

— मैथ्यू रोडेटस

@ मैथ्यू-रोडैटस: यूनिट परीक्षण आपके सॉफ्टवेयर को डिलीवर करने योग्य हैं। पुन: उपयोग आम तौर पर सॉफ्टवेयर के कुछ अन्य टुकड़े में पुन: उपयोग कोड को संदर्भित करता है ।

— btilly

अच्छी बात। मुझे लगता है कि मैं "पुन: प्रयोज्य" का उपयोग एक ऑथोलॉजिकल अर्थ में कर रहा हूं, जो भ्रामक है। हालाँकि, अवलोकन करें कि पुन: प्रयोज्य की विशेषताएं

— टेस्टेबल

@ मैथ्यू-रॉडैटस: पुन: प्रयोज्यता नहीं है, "क्या यह सुविधाओं की कपड़े धोने की सूची है।" यदि आप इस तरह से पुन: प्रयोज्यता प्राप्त करने का प्रयास करते हैं, तो आप कठिन असफल होंगे। इस पर मेरा विश्वास करो।

— btilly

अच्छी बात। मैं अब देख रहा हूं कि मैंने जो सवाल पूछने का मतलब नहीं पूछा था, लेकिन यह अभी भी एक दिलचस्प संवाद है।

— मैथ्यू रोडैटस

Answer 3

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

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

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

आशा है कि मैंने अपने स्पष्टीकरण को बहुत अधिक गड़बड़ नहीं किया

Comments

इसलिए मैंने "ग्लॉस" कहा (जिससे मेरा मतलब है कि, व्यावहारिक रूप से पुन: प्रयोज्यता सबसे अधिक पकड़ लेती है लेकिन अच्छे डिजाइन से हमारा मतलब नहीं है)।

— मैथ्यू रोडैटस

मेरा कहना है कि आपको अच्छे डिज़ाइन के लिए पुन: प्रयोज्य की आवश्यकता है , लेकिन बहुत सारे "पुन: प्रयोज्य" कोड होने का मतलब यह नहीं है कि आपके पास एक अच्छा डिज़ाइन है, इसलिए मैं अभी भी कहूंगा कि नहीं, एक चमक के रूप में भी नहीं

— डेविड कोंडे

यह समझ आता है। मुझे यकीन नहीं है कि मैं सहमत हूं, लेकिन एक अच्छी तरह से सोचा जवाब के लिए +1।

— मैथ्यू रोडेटस

Answer 4

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

इन मूलभूत डिजाइन सिद्धांतों से चिपके रहने से परीक्षण करने में आसानी होती है और पुन: उपयोग में आसानी होती है।

अच्छा डिजाइन == अच्छा डिजाइन, पुन: प्रयोज्य एक उप-उत्पाद है।

Answer 5

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

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

कई समान विशेषताएँ हैं जिन्हें अक्सर अंतर्निहित डिज़ाइन लक्ष्य माना जाता है क्योंकि वे स्पष्ट रूप से अच्छे लगते हैं:

• लागत को कम करना

• विकास के समय को कम करना

• जटिलता को कम करना

• विश्वसनीयता को अधिकतम करना

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

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

Answer 6

जरुरी नहीं। यदि आप कुछ ऐसा पुन: प्रयोज्य बनाते हैं जो स्पष्ट रूप से पुन: उपयोग होने वाला नहीं है तो यह खराब डिजाइन है।

उदाहरण के लिए, यदि आप डेटा से भरी एक फाइल लिख रहे हैं जो आपकी कंपनी के लिए अद्वितीय है और उस डेटा को एक बार कहीं और आयात किया जाना है, तो इसे पुन: प्रयोज्य बनाने में क्यों परेशान करें?

उस ने कहा, यदि आपके ढांचे में पहले से कोई नहीं है, तो फ़ाइल में लिखने के लिए कोड को पुन: उपयोग करने की आवश्यकता हो सकती है। यह अच्छा डिज़ाइन होगा।

Comments

यदि आप किसी चीज का पुन: उपयोग नहीं करने जा रहे हैं, तो आप इसे कैसे सुनिश्चित करेंगे?

— मैथ्यू रोडेटस

@ मैथ्यू - यह एक अच्छे डिजाइनर की मेरी परिभाषा होगी: कोई है जो आमतौर पर उस सवाल को सही

— पाता है

Answer 7

मैं नहीं कहूंगा, ज्यादातर क्योंकि यह केवल कोड के एक छोटे खंड का वर्णन करता है। मैंने पाया है कि जहां प्रयोज्य सबसे महत्वपूर्ण है वह बहुत ही मुख्य और उपयोगिता क्षेत्र के बाहरी किनारों पर है, बीच में इतना नहीं। मैं उन चीजों के कुछ उदाहरण दूंगा जहां मुझे लगता है कि पुन: प्रयोज्य गुणवत्ता डिजाइन का एक उपयोगी मीट्रिक है।

कोर स्टफ

• वेबफ़ॉर्म टेम्प्लेट जो किसी पृष्ठ को आसानी से और लगातार (या किसी भी प्रकार के UI के लिए) जोड़ने की अनुमति देते हैं
• ViewModel बेस क्लास जैसे डिज़ाइन पैटर्न हेल्पर्स, जो मेरे सभी MVVM अनुप्रयोगों में शामिल होंगे

उपयोगिता सामग्री

• ईमेल वर्ग जो SMTP संदेश भेजता है (इसका उपयोग हर समय करें)
• एक जीआईएस दूरी कैलकुलेटर वर्ग (हमारे ऐप्स के एक समूह में प्रयुक्त)

सीआरयूडी सामान के लिए जो 70-80% सबसे अधिक ऐप लेता है, मुझे नहीं लगता कि पुन: प्रयोज्यता एक मूल्यवान मीट्रिक है।