"असली दुनिया" में एकल उत्तरदायित्व सिद्धांत का उपयोग

Question

मैं मूल रूप से उन लोगों के प्रतिशत का विचार प्राप्त करना चाहता हूं जो सोचते हैं कि असली दुनिया कोड और में एकल उत्तरदायित्व सिद्धांत का उपयोग करना उचित है, वास्तव में कितने लोग करते हैं। Podcast #38 में जोएल इस ओओपी सिद्धांत को असली दुनिया के बेकार के बारे में बताता है; और आगे यह दर्शाता है कि अंकल बॉब जैसे लोगों ने गैर-तुच्छ प्रणाली क्यों नहीं लिखी है।

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

समुदाय क्या सोचता है?

Answer 1

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

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

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

Answer 2

मैंने जोएल की टिप्पणियों को पढ़ या सुना नहीं है, इसलिए विशेष रूप से उन पर टिप्पणी नहीं कर सकते हैं।

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

Answer 3

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

यही कारण है कि एओपी की कल्पना की गई थी। इसका उपयोग करके लॉगिंग कक्षाओं को लॉगिंग बदलने के लिए आपको कुछ भी बदलने की ज़रूरत नहीं है।

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

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

Answer 4

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

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

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

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

Answer 5

मैं एक ऐसी परियोजना पर काम कर रहा हूं जो कई अलग-अलग, जटिल जटिल चीजें करता है, जो ढांचे में दूसरों द्वारा आसानी से एक्स्टेंसिबल माना जाता है।

पहले, कक्षाएं बड़ी थीं और कई चीजें होती थीं। उन व्यवहारों को बदलने के लिए, आपको उन वर्गों का विस्तार करना पड़ा। विधियां सभी वर्चुअल थीं और ऑब्जेक्ट की स्थिति को नहीं बदला, इसलिए ऐसा करना बहुत आसान था।

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

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

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

Answer 6

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

कक्षाओं के पास जीयूआई जीयूआई को प्रतिबिंबित करता है और "XXXX के लिए गुई होने" की एकमात्र ज़िम्मेदारी है। कॉवर्ड का समाधान ..

Answer 7

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

Answer 8

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

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

पॉल।

Answer 9

मुझे लगता है कि कभी-कभी सोलिड सिद्धांत प्राकृतिक/व्यावसायिक तर्क का पालन नहीं करते हैं जो आमतौर पर कक्षाओं को डिजाइन करते समय लागू होता है। रॉबर्ट सी मार्टिन ने रेक्टेंज और स्क्वायर कक्षाओं का एक उदाहरण लाया (स्क्वायर आयत के वंशज नहीं होना चाहिए)।

http://www.hanselminutes.com/default.aspx?showID=163

मुझे यकीन है कि यह SRP के बारे में किया गया था नहीं कर रहा हूँ लेकिन यह विचार एक ही है। सोलिड सिद्धांतों से प्रतिकूल निर्णय हो सकते हैं और इस बाधा को प्राप्त करना मुश्किल है।

मेरे लिए 'दिशानिर्देश' 'सिद्धांतों' से अधिक उचित नाम है।