हमें डिजाइन पैटर्न में इतने सारे वर्गों की आवश्यकता क्यों है?

Question

मैं सीनियर्स के बीच जूनियर डेवलपर हूं और उनकी सोच, तर्क को समझने के साथ बहुत संघर्ष कर रहा हूं।

मैं Domain-Driven Design (DDD) पढ़ रहा हूं और समझ नहीं पा रहा हूं कि हमें इतने सारे वर्ग बनाने की आवश्यकता क्यों है। यदि हम सॉफ्टवेयर डिजाइन करने की उस पद्धति का अनुसरण करते हैं, तो हम 20-30 वर्गों के साथ समाप्त हो जाते हैं, जिन्हें अधिकांश दो फाइलों और 3-4 कार्यों के साथ बदला जा सकता है। हां, यह गड़बड़ हो सकता है, लेकिन यह बहुत अधिक बनाए रखने योग्य और पठनीय है।

किसी भी समय मैं यह देखना चाहता हूं कि मुझे किस तरह के EntityTransformationServiceImplवर्ग, इंटरफेस, उनके फ़ंक्शन कॉल, कंस्ट्रक्टर, उनके निर्माण और इतने पर का पालन करने की आवश्यकता है।

सरल गणित:

• डमी कोड की 10 लाइनें बनाम 10 कक्षाएं एक्स 10 (मान लीजिए कि हमारे पास इस तरह के लॉजिक्स बिल्कुल अलग हैं) = गंदे कोड की 600 लाइनें बनाम 100 कक्षाएं + उन्हें लपेटने और प्रबंधित करने के लिए कुछ और; निर्भरता इंजेक्शन जोड़ने के लिए मत भूलना।
• गन्दे कोड की 600 पंक्तियाँ पढ़ना = एक दिन
• 100 कक्षाएं = एक सप्ताह, फिर भी भूल जाओ कि कौन क्या करता है, कब

हर कोई कह रहा है कि इसे बनाए रखना आसान है, लेकिन किस लिए? हर बार जब आप नई कार्यक्षमता जोड़ते हैं, तो आप कारखानों, संस्थाओं, सेवाओं और मूल्यों के साथ पांच और कक्षाएं जोड़ते हैं। मुझे ऐसा लगता है कि इस तरह का कोड गड़बड़ कोड की तुलना में बहुत धीमा है।

मान लीजिए, यदि आप एक महीने में 50K LOC गन्दा कोड लिखते हैं, तो DDD चीज़ को बहुत सारी समीक्षाओं और परिवर्तनों की आवश्यकता होती है (मुझे दोनों मामलों में परीक्षण में कोई आपत्ति नहीं है)। अधिक नहीं तो एक साधारण जोड़ में सप्ताह लग सकता है।

एक वर्ष में, आप बहुत सारे गन्दे कोड लिखते हैं और यहां तक ​​कि इसे कई बार फिर से लिख सकते हैं, लेकिन DDD शैली के साथ, आपके पास अभी भी गन्दे कोड के साथ प्रतिस्पर्धा करने के लिए पर्याप्त सुविधाएँ नहीं हैं।

कृपया समझाएँ। हमें इस डीडीडी शैली और बहुत सारे पैटर्न की आवश्यकता क्यों है?

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

Comments

मुझे लगता है कि यहां एक अच्छा सवाल है लेकिन यह हाइपरबोले और निराशा के पीछे छिपा है। @ user1318496, आपको अपने प्रश्न को थोड़ा सा पुन: परिभाषित करने से लाभ हो सकता है।

— मेटाफ़ाइट

