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

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

I इतने सारे वर्ग बनाएँ। यदि हम सॉफ्टवेयर डिजाइन करने की उस पद्धति का अनुसरण करते हैं, तो हम 20-30 वर्गों के साथ समाप्त हो जाते हैं, जिन्हें अधिकांश दो फाइलों और 3-4 कार्यों के साथ बदला जा सकता है। हां, यह गड़बड़ हो सकता है, लेकिन यह बहुत अधिक बनाए रखने योग्य और पठनीय है।

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

सरल गणित:

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

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

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

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

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

UPD 1: I received so many great answers, can you guys please add comment somewhere or edit your answer with the link for reading list (not sure from which to start, DDD, Design Patterns, UML, Code Complete, Refactoring, Pragmatic ,... so many good books), of course with sequence, so that I can also start understanding and become senior as some of you do.

198
@ user1318496 यह उपरोक्त प्रश्न का एक डुप्लिकेट है। आप इस बात से अनजान हैं कि आप वास्तव में क्या पूछ रहे हैं। आपके प्रश्न का सार वास्तव में OO बनाम कार्यात्मक प्रोग्रामिंग या डिज़ाइन पैटर्न और संगठन के साथ करने के लिए सब कुछ नहीं है। जिस प्रश्न का आप वास्तव में उत्तर चाहते हैं, वह यह है कि "अलग परमाणु इकाइयों में अलग कोड क्यों?"। अब, हालांकि कई डेवलपर्स सोच सकते हैं कि इसका उत्तर स्व-स्पष्ट है, मेरा मानना ​​है कि यह एक बहुत ही वैध प्रश्न है। एक कि कई डेवलपर्स एक रूप में दूसरे के साथ संघर्ष करते हैं क्योंकि वे अभी शुरू हो रहे हैं।
जोड़ा लेखक Vassilis, स्रोत
"हाँ, यह गड़बड़ हो सकता है, लेकिन इसके बहुत अधिक बनाए रखने योग्य और पठनीय है।" अगर इसकी गड़बड़ है, तो यह पठनीय और रखरखाव योग्य कैसे हो सकता है?
जोड़ा लेखक Bigballs, स्रोत
@ जेरेड: "कौन सा परीक्षण करना आसान है?": हमेशा की तरह, यह इस बात पर निर्भर करता है कि किस तरह का परीक्षण। यदि आपके पास 100 तुच्छ कक्षाएं हैं और सभी सिस्टम व्यवहार हैं कि वे एक साथ कैसे जुड़े हुए हैं, तो आमतौर पर परिणामी प्रणाली को बोलना एकीकरण लिखना आसान नहीं है और क्यूए परीक्षण भोले अखंड थे। आपके पास 100+ यूनिट परीक्षण हैं जो जोर देते हैं, "आपने अपना डिज़ाइन नहीं बदला है", लेकिन ऐसा क्या है? ओपी अतिरंजित हो सकता है और/या कोड ठीक हो सकता है, लेकिन अगर समान समस्या को हल करने के लिए भोले कोड की 6 लाइनों के अनुपात में वास्तव में 1 वर्ग है, तो यह विचार करने के लिए आधार हैं कि क्या यह अधिक इंजीनियर है :-)
जोड़ा लेखक TraumaPony, स्रोत
और "एक ही समस्या को हल करें" से मेरा मतलब पूरी तरह से हल है, जो एक अन्य क्षेत्र है जो ओपी यह देखने में विफल हो सकता है कि इस कोड आधार के लेखक क्या देखते हैं। कोड की 600 लाइनें जो अधिकांश समय काम करती हैं, एक फ्रेमवर्क में बैठे 100 वर्गों के समान नहीं होती हैं जो बाहरी रूप से उपयोगी प्रमेयों को सिद्ध करते हैं जो आपको यह कटौती करने की अनुमति देते हैं कि कोड वास्तव में काम करता है!
जोड़ा लेखक TraumaPony, स्रोत
@EricLippert: यदि 100 कक्षाओं वाले कोड में सॉफ्टवेयर के उपयोगकर्ता को आसानी से बताई गई विशेषताएं हैं, कि भोला कोड नहीं है, तो हाँ यह एक महान सादृश्य है। मुझे लगता है कि दीवार में एक छेद और चमकता हुआ खिड़की के बीच का अंतर बहुत आसान है, क्योंकि "भोली समाधान वास्तव में समाधान नहीं है क्योंकि यह हमारी वास्तविक उपयोगकर्ता आवश्यकताओं को पूरा नहीं करता है"। इसलिए, यदि हैक किया गया कोड एक दिन में काम करता है, लेकिन उस सॉफ़्टवेयर स्टैक में एकीकृत नहीं किया जा सकता है जो आपकी वास्तविक उपयोगकर्ता-सामना करने वाली सेवाओं को चलाता है, तो वह एक उदाहरण स्लैम-डंक तर्क होगा जो अधिक कक्षाएं लिखने के लिए होगा।
जोड़ा लेखक TraumaPony, स्रोत
@Jared: आप पहले से ही शर्त लगा चुके हैं कि 100 वर्ग मोनोलिथ की तुलना में परीक्षण करना आसान है। मैं केवल उस दावे का जवाब दे रहा था। कोड को बदलने में आसानी मोनोलिथ के खिलाफ एक पूरी तरह से अलग है :-)
जोड़ा लेखक TraumaPony, स्रोत
यह ध्यान दिया जाना चाहिए कि ओओपी एक सार्वभौमिक सबसे अच्छा उपकरण नहीं है, इसलिए अधिक वर्गों को जोड़कर समस्या के हर (भाग) को हल करना, विशेषकर विरासत के साथ, खराब, अनावश्यक रूप से जटिल डिजाइनों को जन्म दे सकता है। समस्या यह है कि एक अच्छे डिज़ाइन के साथ आने में समय लगता है और एक अनुभवी डेवलपर, और दोनों ही महंगे हैं। व्यापार अक्सर एक गन्दा डिजाइन के साथ ठीक है अगर यह काम करता है अभी
जोड़ा लेखक Rorick, स्रोत
जब तक आप जावा नहीं कर रहे हैं, आप नहीं करते। जब आपके पास जावा होता है, तो सब कुछ एक वर्ग की तरह दिखता है।
जोड़ा लेखक Krzysztof Klimonda, स्रोत
सीधे शब्दों में कहें, तो यह अधिक कठिन है और सुरुचिपूर्ण कोड लिखने में अधिक समय लगता है, इसलिए लोग असंगत लेकिन अत्यधिक संरचित कोड के लिए व्यवस्थित होते हैं।
जोड़ा लेखक Mr Rogers, स्रोत
शायद किसी को फिर से आना एक सकते हैं?
जोड़ा लेखक innaM, स्रोत
@ पॉलीग्नोम: मैं उसी टिप्पणी को टाइप करने वाला था। कनिष्ठ डेवलपर्स की एक अन्य पसंद टिप्पणी की विशेषता है "मुझे लगता है कि इस तरह का कोड बहुत धीमी गति से गड़बड़ कोड बनाता है।" यदि आप अपना आधा समय दीवारों में चलाने में बिताते हैं तो आपको उतनी तेजी से भागना अच्छा नहीं लगता! धीमे-धीमे, चिकनी तेजी से।
जोड़ा लेखक CodeCharming, स्रोत
यह सवाल पूछने के बजाय "हमें खिड़की बनाने के लिए इतने सारे हिस्सों की आवश्यकता क्यों है? वहाँ यह सभी शब्दजाल और सैश डोरियों और डबल लटका हुआ और ट्रिपल घुटा हुआ मुकदमों के साथ शब्दजाल है और यह बहुत भ्रामक है। यदि मैं एक दीवार के माध्यम से देखना चाहता हूं एक ड्रिल प्राप्त करें, दीवार में एक छेद ड्रिल करें, किया। क्यों खिड़की बनाने वाले सब कुछ इतना जटिल बनाना चाहते हैं जब मैं इसे बस इतना कर सकता हूं? "
जोड़ा लेखक CodeCharming, स्रोत
मैं सामान्य रूप से user1318496 के रूप में कक्षाओं के बारे में उसी तरह महसूस करना शुरू कर रहा हूं। शायद यह किसी और चीज की तुलना में व्यक्तिगत पसंद की चीज है।
जोड़ा लेखक Graham, स्रोत
@ ग्राहम भाषा की विशेषताएं कुछ हद तक व्यक्तिगत पसंद की हैं, लेकिन वह इस सवाल का मूल है। कार्यात्मक कोड बस आसान बनाने के लिए लिखा जा सकता है बनाम आसान संशोधित करना।
जोड़ा लेखक R. Schmitz, स्रोत
@ 9000 मुझे लगता है कि आप जिस बारे में बात कर रहे हैं उसे COP - "क्लास-ओरिएंटेड प्रोग्रामिंग" कहा जाएगा? यदि आप वास्तव में ऑब्जेक्ट्स के बारे में हूट दिए बिना कक्षाएं जोड़ रहे हैं, तो आप OOP नहीं कर रहे हैं ...
जोड़ा लेखक R. Schmitz, स्रोत
हमें वास्तव में उनकी आवश्यकता नहीं है ...
जोड़ा लेखक Vector, स्रोत
क्या मैं केवल एक ही व्यक्ति हूं जो सोचता है कि शायद एक साधारण समस्या को हल करने के लिए EntityTransformationServiceImpl के साथ 20-30 वर्गों का उपयोग करना भारी इंजीनियरिंग से अधिक है? मैं अनुमान लगा रहा हूं कि आप जावा की बात कर रहे हैं, जिसकी संस्कृति कोड पैटर्न के अनजाने होने तक डिजाइन पैटर्न पर डिजाइन पैटर्न फेंकने की है ...
जोड़ा लेखक Solomonoff's Secret, स्रोत
मुझे लगता है कि यहां एक अच्छा सवाल है, लेकिन यह हाइपरबोले और निराशा के पीछे छिपा है। @ user1318496, आपको अपने प्रश्न को थोड़ा सा पुन: परिभाषित करने से लाभ हो सकता है।
जोड़ा लेखक Warpspace, स्रोत
@jamesqf शायद आप इसे एक धार्मिक रूपांतरण के रूप में देखते हैं। मैं इसे प्रकार के फ़ंक्शन के रूप में देखता हूं <�कोड> धर्म -> धर्म </कोड>
जोड़ा लेखक Chad, स्रोत
इनमें से कुछ जवाब और टिप्पणियां एक-दूसरे से बात कर रही हैं। मुझे लगता है कि दो अलग-अलग सवालों के बारे में सोचने में मदद मिल सकती है, उदा। "डीडीडी/डिज़ाइन-पैटर्न/आदि का उपयोग क्यों करें। सामान्य में 'सरल' कोड के बजाय" (परीक्षणनीयता, डीकोलिंग, आदि) और "क्यों है यह विशेष कोडबेस का उपयोग कर मैं उम्मीद करता हूँ की तुलना में इतने अधिक वर्ग? " (ओवर-इंजीनियरिंग, भाषा-विशिष्ट वर्कआर्ड्स (उदाहरण के लिए कोई लंबदा), पुरानी शैली (जैसे जावा में अब लैम्ब्डा है), कार्गो-कल्टिंग, टेक ऋण, आदि)
जोड़ा लेखक Warbo, स्रोत
मुझे आपका गणित कोड की लाइनों के आसपास लगता है और उनकी समझ काफी हास्यप्रद है। मैं वास्तव में आपके द्वारा उपयोग की जाने वाली संख्याओं के पीछे आपके तर्क का विस्तृत विवरण देखना चाहूंगा।
जोड़ा लेखक Euphoric, स्रोत
"गन्दे कोड की 600 पंक्तियाँ पढ़ना = एक दिन"। यह गलत है ... एक कक्षा को पढ़ने के लिए मुझे जो समय लगता है वह तेजी से बढ़ता है, क्या सभी शाखाएं और शाखा गलतफहमी होगी आदि ... 600 लाइनों में मैं अपने आराम क्षेत्र के किनारे पर हूं। 1000 पर सामान्य रूप से मुझे कक्षा को पूरी तरह से समझने में एक महीने का समय लगता है ...।
जोड़ा लेखक ArTs, स्रोत
F22 रैप्टर को आईकेईए फिक्स्चर के गोदाम में ले जाकर और उन्हें एक हवाई जहाज के आकार के साँचे में डालकर नहीं बनाया गया था।
जोड़ा लेखक ArTs, स्रोत
क्या वे कक्षाएं अवधारणाएँ हैं जो आपके डोमेन में मौजूद हैं? यदि नहीं, तो वे क्यों मौजूद हैं? यदि वे करते हैं, तो उनके पास व्यावसायिक मूल्य है, है ना? यदि आप डोमेन अवधारणाओं का प्रतिनिधित्व करने वाले 20-30 वर्गों बनाम गंदे कोड की 600 पंक्तियों को लिखते हैं तो आप किस भविष्य के लचीलेपन को ढीला करते हैं?
जोड़ा लेखक Rob Crawford, स्रोत
OOP अक्सर एक विरोधी पैटर्न है, और शुद्ध OOP लगभग हमेशा एक विरोधी पैटर्न है। OOP आपके कोड में सभी प्रकार के स्थानों पर खून बहता है, विशेषकर परीक्षण क्षमता। डिज़ाइन पैटर्न ओओपी के अति प्रयोग के साथ बिखरे हुए इन सभी नाखूनों में ड्राइव करने के लिए हथौड़ा (ओओपी) का उपयोग करते हैं। यदि आपके पास नाम प्रदाता , Entity , या Processor के साथ एक वर्ग है, तो आप संभवतः OOP से अधिक उपयोग कर रहे हैं, लेकिन आप निश्चित रूप से बहुत सारे लोगों को ढूंढ सकते हैं जो पता लगा लिया है कि कैसे उस नाखून को ओओपी।
जोड़ा लेखक Rich Remer, स्रोत
ध्यान दें कि कोड लिखने का यह विशेष तरीका पैटर्न के साथ समस्या नहीं है, लेकिन कोड लिखने वाले लोगों के साथ है। आप बहुत सारे पैटर्न और शायद 40 या 50 वर्गों के साथ एक समृद्ध सॉफ्टवेयर लिख सकते हैं; आसान। लेकिन अगर आप चीजों को खत्म कर देते हैं ... ठीक है, तो आप 20 कक्षाओं के लिए कुछ ऐसा करते हैं जो 3 वर्गों या 4 से 5 प्रक्रियात्मक कार्यों के साथ किया जा सकता है। महत्वपूर्ण कौशल पहचान रहा है जब एक वर्ग बहुत बड़ा होने वाला होता है, ताकि वह एक देव वर्ग न बन जाए।
जोड़ा लेखक marstato, स्रोत
ओपी रक्षा में, वह जिस बात का जिक्र कर रहा है, उसका एक अच्छा उदाहरण हर जगह राज्य पैटर्न के साथ 3 या 4 कम मूल्य की शर्तों पर सरल स्विच की जगह है। मैंने ऐसा होते देखा है और परिणाम वास्तव में कोड की सौ पंक्तियों के बजाय सौ वर्ग हो सकते हैं। रखरखाव से भी समझौता किया जाता है।
जोड़ा लेखक Sentinel, स्रोत
विश्वास नहीं कर सकता कि किसी ने भी सिंगल रिस्पांसिबिलिटी प्रिंसिपल का उल्लेख नहीं किया है (जो, यदि आप इसका पालन करते हैं, तो सामान्य रूप से कई वर्गों के उत्पादन का नेतृत्व करता है) और एसओएलआईडी सिद्धांत।
जोड़ा लेखक sizzlecookie, स्रोत
@ user1318496 - आपको चिंता करने की ज़रूरत नहीं है, बहुत सारी सफल कंपनियां हैं जो आपकी राय साझा करती हैं। और वे हर समय काम पर रखते हैं, क्योंकि कोड को बनाए रखने के लिए अधिक डेवलपर्स की आवश्यकता होती है जो जल्दी से लिखा गया था .. :)
जोड़ा लेखक Fabio, स्रोत
दशकों पहले मैंने एक दुकान में काम किया था जहाँ हमने (I think) DOS 2.0 से DOS 3.0 में अपग्रेड किया था। पहले संस्करण में, इसमें सब कुछ के साथ केवल एक ही निर्देशिका थी। उत्तरार्द्ध में, सबफ़ोल्डर पेश किए गए थे। मेरे मालिक ने पूछा, "हमें इन सभी सबफ़ोल्डरों की आवश्यकता क्यों है? मैं सिर्फ एक फ़ोल्डर में सब कुछ क्यों नहीं डाल सकता, इसलिए मुझे पता है कि इसे कहां खोजना है?" अच्छा समय। :)
जोड़ा लेखक David Lang, स्रोत
डिज़ाइन पैटर्न केवल स्थिरता के बारे में नहीं है, लेकिन यह पुन: प्रयोज्य के बारे में भी है।
जोड़ा लेखक Randy E, स्रोत
पैर की उंगलियों पर कदम रखने के जोखिम पर, क्योंकि आपकी भाषा बेकार है। इससे अधिक के लिए इसे न लें: विभिन्न प्रकार के कारणों के लिए एक चुस्त भाषा अक्सर सही तकनीकी विकल्प है, लेकिन यह इसे गैर-बेकार नहीं बनाती है। आपके वास्तविक प्रश्न के लिए, पठनीयता की तुलना में शुद्धता अधिक महत्वपूर्ण है। या कि थोड़ा अलग तरीके से कहें: पठनीयता मायने रखती है क्योंकि शुद्धता के बारे में तर्क सक्षम बनाता है। तो जो परीक्षण करने के लिए आसान है, आपके 100 वर्ग या आपके अखंड देव वर्ग? मैं 100 सरल कक्षाओं में दांव लगा रहा हूं।
जोड़ा लेखक Sujan, स्रोत
@SteveJessop हां, सिस्टम का परीक्षण करना दोनों ही मामलों में समान रूप से जटिल है। शायद और भी कई वर्गों के मामले में। अंतर यह है: मोनोलिथ के साथ जबकि यह आसान हो सकता है जहां एक बदलाव करने के लिए, संभावित रूप से अनबाउंड समय उस सामान को ठीक करना जो इसे बनाने से टूट सकता है। स्प्लिट-अप कोडबेस में कोड का सही टुकड़ा खोजना कठिन है, लेकिन एक ज्ञात मात्रा है, और परिवर्तन करना तुच्छ है। मैं पासा रोल करने के बजाय आश्वस्त होना चाहता हूं, लेकिन YMMV और एक आकार सभी फिट नहीं है। 10k लाइनों से कम की किसी चीज के लिए, मैं मोनोलिथ पसंद कर सकता हूं। शायद।
जोड़ा लेखक Sujan, स्रोत
@ थियोडोरोस चटजिआनकिंसिस: यह सिर्फ एक धार्मिक रूपांतरण है। समस्या एक सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी की अनथक पूजा है। आप सिर्फ देवता बदलते हैं, लेकिन अनुष्ठान के लिए अडिग पालन करते हैं।
जोड़ा लेखक Ruks, स्रोत
@ रब क्रॉफर्ड: रे "... गन्दे कोड की 600 लाइनें बनाम 20-30 कक्षाएं ...", आपको यहां दो असंबंधित चीजें मिली हैं। यह पूरी तरह से स्पष्ट, अच्छी तरह से टिप्पणी की गई कोड की 600 पंक्तियों को लिखना संभव है, बस इसे 20-30 गन्दा कक्षाओं में बदलना संभव है।
जोड़ा लेखक Ruks, स्रोत

