ठोस सिद्धांत बनाम YAGNI

Question

ठोस सिद्धांत YAGNI कब बनते हैं?

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

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

टिप्पणियों में पूछा गया:

• ठोस सिद्धांत
• YAGNI

Comments

शीर्षक भी नहीं होना चाहिए SOLID principle vs YAGNI?

— वुल्फ

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

— 13

Answer 1

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

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

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

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

Comments

यह बहुत ज्यादा है जो मुझे भी लगता है। एक टिप्पणी के रूप में मैं स्क्रैंकास्ट द्वारा न्याय नहीं करता, मुझे लगता है कि यह एक अच्छा उदाहरण है कि कैसे SOLID को लागू करते समय सॉफ्टवेयर बढ़ सकता है।

— 15

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

— बेरिन लोरिट्स

YAGNI and SOLID coexistअच्छा निष्कर्ष। हालाँकि यह एक अच्छा शुरुआती बिंदु हो सकता है

— वुल्फ

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

— जॉनी

Answer 2

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

इसके बजाय, उन सिद्धांतों और समस्याओं को समझना बेहतर है जिन्हें SOLID संबोधित करने का प्रयास कर रहा है; साथ ही उन सिद्धांतों और समस्याओं के बारे में जिन्हें YAGNI संबोधित करने का प्रयास कर रहा है। आप पाएंगे कि एक आपके आवेदन की वास्तुकला से संबंधित है और दूसरा समग्र रूप से विकास प्रक्रिया से संबंधित है। जबकि कुछ मामलों में ओवरलैप हो सकता है, वे अलग-अलग समस्याएं हैं।

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

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

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

Comments

हां, सहमत हैं .. कोई सिल्वर-बुलेट दृष्टिकोण नहीं है जो हर परिदृश्य पर फिट बैठता है।

— एल युसुबोव

आपका make sure the pieces of the bridge fit togetherअब तक उतना स्पष्ट नहीं है can be maintained over time।

— वुल्फ

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

— सारा

@kai, यह एक गलत आधार है। यदि आपको एक पुल की आवश्यकता है जो 1 मील तक फैला है, तो आप एक पुल का निर्माण करते हैं जो 1 मील तक फैला है। यदि आपको एक पुल की आवश्यकता है जो 5 फीट तक फैला हो, तो आप एक ऐसे पुल का निर्माण करें जो 5 फीट तक फैला हो। मुझे गलत मत समझिए, SOLID सिद्धांत बहुत मददगार हैं, लेकिन यह जानने के लिए उनमें से अधिक समझ में आता है कि समस्या के लिए कौन से सिद्धांत आवश्यक नहीं हैं। 10 में से 9 बार, अतिरिक्त मील की आवश्यकता कभी नहीं होती है।

— बेरिन लोरिट्श

@BerinLoritsch जिसके कारण मैं मानता हूं कि अगर आपको 5 फीट की आवश्यकता है, तो आप 5 फीट का निर्माण करते हैं, लेकिन आप 5 फीट के एक जोड़े को जमीन पर उतारकर 5 फीट का निर्माण नहीं करते हैं। आप वह करते हैं जो आपको चाहिए, और आप इसे अच्छी तरह से करते हैं। (यद्यपि सादृश्य गिरने का एक प्रकार है)

— सारा

Answer 3

जब एक थ्रो-दूर अनुप्रयोग होता है तो ठोस सिद्धांतों की आवश्यकता नहीं होती है; अन्यथा उन्हें हमेशा जरूरत होती है।

ठोस और YAGNI बाधाओं पर नहीं हैं: अच्छा वर्ग डिजाइन आवेदन को बनाए रखना आसान बनाता है। YAGNI में कहा गया है कि आपको अपने एप्लिकेशन के लिए इस विन्यास योग्य राक्षसी होने की क्षमता को नहीं जोड़ना चाहिए जो सूर्य के नीचे सब कुछ कर सकता है - जब तक कि वास्तव में इसकी आवश्यकता न हो।

यह एक कार वर्ग के बीच अंतर है जिसने अच्छी तरह से परिभाषित सीमाएं (एसओएलआईडी) और एक कार वर्ग है जो ग्राहक के पूछने से पहले स्वयं-चंगा करने की क्षमता (YAGNI) है।

Comments

क्या यह मिश्रित नहीं है? इसके बारे में क्या: सेल्फ-हीलिंग कारों की जटिलता को संभालने के लिए SOLID सिद्धांतों को उचित रूप से लागू करें, या YAGNI को तब तक लागू करें जब तक कि आपकी कारें अभी भी इतनी सरल हैं कि वे कभी नहीं टूटेंगी (या - वैकल्पिक रूप से - इतनी चीप कि वे बस फेंक दी जा सकती हैं) ।