पैर की उंगलियों पर कदम रखने के जोखिम पर, क्योंकि आपकी भाषा बेकार है। इससे अधिक के लिए इसे मत लो: एक बेकार भाषा अक्सर कई कारणों से सही तकनीकी विकल्प है, लेकिन यह इसे गैर-बेकार नहीं बनाती है। आपके वास्तविक प्रश्न के लिए, पठनीयता की तुलना में शुद्धता अधिक महत्वपूर्ण है। या इसे थोड़ा अलग तरीके से रखना: पठनीयता मायने रखती है क्योंकि शुद्धता के बारे में तर्क सक्षम बनाता है। तो जो परीक्षण करने के लिए आसान है, आपके 100 वर्ग या आपके अखंड देव वर्ग? मैं 100 सरल कक्षाओं में दांव लगा रहा हूं।

— जैरेड स्मिथ

"हाँ, यह गड़बड़ हो सकता है, लेकिन इसके बहुत अधिक बनाए रखने योग्य और पठनीय है।" अगर इसकी गड़बड़ है, तो यह पठनीय और रखरखाव योग्य कैसे हो सकता है?

— पॉलीग्नोम

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

— एरिक लिपर्ट

जब तक आप जावा नहीं कर रहे हैं, आप नहीं। जब आपके पास जावा होता है, तो सब कुछ एक वर्ग जैसा दिखता है।

— होब्स

Answer 1

यह एक अनुकूलन समस्या है

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

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

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

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

जटिलता संबंधों से आती है, तत्वों से नहीं

मुझे लगता है कि आप अपने विश्लेषण में मात्राओं की मात्रा - कोड की संख्या, वर्गों की संख्या आदि देख रहे हैं, जबकि ये दिलचस्प हैं, वास्तविक प्रभाव तत्वों के बीच संबंधों से आता है, जो दहनशील रूप से विस्फोट करता है। उदाहरण के लिए, यदि आपके 10 कार्य हैं और कोई भी विचार नहीं है, जिस पर निर्भर करता है, तो आपके पास 90 संभावित संबंध (निर्भरताएं) हैं जिनके बारे में आपको चिंता करनी होगी- दस कार्यों में से प्रत्येक नौ अन्य कार्यों में से किसी पर निर्भर हो सकता है, और 9 x 10 = 90. आपके पास कोई विचार नहीं हो सकता है कि कौन सा फ़ंक्शन संशोधित करता है कि कौन सा चर या डेटा कैसे पास हो जाता है, इसलिए कोडर के पास किसी भी विशेष समस्या को हल करने के बारे में चिंता करने की एक टन चीजें हैं। इसके विपरीत, यदि आपके पास 30 कक्षाएं हैं, लेकिन उन्हें बड़ी चतुराई से व्यवस्थित किया जाता है, तो उनके 29 संबंध हो सकते हैं, जैसे अगर वे स्तरित हैं या स्टैक में व्यवस्थित हैं।

यह आपकी टीम के थ्रूपुट को कैसे प्रभावित करता है? खैर, कम निर्भरताएं हैं, समस्या बहुत अधिक है; जब भी वे कोई बदलाव करते हैं तो कोडर्स को उनके सिर में एक ज़िलीन चीज़ नहीं मिलनी चाहिए। तो निर्भरता कम से कम करने के लिए सक्षम समस्या के बारे में तर्क करने की आपकी क्षमता में भारी वृद्धि हो सकती है। यही कारण है कि हम चीजों को वर्गों या मॉड्यूलों में विभाजित करते हैं, और चर को यथासंभव कसकर विभाजित करते हैं, और ठोस सिद्धांतों का उपयोग करते हैं।

Comments

हालाँकि, मैं ध्यान दूंगा कि कक्षाओं का एक अतिरेक और अप्रत्यक्ष रूप से NOR रखरखाव को समझने में मदद नहीं करता है। और न ही कन्वेक्टेड कन्ट्रोल फ्लो (उर्फ, कॉलबैक नरक) है।

— मैथ्यू एम।

@ जॉन यह स्पष्टीकरण सबसे अच्छा और आसान तरीका है जिसे मैं कभी भी पढ़ सकता हूं।

— एड्रियानो रेपेती