10 उत्तर

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

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

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

सॉफ्टवेयर उसी तरह है। आप निश्चित रूप से उत्पाद निर्माण के लिए ऑप्टिमाइज़ कर सकते हैं - ठोस सिद्धांतों।

323
जोड़ा
@ jpmc26 गैर-तुच्छ ओओपी कार्यक्रम (कहते हैं> 10k लोकेशन) का एक उदाहरण क्या होगा जो न्यूनतम संख्या में कक्षाओं का उपयोग करता है और बनाए रखने और पढ़ने में आसान है? इसके अलावा मुझे कोड पढ़ने की जटिलता पर असहमत होना पड़ेगा। यहां तक ​​कि एक आईडीई में कोड लोड किए बिना भी RestoreRunner.RunAsync से RestoreCommand और इतने पर पालन करना बहुत आसान लगता है। मुझे लगता है कि समस्या यह है कि आपने याद किया कि नुगेट्स एक साधारण सूची नहीं है, लेकिन इन दिनों PackageReference के साथ एक पेड़ है जो आपके मानसिक मॉडल में एक रिंच फेंकता है।
जोड़ा लेखक Kyle Hodgson, स्रोत
@Holger इसलिए जब मोज़िला ने अपने ब्राउज़र को पूरी तरह से फिर से लिखने के लिए फ़ायरफ़ॉक्स में नई सुविधाओं को जोड़ना कई सालों से बंद कर दिया था? उन्होंने नहीं किया। सुनिश्चित करें कि आप कोड के कुछ हिस्सों को बदल सकते हैं और एक प्राकृतिक विकास है, लेकिन एक पूर्ण पुनर्लेखन जहर है (दूसरी कंपनी जो IE6 और 8 के बीच एमएस थी .. ने नेटस्केप की तुलना में उनके लिए उतना बेहतर काम नहीं किया)
जोड़ा लेखक Kyle Hodgson, स्रोत
@ होल्गर आप दावा करते हैं कि आज "केवल ब्राउज़र जो या तो स्क्रैच से फिर से लिखे गए हैं या वे लंबे समय तक मौजूद नहीं हैं"। यह तो झूठा है। मुझे संदेह है कि आपको कोई भी लोकप्रिय उत्पाद मिलेगा जो स्क्रैच से फिर से लिखा गया था और अभी भी उतना ही सफल है जितना पहले था (क्योंकि आपके द्वारा उल्लेखित उदाहरण सत्य नहीं है, मुझे संदेह है कि आप एक बेहतर जानते हैं) केवल ब्राउज़र विक्रेता, जो IE6 के बाद नेटस्केप Microsoft के समान था। और वे एक नाबालिग खिलाड़ी के लिए 90% बहुमत से चले गए और यह कि ब्राउज़र को ग्रह पर सबसे लोकप्रिय ऑपरेटिंग सिस्टम के साथ बंडल करने के बावजूद ... बड़ी सफलता है।
जोड़ा लेखक Kyle Hodgson, स्रोत
खरोंच और दूसरी प्रणाली सिंड्रोम से फिर से भरना एक उत्पाद को मारने का एक निश्चित तरीका है, यही कारण है कि कोई भी अभी भी आसपास नहीं कर रहा है। आप जो कर रहे हैं वह नई सुविधाओं को लागू करते समय मौजूदा कोड में सुधार कर रहा है। या आप एक आवश्यकता के आधार पर आवेदन के छोटे भागों को फिर से लिखने का निर्णय ले सकते हैं (सुरक्षा या प्रदर्शन आमतौर पर, बहुत कम ही रखरखाव के लिए)। लेकिन खरोंच से एक फिर से लिखना? जोएल लेख कई, कई कारण देता है कि यह इतना बुरा विचार क्यों है।
जोड़ा लेखक Kyle Hodgson, स्रोत
हालाँकि, मैं ध्यान दूंगा कि कक्षाओं और अप्रत्यक्षता का एक अतिरेक NOR रखरखाव को समझने में मदद नहीं करता है। और न ही कन्वेक्टेड कन्ट्रोल फ्लो (उर्फ, कॉलबैक नरक) है।
जोड़ा लेखक Owen, स्रोत
"विकल्प रखरखाव के लिए अनुकूलन करना है - निर्माण को एक स्पर्श अधिक कठिन बना देता है, लेकिन संशोधनों को आसान या कम जोखिम भरा बनाता है। यह संरचित कोड का उद्देश्य है।" मैं निहित धारणा के साथ मुद्दा लेता हूं कि अधिक वर्ग = अधिक रखरखाव। विशेष रूप से, कई वर्गों में बिखरे हुए तर्क अक्सर कोड में अतिव्यापी तार्किक अवधारणाओं को खोजना मुश्किल बना देते हैं (विशेष रूप से अवधारणाओं को सुनिश्चित करने पर बहुत जानबूझकर आंख के बिना), जो स्थिरता को काफी कम कर देता है।
जोड़ा लेखक jmibanez, स्रोत
मेरे जाने का उदाहरण हाल ही में बन गया है NuGet की पुनर्स्थापना कमांड । पुनर्स्थापना के तीन मूल चरण हैं: पैकेजों की सूची में पढ़ें, उन्हें डाउनलोड करें और फिर उन्हें डिस्क पर निकालें। हालांकि, उन चरणों में से प्रत्येक में निश्चित रूप से जटिलताएं होती हैं, यह अपेक्षाकृत कठिन है कि जहां कोड लागू किए जाते हैं, उन हिस्सों को अपेक्षाकृत बड़ी संख्या में और आंशिक रूप से इस तथ्य के कारण ट्रैक करना कि इन अवधारणाओं का खुलासा नहीं होता है। नामकरण और संगठन में एक प्राथमिकता रही है।
जोड़ा लेखक jmibanez, स्रोत
@Voo मुझे यह पता लगाने में परेशानी हुई कि किस वस्तु ने कमांड शुरू किया; कमांड लाइन पार्स करने के लिए ओओ दृष्टिकोण के साथ यह सब अस्पष्ट है। एक बार जब आप यह पता लगा लेते हैं कि यह RestoreRunner है, तो आप इसके माध्यम से यह पता लगाने की कोशिश करते हैं कि इसके "अनुरोध" कैसे बनाए जाते हैं, जो आपको प्रदाता ऑब्जेक्ट में कॉल में लगभग 4 विधि कॉल के माध्यम से नीचे ले जाता है, अगर मैं पढ़ रहा हूं यह सही। एक पेड़ खोजना आश्चर्यजनक नहीं है, लेकिन सिर्फ इसे खोजने से बहुत अधिक परतें शामिल हैं। मैं चालाक नहीं हूँ। मुझे ऐसा कोड पसंद है जो इसके पीछे के इरादे को प्रकट करने के लिए सावधानी से तैयार किया गया है, और वहां वस्तु केंद्रित दृष्टिकोण खराब अमूर्तता को बढ़ाता है।
जोड़ा लेखक jmibanez, स्रोत
@JohnWu NuGet मॉड्यूलर होने पर बहुत कठिन विफल रहता है। इसके साइड लाइब्रेरी (जैसे NuGet.Frameworks ) हैं पूरी तरह से undocumented (मैं भी उनके निर्माण के लिए स्रोत खोजने में सक्षम नहीं किया गया है।), कमांड लाइन उपकरण वी.एस. प्लग-इन की कार्यक्षमता को बहुत याद कर रहा है, और कोड को देखते हुए, इतनी सारी वस्तुओं का निर्माण करने की आवश्यकता है एक टुकड़ा काम करने का मतलब है कि आपके पास इसके किसी भी उपयोग के लिए पूरे कोड आधार की बहुत व्यापक समझ होनी चाहिए। यह पहले से ही प्रभावी रूप से अखंड है, इसलिए मैं आपके तर्क को नहीं खरीदता।
जोड़ा लेखक jmibanez, स्रोत
@JohnWu सिवाय इसके कि व्यापक पैटर्न की ओर देखें। DI को धार्मिक रूप से स्वीकार किया जाता है। कोई DI प्रस्तावक मुझे पता नहीं है, "यहां बताया गया है कि यहाँ एक समस्या है जो DI को हल करने में अच्छा लग रहा है," वे कहते हैं, "आपको OO कोड लिखना चाहिए और इसका मतलब है कि आपको DI चाहिए और ओह, btw, आपको ठोस सिद्धांतों का पालन करना चाहिए । " वस्तुतः कोई भी इस बारे में बात नहीं करता है कि इन विचारों को वास्तव में हल करने के लिए क्या समस्याएं हैं। वे सिर्फ नियमों के रूप में पेश किए जाते हैं जो हर समय लागू होते हैं।
जोड़ा लेखक jmibanez, स्रोत
@ R.Schmitz वास्तव में अच्छे प्रोग्रामर पहली बार में नियमों के संदर्भ में नहीं सोचते हैं। वे समस्याओं को सुलझाने के संदर्भ में सोचते हैं। इससे भी महत्वपूर्ण बात यह है कि अच्छे प्रोग्रामर पहचानते हैं जब अन्य प्रोग्रामर पहले से ही उस मानसिकता में नहीं होते हैं और नियमों को बताते हुए उन्हें इस ओर धकेलते हैं।
जोड़ा लेखक jmibanez, स्रोत
@ R.Schmitz मैं कह रहा हूँ कि वास्तव में अच्छे प्रोग्रामर सोच को पलट देते हैं। वे नहीं सोचते, "आपको पठनीयता के लिए अपने कोड का अनुकूलन करना चाहिए।" वे सोचते हैं, "हमें समय पर या अन्य डेवलपर्स द्वारा परिवर्तन करने के लिए कोड को समझने में सक्षम होने की समस्या को हल करने की आवश्यकता है।" सबसे पहले समस्या को समझाए बिना एक समाधान लागू करता है। दूसरा समस्या को बताता है और विभिन्न समाधानों के लिए खुला रहता है, और इसका एक लक्ष्य है कि यह बहुत स्पष्ट है जब आप सफल हुए हैं या नहीं (भले ही यह अभी भी व्यक्तिपरक है)।
जोड़ा लेखक jmibanez, स्रोत
मैं दहन के लिए पूर्ण 10 × 10 = 100 के लिए जाऊंगा: उन कार्यों को अच्छी तरह से पुनरावर्ती किया जा सकता है, और विशेष रूप से खराब कोड में, स्पष्ट रूप से ऐसा नहीं है।
जोड़ा लेखक LessIsMore, स्रोत
अच्छी तरह से लिखा है, लेकिन क्या यह याद आ रहा है कि "एक बार लेकिन कई बार संशोधित, कई बार बनाया" क्यों महत्वपूर्ण है? (यदि सभी कोड EntityTransformationServiceImpl में है, तो आप इसे ठीक करने से पहले कैसे पूरी बात काम करते हैं जानने के लिए मजबूर हैं - लेकिन अगर उदाहरण के लिए प्रारूप में कुछ गलत है और फॉर्मैटर क्लास हैंडल करता है, आपको केवल सीखने की ज़रूरत है यह हिस्सा कैसे काम करता है इसके अलावा ~ 3 महीने के बाद अपना खुद का कोड पढ़ना एक अजनबी कोड को पढ़ने की तरह है।) मुझे सबसे ज्यादा अच्छा लगता है। हमारे अवचेतन से इस बारे में सोचा, लेकिन अनुभव के कारण हो सकता है। इस पर 100% यकीन नहीं है।
जोड़ा लेखक R. Schmitz, स्रोत
@ होलर नं, क्योंकि नया कोड जोड़ते समय, पिछला कोड आपके लेखन मानकों जितना महत्वपूर्ण नहीं होता है। यदि सॉफ़्टवेयर कोड जोड़ने के लिए इसे बहुत महंगा बनाता है, तो यह सिर्फ गन्दा कोड है। आपके पास एक पूरी तरह से मॉड्यूलर परियोजना हो सकती है, लेकिन कुछ त्वरित और आसान कोड जोड़ें। आपके पास एक ईश्वर वर्ग में एक संपूर्ण कार्यक्रम भी हो सकता है, लेकिन बाद में अपने जोड़ को कैसे बनाए रखा जा सकता है, इस पर कुछ विचार करें। उन कंपनियों के बारे में जिन्हें आप बोलते हैं, मैंने केवल एक और इसे नेटस्केप कहा जाता था।
जोड़ा लेखक R. Schmitz, स्रोत
@Holger यदि कोई कंपनी एक नया उत्पाद बनाती है जो कोड आधार का पुनर्लेखन नहीं कर रही है, तो यह इसे पहले स्थान पर बना रहा है। अन्यथा आप तर्क दे रहे हैं कि आज का ऑटोकैड और 3 डीएसएमएक्सएक्स आदि 1968 के यूआईएसयूआरएफ और कॉल ऑफ ड्यूटी के केवल "पुनर्लेखन" हैं: आधुनिक युद्ध 3 केवल डीओएम का एक पुनर्लेखन है। इसके अलावा, मैं यह नहीं कह रहा हूं कि ऐसा नहीं होता, बस उन मामलों में अगर यह बेहतर नहीं होता।
जोड़ा लेखक R. Schmitz, स्रोत
@Holger आपकी बातों के साथ-साथ मैंने जो कुछ भी लिखा है वह गलत है। कॉल ऑफ़ ड्यूटी डूम का पुनर्लेखन है। यह पूरी तरह से अलग डेवलपर द्वारा एक पूरी तरह से अलग उत्पाद है। निश्चित रूप से, आप कह सकते हैं कि कोड का हर टुकड़ा कोड के पहले टुकड़े का एक पुनर्लेखन है जो कभी लिखा गया है, लेकिन यह शब्द किसी भी व्यावहारिक अर्थ को खो देता है और आपको संभवतः फिर यहां एक प्रश्न पोस्ट करें ।
जोड़ा लेखक R. Schmitz, स्रोत
@ होलजर लुक, फ़ायरफ़ॉक्स 2004 में रिलीज़ हुआ है, जो कि 14 साल है; 2007 में Android, कि 11 साल है। IT में, यह केवल पुराना नहीं है, यह प्राचीन है। आपके सिद्धांत के अनुसार, फ़ायरफ़ॉक्स को "पुराना, पैचेड" (एक ही समय में) होना चाहिए था, 2006 तक अनुपयोगी गड़बड़, या 2010 के आसपास एंड्रॉइड। यह केवल बनाए रखने योग्य कोड की दक्षता से वंचित है, क्योंकि वे अब बेहतर हैं लगभग हर पहलू में - सुरक्षा, प्रयोज्य, सुविधा सेट, आप इसे नाम देते हैं। ऐसा लगता है जैसे आपके पास मेंटेनेंस कोड के खिलाफ एक व्यक्तिगत एजेंडा है।
जोड़ा लेखक R. Schmitz, स्रोत
@ jpmc26 ऐसा इसलिए है क्योंकि अच्छे प्रोग्रामर जानते हैं कि सभी "नियमों" को व्यावहारिक रूप से लागू किया जाना है; सभी नियमों को स्वचालित रूप से एक "मिलता है, सिवाय इसके अगर आपके पास अंत में" के लिए वास्तव में अच्छा कारण है। यदि आप ऐसे लोगों के साथ काम करते हैं जो व्यावहारिक होने के बजाय हठधर्मी हैं, तो यह किसी नियम के लिए बुरा होगा।
जोड़ा लेखक R. Schmitz, स्रोत
@ होल्गर फिर से, आपका प्रारंभिक कथन था " सॉफ़्टवेयर को इस तरह से डिज़ाइन किया गया है कि यह बहुत महंगा बनाता है, इसलिए हमें इसे तब तक बनाए रखना और बनाए रखना होगा जब तक हम इस बिंदु पर नहीं पहुंच जाते हैं कि यह पूरी तरह से पुराना, गड़ा हुआ गड़बड़ है। "मेरे द्वारा जोड़ा गया लेख आपको अधिक जानकारी दे सकता है कि यदि आप रुचि रखते हैं तो पुनर्लेखन बुरे क्यों हैं। फ़ायरफ़ॉक्स और एंड्रॉइड द्वारा आपका प्रारंभिक कथन गलत साबित हुआ है। उसके बाद सब कुछ बस एक चर्चा थी, जो टिप्पणी के लिए नहीं हैं, तो चलो अब यहाँ इसे रोक दें।
जोड़ा लेखक R. Schmitz, स्रोत
@ होल्गर आपने लिखा [A] महत्वपूर्ण हो सकता है क्योंकि [B] कारण [C] है। यही आपके "हो सकता है" पर लागू होता है। आपके पास जो सिद्धांत था वह यह है कि [B] कारण [C] है। दो विशाल उदाहरण जहां यह लागू नहीं होता है वह यह साबित करता है कि [B] कारण नहीं है [C]। यदि आपकी बात कुछ और थी, तो मैंने यह नहीं माना और केवल यह दिखाया कि आपका एक परिसर गलत था।
जोड़ा लेखक R. Schmitz, स्रोत
@ jpmc26 मैं उद्धरण चिह्नों में "नियम" डालता हूं क्योंकि वे दिशानिर्देश हैं। एक नियम "आपको चाहिए" से शुरू नहीं हो सकता। अगर कोई " जैसे मूलभूत दिशा-निर्देशों का पालन नहीं करता है, तो आपको पठनीयता के लिए अपने कोड का अनुकूलन करना चाहिए " या " आपको टीम के कोड सम्मेलनों का पालन करना चाहिए ", (सभी को जोड़कर "सिवाय इसके कि अगर आपके पास वास्तव में अच्छा कारण नहीं है"), तो वे एक
जोड़ा लेखक R. Schmitz, स्रोत
@ jpmc26 मेला पर्याप्त है, लेकिन आपको बताए जाने के बाद 5 क्यों-सवाल पूछना "आपको टीम के कोड सम्मेलनों का पालन करना चाहिए" आपके करियर के लिए अच्छा नहीं है। कभी-कभी स्पष्टीकरण को जोड़ना हमेशा स्पष्ट होता है।
जोड़ा लेखक R. Schmitz, स्रोत
@ jpmc26 "मैं इस धारणा के साथ मुद्दा उठाता हूं कि अधिक वर्ग = अधिक रखरखाव।" निर्भर करता है, निश्चित रूप से, "अधिक" का ऑपरेंड क्या है। इस मामले में, यह "50K एलओसी गड़बड़ कोड है।" इसलिए मुझे यकीन नहीं है कि मैं ओपी के पद के विशिष्ट संदर्भ में सहमत हूं।
जोड़ा लेखक John Wu, स्रोत
नगेट शायद एक महान उदाहरण नहीं है, क्योंकि इसकी माप्यता बाहरी आवश्यकताओं से अधिक हो सकती है, जो कि आर्किटेक्ट के ओवरथ्यूसिस्म से अधिक है - यह, आखिरकार, एक्स्टेंसिबल फ्रेमवर्क के प्रबंधन के लिए एक एक्स्टेंसिबल फ्रेमवर्क है, जो एक विजुअल स्टूडियो एक्सटेंशन के अंदर पॉवरसैट कमांडलेट के रूप में चलता है। अब जब मैं इसके बारे में सोचता हूं, अगर उन सभी चीजों को अखंड रूप से लिखा जाता है, तो नुगेट भी मौजूद नहीं हो सकता है ..।
जोड़ा लेखक John Wu, स्रोत
@ होल्गर अपनी पोस्ट में मैं दो संभावित अनुकूलन लक्ष्यों पर चर्चा करता हूं। निश्चित रूप से आप अन्य लक्ष्यों के लिए भी अनुकूलन कर सकते हैं- उदा। "पुनर्लेखन की न्यूनतम संख्या" (जो कि स्थिरता के लिए अनुकूलन के लिए बहुत समान है) या "पुन: लिखने में आसानी को अधिकतम करने के लिए", जो समान है लेकिन उत्पाद निर्माण में आसानी के लिए अनुकूलन के समान नहीं है (अतिरिक्त आवश्यकताएं हैं जैसे पिछड़ी संगतता सुविधा समता)। मैं एक लक्ष्य निर्धारित नहीं करता हूं, मैं बस अंतर को उजागर करना चाहता हूं, सावधान डिजाइन के लिए तर्क को समझाने के साधन के रूप में।
जोड़ा लेखक John Wu, स्रोत
@ तव "हर तरह से और हर कीमत पर धार्मिक रूप से डिजाइन पैटर्न पाते हैं।" यह एक डिजाइन निर्णय (आउटपुट) की तरह लगता है एक डिजाइन लक्ष्य (इनपुट) नहीं। जब आप ऑप्टिमाइज़ेशन इनपुट में अपने वांछित आउटपुट को फ्रंट-लोड कर रहे होते हैं, तो प्रक्रिया बहुत अधिक मूल्य नहीं जोड़ रही है (यह एंडोजेनिटी के परीक्षण में विफल रहता है), a.k.a आप इसे गलत कर रहे हैं। अपने वास्तुकार की तरह लगता है कि बस एक "पेट NFR ," है जो हमेशा खराब होता है।
जोड़ा लेखक John Wu, स्रोत
@ जॉन यह स्पष्टीकरण सबसे अच्छा और आसान तरीका है जिसे मैं कभी भी पढ़ सकता हूं।
जोड़ा लेखक Les H, स्रोत
जब मैं पहली बार कोड करना सीख रहा था, तो मैंने एक कक्षा के भीतर एक कार्यक्रम लिखा था, यह अच्छी तरह से काम किया था लेकिन उस बिंदु पर पहुंच गया जहां एक साधारण बदलाव करने से 4 या 5 बग आएंगे जो मुझे ठीक करने में कुछ दिन लगेंगे। मैंने डिजाइन पर शोध करना शुरू किया और लगभग 10 वर्गों में सब कुछ तोड़ दिया और मेरे रखरखाव की समस्याएं गायब हो गईं। मैंने इस रिफ्लेक्टर के बाद शुरू किए गए 0 बग के साथ कई बदलाव किए। मुझे लगता है कि इस पाठ को वास्तव में समझने का कठिन तरीका सीखना है कि यह इसके लायक क्यों है।
जोड़ा लेखक reggaeguitar, स्रोत
@Voo जो "कक्षाओं की न्यूनतम संख्या" की परिभाषा पर निर्भर करता है। हमारे पास हजारों वर्गों से मिलकर एक एप्लिकेशन है, फिर भी, मुझे पता है कि क्या हमने कुछ सामान्य रूप से उपयोग किए जाने वाले फ्रेमवर्क और "सर्वोत्तम प्रथाओं" का उपयोग किया है, तो हमारे पास बीस गुना संख्या थी ...
जोड़ा लेखक Holger, स्रोत
@ R.Schmitz जो एक दिलचस्प बिंदु है। "एक बार बनाया गया, लेकिन कई बार संशोधित, कई बार" महत्वपूर्ण हो सकता है क्योंकि सॉफ़्टवेयर को इस तरह से डिज़ाइन किया गया है कि यह बहुत महंगा बना देता है, इसलिए हमें इसे तब तक बनाए रखना और बनाए रखना होगा जब तक हम इस बिंदु पर नहीं पहुंच जाते कि यह पूरी तरह से पुरानी, ​​गंदी गंदगी को मरना पड़ता है। हर कोई इस पैटर्न का पालन नहीं करता है। ऐसी कंपनियां हैं जो एक सॉफ्टवेयर का विमोचन करती हैं, हमेशा वह दिन होता है जब नए संस्करण का विकास शुरू होता है, जिसे स्क्रैच से लिखा जाता है, जिसमें पिछले संस्करण को विकसित करने से सीखे गए सभी पाठों को शामिल किया जाता है, साथ ही साथ नई आने वाली प्रौद्योगिकियां भी होती हैं।
जोड़ा लेखक Holger, स्रोत
@ R.Schmitz क्या आप जानते हैं कि उस समय के सभी ब्राउज़र मूल मोज़ेक पर आधारित थे, जिनमें, उदा। इंटरनेट एक्सप्लोरर, एक नाम के लिए जो अभी भी मौजूद है? आप क्या सोचते हैं, आज के कितने ब्राउज़र अभी भी इसके आधार पर हैं? आज, केवल ब्राउज़र हैं जो या तो, स्क्रैच (एक समय से अधिक) से फिर से लिखे गए हैं और तब तक मौजूद नहीं हैं। एक सिद्धांत की दुनिया में, पहला ब्राउज़र एक मॉड्यूलर, एक्स्टेंसिबल, फ्यूचर-प्रूफ तरीके से लिखा जा सकता था, जो भी भविष्य में बदलाव लाएगा उसके लिए तैयार रहना। वास्तव में, नहीं। आवश्यकताएँ और प्रौद्योगिकियाँ बहुत बदल जाती हैं।
जोड़ा लेखक Holger, स्रोत
@ R.Schmitz इसलिए आप कह रहे हैं कि यह बेहतर होगा अगर "कॉल ऑफ़ ड्यूटी: मॉडर्न वारफेयर 3" कयामत के स्रोत कोड पर आधारित था और यह डूम के खराब सॉफ्टवेयर डिज़ाइन का संकेत है कि यह isn 'टी? या क्या आप वास्तव में मेरी बात की पुष्टि कर रहे हैं कि पुराने सॉफ़्टवेयर को नए से बदल दिया जाएगा, क्योंकि पुराने को अपडेट करना एक भ्रम है?
जोड़ा लेखक Holger, स्रोत
@ क्या मैं यह नहीं देख पा रहा हूं कि मैंने दावा किया है कि सभी सॉफ्टवेयर डेवलपर ऐसा करते हैं। हो सकता है कि आपने सही किया हो और नेटस्केप के लिए फिर से डिज़ाइन किए गए स्क्रैच रिप्लेसमेंट के रूप में अपना जीवन शुरू करने के बाद फ़ायरफ़ॉक्स को कभी भी खरोंच से मुक्त नहीं किया गया। शायद यह संकेत है कि फ़ायरफ़ॉक्स को कितनी अच्छी तरह से डिज़ाइन किया गया है। या हो सकता है, आप अभी एक फ़्लैमर शुरू करने वाले हों, क्योंकि फ़ायरफ़ॉक्स की गुणवत्ता वास्तव में विवादास्पद है। कीड़ा नहीं खोल सकता।
जोड़ा लेखक Holger, स्रोत
@ R.Schmitz ऐसा लगता है कि आप इस बिंदु को पूरी तरह से याद कर रहे हैं। इससे कोई फर्क नहीं पड़ता कि नया सॉफ्टवेयर किसी पुराने का "फिर से लिखना" है या पूरी तरह से नया उत्पाद है। मुद्दा यह है, यह नया सॉफ़्टवेयर है, जिससे यह कोई फर्क नहीं पड़ता कि पुराने का रखरखाव कितना आसान है। क्या तुम्हें अब समझ में आया? पुराना सॉफ्टवेयर मर जाएगा। पुराने सॉफ्टवेयर को नए से बदला जाएगा। यह एक अपरिहार्य तथ्य है। आप केवल यह प्रभावित कर सकते हैं कि वह नया आपका है या आपके प्रतिस्पर्धियों का। लेकिन आप रखरखाव के लिए अपने सॉफ़्टवेयर का अनुकूलन भी कर सकते हैं, जिससे नए सॉफ़्टवेयर का विकास महंगा हो सकता है, और हमेशा के लिए नया लिखने से बचने की कोशिश करें
जोड़ा लेखक Holger, स्रोत
@ वास्तव में, Microsoft केवल वही था जिसने अपने ब्राउज़र को स्क्रैच से फिर से लिखा था। अब, नाम कोई ब्राउज़र इसके अलावा Microsoft से जो उस समय (नेटस्केप 4 या पहले) मौजूद था जो आज भी मौजूद है (एक प्रमुख पुनर्लेखन के बिना, दूसरे शब्दों में, अभी भी मोज़ेक कोड पर आधारित है)। ठीक है, वास्तव में नेटस्केप ने फिर से लिखा था, लेकिन इसे मोज़िला फाउंडेशन को आउटसोर्स कर दिया, जिससे फ़ायरफ़ॉक्स का विकास हुआ। इसलिए पुनर्लेखन ने उत्पाद को "मार" दिया क्योंकि इसने नए को जन्म दिया। क्या आपको लगता है कि पुराने कोड के आधार पर नेटस्केप ब्राउज़र आज भी मौजूद हो सकता है? मोजिला ने असहमति जताई।
जोड़ा लेखक Holger, स्रोत
@JohnWu अनुकूलन का वर्णन करने का अपना तरीका अलग-अलग लक्ष्यों का एक फ़ंक्शन बहुत अच्छा है, मुझे इस पर कोई आपत्ति नहीं है। यह एक बहुत अच्छा जवाब है।
जोड़ा लेखक Holger, स्रोत
@ R.Schmitz, सिवाय इसके कि फ़ायरफ़ॉक्स के मुख्य प्रायोजक ने एक बार क्रोम नाम का अपना ब्राउज़र लिखने का फैसला किया, जो फ़ायरफ़ॉक्स पर आधारित नहीं है, आप सही हैं। फ़ायरफ़ॉक्स प्राचीन है। हालाँकि, आप क्या साबित करना चाहते हैं? मेरा प्रारंभिक कथन था कि आज, कोई भी ब्राउज़र मोज़ेक पर आधारित नहीं है, क्योंकि सभी मौजूदा ब्राउज़र तब से पूरी तरह से फिर से लिखे गए हैं, या उससे बहुत छोटे हैं। यह देखते हुए कि मोज़ेक 1993 से है, Firexfox उससे बहुत छोटा है। इसलिए आपने मुझे गलत साबित नहीं किया। इसके अलावा, मैं रखरखाव योग्य कोड के खिलाफ नहीं हूं, ऐसा कभी नहीं कहा। बल्कि, मैं उस कोड के खिलाफ हूं जो केवल बढ़ रहा है जानता है।
जोड़ा लेखक Holger, स्रोत
@ R.Schmitz आप उस वाक्यांश को संदर्भ से बाहर निकाल रहे हैं। वाक्य " but एक बार बनाया गया था, लेकिन कई बार संशोधित किया गया, कई बार ' हो सकता है क्योंकि सॉफ्टवेयर एक तरह से डिज़ाइन किया गया है जो भयानक रूप से महंगा बनाता है ... "। यह एक पैटर्न के बारे में अटकलें है जो सॉफ़्टवेयर परियोजनाओं के कुछ मात्रा पर लागू होती है। आप पहले से ही इस बिंदु से चूक गए, चेरी से चुने गए सॉफ़्टवेयर के बारे में एक चर्चा को खोलकर, दो उदाहरण IIRC, जो बहुत लंबे समय तक बनाए रखा गया है, सभी अरबों सॉफ़्टवेयरों की अनदेखी करते हुए किया मर जाते हैं। यह अटकलबाजी कथन केवल दो उदाहरणों द्वारा "गलत साबित" नहीं है।
जोड़ा लेखक Holger, स्रोत
शानदार उत्तर लेकिन ..: रखरखाव के लिए अनुकूलन करने का विकल्प है इसका मतलब है कि यह केवल एक है और एक ओपी के बारे में शिकायत कर रहा है। सभी तरीकों से और हर कीमत पर डिज़ाइन पैटर्न खोजने के लिए अनुकूलन भी है। कीवर्ड स्मार्ट है और केवल बहुत सारी कक्षाएं बनाकर यह एक दिया नहीं है। DI एक महान/भयानक उदाहरण है, जहां, जैसा कि एक बुद्धिमान व्यक्ति ने लिखा है, आपको 100 $ buzzwords के लिए 50c अवधारणा मिलती है।
जोड़ा लेखक pong, स्रोत
एक अच्छा जवाब है, लेकिन एक भयावह चूक के साथ: यह अत्यधिक संभावना है कि "गड़बड़ कोड की 600 लाइनें" ठीक से परीक्षण नहीं की जा सकती हैं, और अकेले ओपी में वकालत की गई दृष्टिकोण के लिए एक सौदा ब्रेकर है।
जोड़ा लेखक Nath, स्रोत

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

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

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