— वुल्फ

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

— सारा

अक्सर बार फेंक-दूर अनुप्रयोगों नहीं हैं।

— ट्यूलेंस कोरडोवा

"सेल्फ हील" अच्छा है। "इससे पहले कि ग्राहक इसे मांगे," यह भी अच्छा है क्योंकि मुझे लगता है कि पूरा विचार, यदि आप अंकल बॉब को सुनते हैं, तो ऐसी जगहों के लिए जो लाभ कमाते हैं और ग्राहक की जरूरतों का अनुमान लगाते हैं और एक व्यवहार्य व्यवसाय रखते हैं जो जरूरतों का जवाब दे सके क्योंकि वे बदल जाते हैं। बहुत से लोग अंकल बॉब पर गुस्सा हो जाते हैं क्योंकि वह प्रोग्रामिंग के लिए सही नहीं है, लेकिन वह आपको बता रहा है, ज्यादातर समय, यह सिर्फ इसलिए नहीं, बल्कि SOLID का उपयोग करने के लिए क्यों मायने रखता है।

— जॉनी

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

— icc97

Answer 4

हमेशा कुछ नहीं लागू होता है! वास्तुकला अंतरिक्ष यात्रियों को डराने मत दो ! महत्वपूर्ण बात यह है कि इन सिद्धांतों को संबोधित करने की कोशिश कर रहे हैं और इन समस्याओं को समझने की कोशिश करें ताकि आप उन्हें लागू करने के बारे में सूचित निर्णय कर सकें।

हाल ही में मैं यह समझने की कोशिश कर रहा था कि मुझे सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल ( यहाँ मैं क्या लेकर आया था) का उपयोग करना चाहिए ।

उम्मीद है की यह मदद करेगा!

Answer 5

आइंस्टीन के लिए जिम्मेदार एक उद्धरण है (शायद एक वास्तविक पर एक बदलाव ):

"सब कुछ जितना संभव हो उतना सरल बनाया जाना चाहिए, लेकिन कोई सरल नहीं है।"

और यह कम या ज्यादा मैं दृष्टिकोण है जब मैं SOLID बनाम YAGNI ट्रेडऑफ़ के साथ सामना करता हूं: उन्हें वैकल्पिक रूप से लागू करें, क्योंकि आप कभी नहीं जानते कि कोई प्रोग्राम 'थ्रो-दूर' कोड है या नहीं। तो, बस गंदगी की एक परत जोड़ें जो काम करता है, फिर इसे एक क्लीनर इंटरफ़ेस में पॉलिश करें ... और तब तक दोहराएं जब तक आप एंट्रोपी के सही स्तर तक नहीं पहुंच जाते। उम्मीद है कि।

Comments

अच्छी बात: you never know if a program is 'throw-away' code- ठीक है, मुझे लगता है कि वैकल्पिक विचार उतना अच्छा नहीं है।

— वुल्फ

@ वोल्फ: हाँ, मुझे लगता है कि मैं सबसे अच्छा है चरणों के क्रम पर विस्तार कर रहा था (संक्षेप में 'पहले इसे संभव बनाएं, फिर इसे सुंदर बनाएं, फिर इसे तेजी से' नारा 'बनाएं), लेकिन फिर मैंने सोचा ... YAGNI :)

— log

Answer 6

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

YAGNI और KISS सुविधा क्षेत्र के साथ संबंध है। एक प्रोग्राम जो अधिक प्रकार की समस्याओं को हल करता है वह अधिक जटिल और सार है। यदि आपको उस सामान्यता की आवश्यकता नहीं है, तो आपने कोड और कोड बनाने में समय बिताया है जो समझना और बनाए रखना कठिन है, लेकिन कोई अतिरिक्त मूल्य प्रदान नहीं करता है।

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

Answer 7

मुझे लगता है कि आपको YAGNI शुरू करना चाहिए और जब भी आवश्यकता हो, इसे SOLIDify करें।

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

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

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

Comments

हम्म, मैं आपकी बात को निरर्थक होने के बारे में देखता हूं, मैं इसे हटा दूंगा लेकिन ऐसा लगता है कि मेरे पास ऐसा करने के लिए विशेषाधिकार नहीं हैं (या मैं बटन नहीं देख रहा हूं)। किसी भी तरह मैं इसे स्पष्ट करने के लिए संपादित करूँगा।

— बिन्यामीन