अच्छी तरह से लिखा है, लेकिन क्या यह शायद याद आ रहा है कि "एक बार लेकिन कई बार संशोधित, कई बार बनाया" क्यों महत्वपूर्ण है? (यदि सभी कोड में हैं EntityTransformationServiceImpl, तो आपको यह सीखने के लिए मजबूर किया जाता है कि आप इसे ठीक करने से पहले पूरी बात कैसे काम करते हैं - लेकिन अगर उदाहरण के लिए कुछ गड़बड़ है और एक Formatterवर्ग इसे संभालता है, तो आपको केवल यह सीखने की जरूरत है कि वह भाग कैसे काम करता है । ~ 3 महीने के बाद अपना खुद का कोड पढ़ना किसी अजनबी के कोड को पढ़ने जैसा है।) मुझे लगता है कि हममें से ज्यादातर लोग अवचेतन रूप से इस बारे में सोचते हैं, लेकिन ऐसा अनुभव के कारण हो सकता है। इस पर 100% यकीन नहीं है।

— आर। शमित्ज़

मैं दहन के लिए पूरे 10 × 10 = 100 के लिए जाऊंगा: उन कार्यों को अच्छी तरह से पुनरावर्ती किया जा सकता है, और विशेष रूप से खराब कोड में, स्पष्ट रूप से ऐसा नहीं है।

— केरेन

"विकल्प रखरखाव के लिए अनुकूलन करना है - निर्माण को एक स्पर्श अधिक कठिन बना देता है, लेकिन संशोधनों को आसान या कम जोखिम भरा बनाता है। यह संरचित कोड का उद्देश्य है।" मैं निहित धारणा के साथ मुद्दा लेता हूं कि अधिक वर्ग = अधिक रखरखाव। विशेष रूप से, कई वर्गों में बिखरे हुए तर्क अक्सर कोड में ओवररचिंग लॉजिकल अवधारणाओं को ढूंढना मुश्किल बना देते हैं (विशेष रूप से अवधारणाओं को सुनिश्चित करने के लिए बहुत जानबूझकर आंख के बिना), जो कि स्थिरता को बहुत कम कर देता है।

— jpmc26

Answer 2

ठीक है, सबसे पहले, पठनीयता और मुख्यता अक्सर देखने वाले की आंखों में होती है।

जो आपके लिए पठनीय है वह आपके पड़ोसी के लिए नहीं हो सकता है।

स्थिरता अक्सर खोजशीलता के लिए उबलती है (आसानी से कोडबेस में खोजा गया एक व्यवहार या अवधारणा) और खोजशीलता एक और विषय वस्तु है।

DDD

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

• डोमेन अवधारणाओं को एंटिटीज और एग्रीगेट्स के रूप में एन्कोड किया गया है
• डोमेन व्यवहार एंटिटी या डोमेन सेवाओं में रहता है
• एग्रिगेट रूट्स द्वारा संगति सुनिश्चित की जाती है
• दृढ़ता संबंधी चिंताओं को रिपोजिटरी द्वारा नियंत्रित किया जाता है

इस व्यवस्था को बनाए रखना उद्देश्यपूर्ण नहीं है । हालाँकि इस बात पर है कुछ हद आसान बनाए रखने के लिए जब हर कोई समझता है कि वे एक DDD संदर्भ में सक्रिय रहे हैं।

कक्षाएं

कक्षाएं स्थिरता, पठनीयता, खोजशीलता आदि के साथ मदद करती हैं ... क्योंकि वे एक प्रसिद्ध सम्मेलन हैं ।

ऑब्जेक्ट ओरिएंटेड सेटिंग्स में, क्लासेस का उपयोग आमतौर पर संबंधित व्यवहार को व्यवस्थित करने के लिए किया जाता है और उस अवस्था को एनकैप्सुलेट किया जाता है जिसे सावधानी से नियंत्रित करने की आवश्यकता होती है।

मुझे पता है कि बहुत सार लगता है, लेकिन आप इसके बारे में इस तरह सोच सकते हैं:

कक्षाओं के साथ, आपको यह जानने की आवश्यकता नहीं है कि उनमें कोड कैसे काम करता है। आपको बस यह जानना होगा कि वर्ग किसके लिए जिम्मेदार है।

कक्षाएं आपको अच्छी तरह से परिभाषित घटकों के बीच बातचीत के संदर्भ में आपके आवेदन के बारे में तर्क करने की अनुमति देती हैं ।

यह संज्ञानात्मक बोझ को कम करता है जब आपके आवेदन कैसे काम करता है, इसके बारे में तर्क देता है। यह याद रखने की बजाय कि कोड की 600 लाइनें क्या पूरा करती हैं, आप सोच सकते हैं कि 30 घटक कैसे बातचीत करते हैं।

और, उन 30 घटकों को देखते हुए संभवतः आपके आवेदन की 3 परतें होती हैं , आप शायद केवल एक समय में लगभग 10 घटकों के बारे में तर्क दे सकते हैं।

यह बहुत प्रबंधनीय लगता है।

सारांश

अनिवार्य रूप से, जो आप वरिष्ठ देवों को देख रहे हैं वह यह है:

वे आसानी से कक्षाओं के बारे में तर्क करने के लिए आवेदन को तोड़ रहे हैं ।

फिर वे परतों के बारे में आसान करने के लिए इनका आयोजन कर रहे हैं ।

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

Comments

इसके अलावा छोटी कक्षाओं को बदलना / रिफ्लेक्टर करना आसान होता है।

— ज़ालोमन

Overengineering करता नहीं है कि तुम क्या दावा के बावजूद काफी विपरीत, - अधिक maintainable या समझा जा सकता कोड दे। AddressServiceRepositoryProxyInjectorResolverजब आपको समस्या को अधिक सुरुचिपूर्ण ढंग से हल करने की आवश्यकता होती है, तो आपको कौन चाहिए ? डिज़ाइन पैटर्न के लिए डिज़ाइन पैटर्न केवल आवश्यक जटिलता और क्रियाशीलता की ओर जाता है।

— वाइकिंगस्टीवेट

हाँ, अतिप्रचार बुरा है। इसलिए पिल्लों को मार रहा है। यहां कोई भी वकालत नहीं कर रहा है। logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/…

— मेटाफ़ाइट

इसके अलावा, सॉफ्टवेयर इंजीनियरिंग संदर्भ में "लालित्य" अक्सर एक वैसल वर्ड है। en.wikipedia.org/wiki/Weasel_word

— मेटाफ़ाइट

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

— मेटाफ़ाइट

Answer 3

कृपया मुझे समझाएं, हमें इस डीडीडी शैली, बहुत सारे पैटर्न की आवश्यकता क्यों है?

सबसे पहले, एक नोट: डीडीडी का महत्वपूर्ण हिस्सा पैटर्न नहीं है , लेकिन व्यवसाय के साथ विकास के प्रयास का संरेखण है। ग्रेग यंग ने टिप्पणी की कि नीली किताब में अध्याय गलत क्रम में हैं ।

लेकिन आपके विशिष्ट प्रश्न के लिए: आपकी अपेक्षा से बहुत अधिक वर्ग होते हैं, (क) क्योंकि पाइपलाइन के डोमेन व्यवहार को अलग करने का प्रयास किया जा रहा है और (b) क्योंकि अवधारणाओं को सुनिश्चित करने के लिए अतिरिक्त प्रयास किए जा रहे हैं। डोमेन मॉडल में स्पष्ट रूप से व्यक्त किए जाते हैं।

निस्संदेह, यदि आपके पास डोमेन में दो अलग-अलग अवधारणाएं हैं, तो उन्हें मॉडल में अलग होना चाहिए, भले ही वे मेमोरी प्रतिनिधित्व में समान हों ।