DDD

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

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

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

कक्षाएं

कक्षाएं help with maintainability, readability, discoverability, etc... because they are a well known convention.

In Object Oriented settings, कक्षाएं are typically used to group closely related behaviour and to encapsulate state that needs to be controlled carefully.

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

With कक्षाएं, you don't necessarily need to know how the code in them works. You just need to know what the class is responsible for.

कक्षाएं allow you to reason about your application in terms of interactions between well defined components.

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

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

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

सारांश

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

They are breaking down the application into easy to reason about कक्षाएं.

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

They are doing this because they know that, as the application grows, it becomes harder and harder to reason about it as a whole. Breaking it down into Layers and कक्षाएं means that they never have to reason about the entire application. They only ever need to reason about a small subset of it.

64
जोड़ा
इसके अलावा छोटी कक्षाओं को बदलना/रिफ्लेक्टर करना आसान होता है।
जोड़ा लेखक Pieter, स्रोत
"कक्षाओं के साथ, आपको यह जानने की आवश्यकता नहीं है कि उनमें कोड कैसे काम करता है। आपको बस यह जानने की आवश्यकता है कि वर्ग किसके लिए जिम्मेदार है।" कक्षाएं निश्चित रूप से इसे प्राप्त करने का एकमात्र तरीका नहीं हैं, हालांकि वे कुछ परिस्थितियों में एक उपयोगी तरीका हो सकते हैं। अधिक महत्वपूर्ण बात, हालांकि, यह उन कक्षाओं का उपयोग नहीं कर रहा है जो इसे प्राप्त करता है, यह अच्छा डिज़ाइन विकल्प एक डेवलपर द्वारा करता है। कक्षाएं एक जादू की चटनी नहीं हैं जो आपको यह देती हैं, किसी भी खिंचाव से।
जोड़ा लेखक jmibanez, स्रोत
ओपी के अनुसार, जो "उनकी सोच को समझने के साथ बहुत संघर्ष कर रहा है, तर्क दे रहा है" ऐसा लगता है कि कोड बनाने के पीछे तर्क यह है कि इसके बारे में तर्क करना आसान नहीं है।
जोड़ा लेखक Erb, स्रोत
हाँ, अतिशय खराब है। इसलिए पिल्लों को मार रहा है। यहां कोई भी वकालत नहीं कर रहा है। तार्किक रूप से http://www.tools/lp/Bo/LogicalFallacies/169/ & hellip;
जोड़ा लेखक Warpspace, स्रोत
इसके अलावा, सॉफ्टवेयर इंजीनियरिंग संदर्भ में "लालित्य" अक्सर एक वैसल वर्ड है। en.wikipedia.org/wiki/Weasel_word
जोड़ा लेखक Warpspace, स्रोत
कोड को व्यवस्थित करने के लिए किसी भी दृष्टिकोण के बारे में कहा जा सकता है। सब कुछ रखरखाव टीम को समझने पर टिका है कि कोड को क्यों आयोजित किया गया है। यह अच्छी तरह से स्थापित और समझे गए सम्मेलनों का उपयोग करने का पूरा बिंदु है।
जोड़ा लेखक Warpspace, स्रोत
@ jpmc26 मैं सहमत हूं, कक्षाएं जादू नहीं हैं। हालांकि, वे अक्सर एनकैप्सुलेशन और सार्वजनिक अनुबंध जैसी चीजों के लिए भाषा-स्तर का समर्थन प्रदान करते हैं।
जोड़ा लेखक Warpspace, स्रोत
@ icc97 ऐसा लगता है जैसे आप अनुभव, संदर्भ और सम्मेलनों और पैटर्न के ज्ञान से कह रहे हैं कि इससे बहुत फर्क पड़ता है। और यह कि एक कनिष्ठ देव के पास इन चीजों की कमी हो सकती है, जिससे उनके लिए उन चीजों को ध्यान में रखते हुए कोड लिखना मुश्किल हो जाएगा।
जोड़ा लेखक Warpspace, स्रोत
ओवरइंजीनियरिंग करता है नहीं जो आप दावा करते हैं उसके बावजूद अधिक अनुरक्षणीय या समझने योग्य कोड दें - काफी विपरीत। जब आपको समस्या को और अधिक सुरुचिपूर्ण ढंग से हल किया जा सकता है, तो AddressServiceRepositoryProxyInjectorResolver की आवश्यकता किसे है? डिजाइन पैटर्न के लिए डिजाइन पैटर्न सिर्फ आवश्यक जटिलता और क्रियाशीलता की ओर जाता है।
जोड़ा लेखक Ian Yates, स्रोत
बहुत बढ़िया जवाब! मैं आपसे असहमत टिप्पणियों पर आश्चर्यचकित हूं
जोड़ा लेखक reggaeguitar, स्रोत
यदि वे पहले इसे कक्षाओं में तोड़ रहे हैं और तो उन कक्षाओं को परतों में जोड़ रहे हैं, तो कोई आश्चर्य नहीं कि चीजें गड़बड़ हो जाती हैं। आप इसे दूसरे तरीके से करना चाहते हैं (इसके अलावा, आप शुरू करने के लिए कक्षाएं शुरू करना चाहते हैं)।
जोड़ा लेखक Clearer, स्रोत
और फिर पूरे पैटर्न को तोड़ने के लिए केवल एक बंदर रिंच लेता है
जोड़ा लेखक user2890248, स्रोत

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

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

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

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

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

Additionally, you see a bit more attention paid to separation of concerns; and the notion of insulating consumers of some capability from the implementation details. See D. L. Parnas. The clear boundaries empower you to change or extend the implementation without the effects rippling throughout you entire solution.

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

निष्पक्षता में: इसमें से कुछ ऑब्जेक्ट ओरिएंटेड ब्रेन डैमेज भी है। मूल रूप से इवांस द्वारा वर्णित पैटर्न जावा परियोजनाओं पर आधारित हैं जो उन्होंने 15+ साल पहले भाग लिया था; राज्य और व्यवहार को उस शैली में कसकर युग्मित किया जाता है, जिससे जटिलताओं से आप बच सकते हैं; स्टुअर्ट हल्लोवे द्वारा धारणा और कार्य देखें जॉन कार्मैक द्वारा href = "http://number-none.com/blow/john_carmack_on_inbuild_code.html" rel = "noreferrer"> इनलाइनिंग कोड ।

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

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

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

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

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

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

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

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

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

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

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

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

However, there is another aspect to consider - testing can only be fine-grained as your original code.

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

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

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

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

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

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

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

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

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

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

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

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

17
जोड़ा
क्या आप कह रहे हैं कि आपके 20 वर्षों के अनुभव में, कभी भी एक ही समाधान किसी समस्या के भाग के लिए प्रस्तुत नहीं हुआ है? आपने हमेशा दो वर्गों को एक-दूसरे के साथ बातचीत करते हुए हर बार एक पूरी तरह से नया समाधान बनाया है? बहुत अच्छी तरह से हर कोई पैटर्न का बार-बार उपयोग करता है, किताबें केवल वहां होती हैं इसलिए हम उन्हें उसी तरह नाम देते हैं जब हम उनके बारे में बात करते हैं।
जोड़ा लेखक Rob Hunter, स्रोत
जबकि शुद्ध स्तर पर यह सही है, ऐसा लगता है जैसे DDD और अन्य पैटर्न सिर्फ सिद्धांत हैं। वे नहीं कर रहे हैं वे पठनीय और प्राप्य कोड प्राप्त करने के लिए महत्वपूर्ण उपकरण हैं।
जोड़ा लेखक Moogie, स्रोत
@vikingsteve ओपी एक प्रोग्रामिंग गुरु नहीं है जो डिजाइन पैटर्न के सामान्य अति प्रयोग पर टिप्पणी करता है। ओपी एक प्रशिक्षु है और सोचता है कि उनकी दुकान पर का अत्यधिक उपयोग किया जाता है । मुझे पता है कि शुरुआत-मेरे द्वारा आजकल लिखे गए कोड के बारे में मैंने ऐसा ही सोचा होगा, लेकिन शुरुआत-मेरे पास बहुत सारी व्यक्तिगत परियोजनाएं विफल थीं, क्योंकि वे बहुत जटिल थे।
जोड़ा लेखक R. Schmitz, स्रोत
@ वेक्टर मैं थोड़ा बहुत चकित हूं कि वे संपादन कितने अच्छे थे। यह मेरे लिए निश्चित रूप से +1 के लिए "100% सहमत" के लिए "लगता है" से गया था!
जोड़ा लेखक R. Schmitz, स्रोत
@ Luaan यदि आप पहले से ही अच्छी तरह से डिजाइन, संगठित, संरचित, OOP के बारे में परवाह करते हैं, तो मैं शायद ही उस शुरुआती-आपको कॉल करूँगा, लेकिन हाँ अति प्रयोग बुरा है। हालांकि, यह सवाल अधिक है कि ओपी वास्तव में कैसे समझ नहीं पाता है कि कौन सी समस्याएं हल करती हैं। यदि आप कारण नहीं जानते हैं, तो ऐसा लगता है कि कोई कारण नहीं है - लेकिन वास्तव में, आप अभी तक इसे नहीं जानते हैं।
जोड़ा लेखक R. Schmitz, स्रोत
@JensSchauder - मैंने आपकी टिप्पणी के प्रकाश में उत्तर संपादित किया है। मैं सहमत हूं कि इसे केवल "सिद्धांत" कहना आमतौर पर गलत है। "कार्यप्रणाली" अधिक उपयुक्त है।
जोड़ा लेखक Vector, स्रोत
@ R.Schmitz - मैंने टिप्पणियों को पढ़ा और महसूस किया कि मेरी भाषा वास्तव में सटीक नहीं थी और मेरी स्थिति थोड़ी चरम पर थी।
जोड़ा लेखक Vector, स्रोत
@PeteKirkham ओपी दुविधा डिजाइन पैटर्न के अति प्रयोग है। क्या आपको वास्तव में एक AccountServiceFacadeInjectResolver (वास्तविक उदाहरण जो मुझे अभी काम में सिस्टम में मिला है) की आवश्यकता है - उत्तर शायद सबसे अधिक नहीं है।
जोड़ा लेखक Ian Yates, स्रोत
@ R.Schmitz ने कहा कि, शुरुआत में मेरे पास बहुत सारी व्यक्तिगत परियोजनाएं विफल थीं क्योंकि उन्होंने चीजों को अच्छी तरह से डिजाइन, संगठित, संरचित, OOP बनाने के लिए बहुत प्रयास किया ... ये सभी उपकरण हैं। उन्हें ठीक से समझने और उपयोग करने की आवश्यकता है, और आप खराब होने के लिए हथौड़ा को मुश्किल से दोष दे सकते हैं। हैरानी की बात यह है कि इस साधारण सी बात को समझने में काफी अंतर्दृष्टि और अनुभव लगता है :)
जोड़ा लेखक Luaan, स्रोत
मेरे अनुभव में अजीब बात यह है कि मुझे AccountServiceFacadeInjectResololver टाइप की चीजें अक्सर कोड में मिलती हैं जो DDD का उपयोग नहीं करती हैं। स्प्रिंग-आधारित एप्लिकेशन लगभग पूरी तरह से ऐसी कक्षाएं लगती हैं जिनका समस्या क्षेत्र की तुलना में फ्रेमवर्क में भरना अधिक है।
जोड़ा लेखक Rob Crawford, स्रोत

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

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

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

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

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

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

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

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

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

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

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

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

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