वास्तव में, आप एक डोमेन विशिष्ट भाषा का निर्माण कर रहे हैं, जो व्यवसाय की भाषा में आपके मॉडल का वर्णन करती है, जैसे कि एक डोमेन विशेषज्ञ इसे देखने और त्रुटियों को देखने में सक्षम होना चाहिए।

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

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

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

कोई फर्क नहीं पड़ता कि आप किस भाषा में काम करते हैं, एक कार्यात्मक शैली में प्रोग्रामिंग लाभ प्रदान करती है। जब भी यह सुविधाजनक हो, आपको इसे करना चाहिए और जब यह सुविधाजनक न हो तो आपको निर्णय के बारे में कठिन सोचना चाहिए। कार्मैक, 2012

Comments

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

— प्रहरी

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

— लुआं

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

— jpmc26

Answer 4

अन्य उत्तरों में कई अच्छे बिंदु हैं, लेकिन मुझे लगता है कि वे चूक जाते हैं या एक महत्वपूर्ण वैचारिक गलती पर जोर नहीं देते हैं:

आप पूरा कार्यक्रम समझने के प्रयास की तुलना कर रहे हैं।

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

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

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

मैंने दोनों तरह के सिस्टम में काम किया है। अंतर आसानी से तुलनीय कार्यों और तुलनीय प्रणाली आकार के लिए प्रदर्शन में परिमाण के दो आदेश हो सकते हैं।

इसका प्रभाव अन्य गतिविधियों पर पड़ता है:

• छोटी इकाइयों के साथ परीक्षण बहुत आसान हो जाता है
• मर्ज कम होने के कारण दो डेवलपर्स के एक ही कोड कोड पर काम करने की संभावना कम होती है।
• कम दोहराव क्योंकि यह टुकड़ों का पुन: उपयोग करना आसान है (और पहली जगह में टुकड़ों को खोजने के लिए)।

Answer 5

क्योंकि कोड लिखने की तुलना में परीक्षण कोड कठिन है

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

हालांकि, विचार करने के लिए एक और पहलू है - परीक्षण केवल आपके मूल कोड के रूप में ठीक-ठीक हो सकता है।

यदि आप एक मोनोलिथ में सब कुछ लिखते हैं, तो आप जो एकमात्र प्रभावी परीक्षण लिख सकते हैं, वह है "ये इनपुट दिए गए, क्या आउटपुट सही है?"। इसका मतलब यह है कि किसी भी कीड़े पाए गए, "कोड के उस विशाल ढेर में कहीं" के लिए scoped हैं।

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

समाधान: कई छोटे परीक्षण जो एक विशिष्ट, संभावित विफलता को इंगित करते हैं।

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

जैसा कि स्पष्ट होना चाहिए, छोटे परीक्षण करने का मतलब है कि आपके कोडबेस को छोटे परीक्षण योग्य विखंडू में विभाजित करने की आवश्यकता है। एक बड़े वाणिज्यिक कोडबेस पर ऐसा करने का तरीका, अक्सर कोड में परिणाम होता है जो दिखता है कि आप किसके साथ काम कर रहे हैं।

बस एक साइड-नोट के रूप में: यह कहना नहीं है कि लोग चीजों को "बहुत दूर" नहीं ले जाएंगे। लेकिन कोडबेस को छोटे / कम जुड़े हिस्सों में अलग करने का एक वैध कारण है - अगर समझदारी से काम लिया जाए।

Comments

जबकि आपका जवाब केवल परीक्षण और परीक्षण क्षमता को संबोधित करता है, यह एकमात्र सबसे महत्वपूर्ण मुद्दा है, जिसमें से कुछ अन्य जवाबों ने पूरी तरह से अनदेखा किया है +1।

— स्कोमीसा

Answer 6

कृपया मुझे समझाएं, हमें इस डीडीडी शैली, बहुत सारे पैटर्न की आवश्यकता क्यों है?