8
जोड़ा

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

  • क्योंकि उन छोटे कार्यक्रमों और clasess बढ़ने लगते हैं, विशेष रूप से सफल। साधारण स्तर पर काम करने वाले यह सरल पैटर्न पैमाने नहीं हैं।
  • क्योंकि हर ऐड/चेंज के लिए कई कलाकृतियों को जोड़ना/बदलना भारी पड़ सकता है, लेकिन आप जानते हैं कि क्या जोड़ना है और ऐसा करना आसान है। 3 मिनट की टाइपिंग में 3 घंटे की चतुर कोडिंग होती है।
  • बहुत सी छोटी कक्षाएं "गड़बड़" नहीं हैं, क्योंकि आप यह नहीं समझती हैं कि ओवरहेड वास्तव में एक अच्छा विचार क्यों है
  • बिना डोमेन ज्ञान जोड़े, 'मेरे लिए स्पष्ट' कोड अक्सर मेरी टीम के साथियों के लिए रहस्यमय होता है ... साथ ही भविष्य का मुझे।
  • जनजातीय ज्ञान परियोजनाओं को अविश्वसनीय रूप से कठिन बना सकता है ताकि टीम के सदस्यों को आसानी से और कड़ी मेहनत से जोड़ा जा सके कि वे जल्दी से उत्पादक बन सकें।
  • कंप्यूटिंग में दो कठिन समस्याओं में से एक नामकरण अभी भी सही है और बहुत सारी कक्षाएं और विधियाँ अक्सर नामकरण में एक गहन अभ्यास है, जो कई लोगों को बहुत अच्छा लगता है।
7
जोड़ा
@vikingsteve आप एक त्रुटिपूर्ण क्रियान्वयन के एकल उदाहरण का उल्लेख करते हुए उम्मीद करते हैं कि यह साबित होगा कि संरचित कोड, सामान्य रूप से, एक बुरा विचार है। वह सिर्फ ट्रैक नहीं करता है।
जोड़ा लेखक Warpspace, स्रोत
@ क्लेयर मुझे पूरा यकीन है कि यहां हर कोई समझौते में है कि संरचित कोड का काल्पनिक गलत उपयोग एक बुरी बात है। ओपी का कहना है कि वे जूनियर हैं। इसलिए लोग मान रहे हैं कि वह संरचित कोड के लाभों से अपरिचित है और उन्हें दोहरा रहा है।
जोड़ा लेखक Warpspace, स्रोत
लेकिन क्या ओवरहेड आवश्यक है? कई मामलों में जो मैं देखता हूं, डिजाइन पैटर्न का उपयोग किया जाता है। Overcomplexity के परिणाम को समझने, बनाए रखने, परीक्षण करने और डिबगिंग कोड में कठिनाई बढ़ जाती है। जब आपके पास एक साधारण सेवा वर्ग (मैंने अभी देखा एक वास्तविक उदाहरण) के आसपास 12 कक्षाएं और 4 मावेन मॉड्यूल हैं, तो यह जल्दी से आपके विचार से कम प्रबंधनीय हो जाता है।
जोड़ा लेखक Ian Yates, स्रोत
@MetaFight OP संरचना कोड के बारे में बात नहीं कर रहा है। वह उस बारे में बात कर रहा है, जो वह देखता है, बहुत सारे अमूर्त। यदि आपके पास बहुत अधिक सार हैं, तो मैं तर्क देता हूं, आप जल्दी से बहुत ही असंरचित कोड और बहुत सारे समान टुकड़े प्राप्त करते हैं, बस इसलिए कि लोग उन सामानों का सामना नहीं कर सकते जिनसे उन्हें निपटना है।
जोड़ा लेखक Clearer, स्रोत

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

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

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