हम में से कई (अधिकांश ...) को वास्तव में उनकी आवश्यकता नहीं है। सिद्धांतकार और बहुत उन्नत, अनुभवी प्रोग्रामर बहुत सारे अनुसंधान और उनके गहन अनुभव के परिणामस्वरूप सिद्धांतों और कार्यप्रणाली के बारे में किताबें लिखते हैं - इसका मतलब यह नहीं है कि वे जो कुछ भी लिखते हैं वह उनके रोजमर्रा के अभ्यास में प्रत्येक प्रोग्रामर के लिए लागू होता है।

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

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

एक समय आ सकता है जब आपको पता चलेगा कि आप अपने बारे में जो कुछ पढ़ते हैं उसका उपयोग कर सकते हैं, लेकिन पहले "काफी" नहीं मिला, या शायद नहीं।

Comments

जबकि शुद्ध स्तर पर यह सही है, ऐसा लगता है जैसे DDD और अन्य पैटर्न सिर्फ सिद्धांत हैं। वे नहीं कर रहे हैं वे पठनीय और प्राप्य कोड प्राप्त करने के लिए महत्वपूर्ण उपकरण हैं।

— जेन्स स्काउडर

@PeteKirkham ओपी दुविधा डिजाइन पैटर्न का अति प्रयोग है। क्या आपको वास्तव में एक की आवश्यकता है AccountServiceFacadeInjectResolver(वास्तविक उदाहरण जो मुझे काम में एक प्रणाली में मिला है) - जवाब सबसे संभवत: नहीं है।

— वाइकिंगस्टीवेट

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

— आर। शमित्ज़

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

— लूआन

@ Luaan यदि आप पहले से ही अच्छी तरह से डिजाइन, संगठित, संरचित, OOP के बारे में परवाह करते हैं, तो मैं शायद ही उस शुरुआत करने वाले को फोन करूँगा, लेकिन हाँ अति प्रयोग बुरा है। हालाँकि, यह सवाल अधिक है कि ओपी वास्तव में कैसे समझ नहीं पाता है कि उन समस्याओं का समाधान क्या है। यदि आप कारण नहीं जानते हैं, तो ऐसा लगता है कि कोई कारण नहीं है - लेकिन वास्तव में, आप अभी तक इसे नहीं जानते हैं।

— आर। शमित्ज़

Answer 7

जैसा कि आपका प्रश्न बहुत सारी जमीनों को कवर कर रहा है, बहुत सारी मान्यताओं के साथ, मैं आपके प्रश्न के विषय को बाहर कर दूंगा:

हमें डिजाइन पैटर्न में इतने सारे वर्गों की आवश्यकता क्यों है

हम नहीं। आम तौर पर स्वीकृत नियम नहीं है जो कहता है कि डिजाइन पैटर्न में कई कक्षाएं होनी चाहिए।

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

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

उन दोनों को महत्वपूर्ण क्यों होना चाहिए?

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

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

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

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

कुछ लोग बस उस तरह से काम नहीं करते हैं। वे ऐसी चीज़ों के लिए इंटरफेस (या, अधिक सामान्यतः, अमूर्त आधार वर्ग) बनाते हैं जिनका कभी भी अधिक उपयोग किया जा सकता है; यह एक वर्ग विस्फोट की ओर जाता है।

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

इसलिए, खुले दिमाग को रखना सबसे महत्वपूर्ण बिट है, यहाँ, और यह मेरी प्राथमिक सलाह होगी, यह देखते हुए कि आप इस मुद्दे के बारे में बहुत दर्द में लग रहे हैं, अपने बाकी सवालों को देखते हुए ...

Answer 8

अनुभवी कोडर्स ने सीखा है:

• क्योंकि उन छोटे कार्यक्रमों और clasess बढ़ने लगते हैं, विशेष रूप से सफल होते हैं। यह सरल पैटर्न है कि एक साधारण स्तर पर काम किया पैमाने नहीं है।
• क्योंकि हर ऐड / बदलाव के लिए कई कलाकृतियों को जोड़ना / बदलना भारी पड़ सकता है, लेकिन आप जानते हैं कि क्या जोड़ना है और ऐसा करना आसान है। 3 मिनट की टाइपिंग में 3 घंटे की चतुर कोडिंग होती है।
• छोटी कक्षाओं के बहुत सारे "गन्दा" नहीं है क्योंकि आप यह नहीं समझते हैं कि ओवरहेड वास्तव में एक अच्छा विचार क्यों है
• डोमेन ज्ञान जोड़े बिना, 'मेरे लिए स्पष्ट' कोड अक्सर मेरी टीम के साथियों के लिए रहस्यमय होता है ... साथ ही भविष्य का मुझे भी।
• जनजातीय ज्ञान परियोजनाओं को अविश्वसनीय रूप से कठिन बना सकता है ताकि टीम के सदस्यों को आसानी से और कड़ी मेहनत से उन्हें जल्दी से उत्पादक बनाया जा सके।
• नामकरण कंप्यूटिंग में दो कठिन समस्याओं में से एक है, अभी भी सही है और बहुत सारी कक्षाएं और विधियाँ अक्सर नामकरण में एक गहन अभ्यास है जो कई लोगों के लिए एक बहुत अच्छा लाभ है।

Comments

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

— वाइकिंगस्टीवेट

@vikingsteve आप एक त्रुटिपूर्ण कार्यान्वयन के एकल उदाहरण का उल्लेख करते रहते हैं, यह उम्मीद करते हैं कि यह साबित होगा कि संरचित कोड, सामान्य रूप से, एक बुरा विचार है। वह सिर्फ ट्रैक नहीं करता है।

— मेटाफ़ाइट

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

— क्लीयर

@ क्लेयर मुझे पूरा यकीन है कि यहां हर कोई सहमति में है कि संरचित कोड का काल्पनिक गलत उपयोग एक बुरी बात है। ओपी का कहना है कि वे जूनियर हैं। इसलिए लोग मान रहे हैं कि वह संरचित कोड के लाभों से अपरिचित है और उन्हें दोहरा रहा है।

— मेटाफ़ाइट

Answer 9

अब तक के जवाब, उन सभी को अच्छा लगा, जो उचित धारणा के साथ शुरू हुआ कि पूछने वाला कुछ याद कर रहा है, जिसे पूछने वाला भी मानता है। यह भी संभव है कि पूछने वाला मूल रूप से सही हो, और यह चर्चा करने लायक है कि यह स्थिति कैसे आ सकती है।

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

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

Answer 10

उपयोग के अनुसार अधिक वर्ग और कार्य करना समस्याओं को विशिष्ट तरीके से हल करने के लिए एक महान दृष्टिकोण होगा जो भविष्य में किसी भी मुद्दे को हल करने में मदद करते हैं।

एकाधिक कक्षाएं उनके मूल काम के रूप में पहचान करने में मदद करती हैं और किसी भी समय किसी भी वर्ग को बुलाया जा सकता है।

हालाँकि, यदि आप उनके प्राप्य नाम से कई वर्ग और कार्यों को कॉल करने और प्रबंधित करने में आसान हैं। इसे स्वच्छ कोड कहा जाता है।

Comments

क्षमा करें, लेकिन आप क्या कह रहे हैं?

— डेडुप्लिकेटर

@Deduplicator जावा में एक उदाहरण लेते हैं यदि हम डिजाइन करते हैं कि हमने उनके उत्तराधिकार के लिए जेफर्स थ्रेड्स और कक्षाएं इस्तेमाल की हैं। केवल एक वर्ग से हम डिजाइन के लिए जावा के कुछ कार्यों का उपयोग करने में सक्षम नहीं हो सकते हैं, इसलिए हमें और अधिक कक्षाएं बनाने की आवश्यकता है

— संजीव चौहान

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

— टेलोंक्स