4
जोड़ा
क्षमा करें, लेकिन आप क्या कह रहे हैं?
जोड़ा लेखक Shizam, स्रोत
इस उत्तर को इस विचार को प्रस्तुत करने की आवश्यकता है कि यह स्पष्ट अंग्रेजी में प्रस्तुत करना है। ऐसा लगता है कि उत्तर में मुख्य विचार यह है कि छोटे वर्ग, प्रत्येक एक अच्छी तरह से परिभाषित कार्यक्षमता के साथ, एक अच्छा विचार है, लेकिन भयानक व्याकरण इसे समझना लगभग असंभव बना देता है। इसके अलावा, अपने आप से, यह दावा पर्याप्त नहीं हो सकता है।
जोड़ा लेखक Stefan Kendall, स्रोत
@Deduplicator चलो जावा में एक उदाहरण लेते हैं यदि हम डिजाइन करते हैं कि हमने उनके उत्तराधिकार के लिए जेफर्स थ्रेड और कक्षाएं इस्तेमाल की हैं। केवल एक वर्ग से हम डिजाइन के लिए जावा के कुछ कार्यों का उपयोग करने में सक्षम नहीं हो सकते हैं, इसलिए हमें अधिक कक्षाएं बनाने की आवश्यकता है
जोड़ा लेखक David Farrell, स्रोत

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

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

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

2
जोड़ा