सुनिश्चित करें कि प्रत्येक वर्ग की एक ही जिम्मेदारी है, क्यों?

37

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

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

— बास्तियन वंदामे
स्रोत

2

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

— gnat

1

मेरा एक सवाल था जो आपको संबंधित भी मिल सकता है: एक वर्ग की वास्तविक जिम्मेदारी क्या है?

— पियरे अरलाउड

3

क्या एकल जिम्मेदारी के सभी कारण सही नहीं हो सकते? यह रखरखाव को आसान बनाता है। यह परीक्षण को आसान बनाता है। यह वर्ग को और अधिक मजबूत बनाता है (सामान्य रूप में)।

— मार्टिन यॉर्क

2

उसी कारण से आपके पास AT ALL है।

— Aprdralo

2

मेरा हमेशा इस कथन के साथ एक मुद्दा रहा है। यह परिभाषित करना बहुत मुश्किल है कि "एकल जिम्मेदारी" क्या है। एक एकल ज़िम्मेदारी किसी भी सीमा तक हो सकती है जहां "सत्यापित करें कि 1 + 1 = 2" से "कॉर्पोरेट बैंकिंग खातों में और उसके बाहर भुगतान किए गए सभी पैसे का एक सटीक लॉग बनाए रखें"।

— डेव नै

57

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

SRP फ़ंक्शंस के समान ही लागू होता है क्योंकि यह कक्षाओं के लिए होता है, लेकिन मुख्यधारा की OOP भाषाएँ एक साथ ग्लूइंग फ़ंक्शंस में अपेक्षाकृत खराब होती हैं।

— डोभाल
स्रोत

12

अमूर्त रचना करने के लिए एक सुरक्षित तरीके के रूप में कार्यात्मक प्रोग्रामिंग का उल्लेख करने के लिए +1।

— लॉग

> लेकिन मुख्यधारा ओओपी भाषाएँ एक साथ ग्लूइंग फ़ंक्शन में अपेक्षाकृत खराब हैं। <क्योंकि ओओपी भाषा फ़ंक्शंस से संबंधित नहीं हैं, लेकिन संदेश।

— जेफ हबर्ड

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

— डोभाल

@ डोवाल नहीं, मेरा वास्तव में मतलब है कि OOP संदेशों से चिंतित है। यह कहना नहीं है कि एक दी गई भाषा एक साथ प्रोग्रामिंग कार्यों में एक कार्यात्मक प्रोग्रामिंग भाषा से बेहतर या बदतर है - बस यह कि यह भाषा की प्राथमिक चिंता नहीं है ।

— जेफ हब्बार्ड

मूल रूप से, यदि आपकी भाषा OOP को आसान / बेहतर / तेज / मजबूत बनाने के बारे में है, तो चाहे आप एक साथ गोंद का कार्य करें या न करें, जिस पर आप ध्यान केंद्रित नहीं करते हैं।

— जेफ हब्बार्ड

30

बेहतर रखरखाव, आसान परीक्षण, तेज बग फिक्सिंग SRP लगाने के सिर्फ (बहुत सुखद) परिणाम हैं। मुख्य कारण (जैसा कि रॉबर्ट सी। माटिन इसे कहते हैं) है:

एक वर्ग में एक होना चाहिए, और केवल एक, बदलने का कारण।

दूसरे शब्दों में, SRP स्थानीयता को बदल देती है ।

SRP DRY कोड को भी बढ़ावा देता है। जब तक हमारे पास कक्षाएं हैं जिनकी केवल एक ही जिम्मेदारी है, तो हम उन्हें कहीं भी उपयोग करना चुन सकते हैं। यदि हमारे पास एक वर्ग है जिसमें दो जिम्मेदारियां हैं, लेकिन हमें उनमें से केवल एक की आवश्यकता है और दूसरा हस्तक्षेप कर रहा है, हमारे पास 2 विकल्प हैं:

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

— मैकीज चोलापुक
स्रोत

1

+1 SRP को DRY से जोड़ने के लिए।

— महदी

21

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

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

जैसा कि उनका मतलब है:

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

सिद्धांत का पालन करते हुए कुछ समय के लिए कोड बनाने का प्रयास करें, और बाद में कुछ बदलाव करने के लिए उस कोड को दोबारा बनाएं। आप इसे प्रदान करने वाले बड़े पैमाने पर लाभ देखेंगे।

आप प्रत्येक वर्ग के लिए ऐसा ही करते हैं, और अधिक कक्षाओं के साथ अंत करते हैं, सभी एसआरपी का अनुपालन करते हैं। यह संरचना को कनेक्शन के दृष्टिकोण से अधिक जटिल बनाता है, लेकिन प्रत्येक वर्ग की सादगी इसे सही ठहराती है।

— मियामोतो अकीरा
स्रोत

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

2

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

— मियामोतो अकीरा

मुझे लगता है कि आपको अपने उत्तर में इसे जोड़ना चाहिए।

4

यहाँ तर्क हैं कि, मेरे विचार में, इस दावे का समर्थन करते हैं कि एकल-जिम्मेदारी सिद्धांत एक अच्छा अभ्यास है। मैं आगे के साहित्य के लिंक भी प्रदान करता हूं, जहां आप और भी विस्तृत तर्क पढ़ सकते हैं - और मेरी तुलना में अधिक स्पष्ट:

बेहतर रखरखाव : आदर्श रूप से, जब भी सिस्टम की कार्यक्षमता को बदलना होगा, तो एक और केवल एक वर्ग होगा जिसे बदलना होगा। कक्षाओं और जिम्मेदारियों के बीच एक स्पष्ट मानचित्रण का मतलब है कि परियोजना में शामिल कोई भी डेवलपर यह पहचान सकता है कि यह किस वर्ग का है। (जैसा कि @ MaciejChałapuk ने नोट किया है, रॉबर्ट सी। मार्टिन, "क्लीन कोड" देखें )
आसान परीक्षण : आदर्श रूप में, वर्गों में यथासंभव कम से कम एक सार्वजनिक इंटरफ़ेस होना चाहिए, और परीक्षणों को केवल इस सार्वजनिक इंटरफ़ेस को संबोधित करना चाहिए। यदि आप स्पष्टता के साथ परीक्षण नहीं कर सकते हैं, क्योंकि आपकी कक्षा के कई हिस्से निजी हैं, तो यह एक स्पष्ट संकेत है कि आपकी कक्षा में बहुत अधिक जिम्मेदारियां हैं, और आपको इसे छोटे उपवर्गों में विभाजित करना चाहिए। कृपया ध्यान दें कि यह उन भाषाओं पर भी लागू होता है जहां कोई 'सार्वजनिक' या 'निजी' वर्ग के सदस्य नहीं हैं; एक छोटा सार्वजनिक इंटरफ़ेस होने का मतलब है कि यह क्लाइंट कोड के लिए बहुत स्पष्ट है कि इसे किस वर्ग के किन हिस्सों में उपयोग करना है। ( अधिक जानकारी के लिए केंट बेक, "टेस्ट-ड्रिवेन डेवलपमेंट" देखें।)
मजबूत कोड : आपका कोड अधिक या कम बार विफल नहीं होगा क्योंकि यह अच्छी तरह से लिखा गया है; लेकिन, सभी कोड के रूप में, इसका अंतिम लक्ष्य मशीन के साथ संवाद करना नहीं है , लेकिन साथी डेवलपर्स के साथ ( केंट बेक, "कार्यान्वयन पैटर्न" , अध्याय 1 देखें) एक स्पष्ट कोडबेस के बारे में तर्क करना आसान है, इसलिए कम कीड़े पेश किए जाएंगे , और कम समय बग की खोज और इसे ठीक करने के बीच गुजर जाएगा।

— logc
स्रोत

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

— बैस्टियन वंदामे

@ B413: मेरा मतलब यह नहीं था कि कोई भी परिवर्तन एक एकल वर्ग के लिए एक ही परिवर्तन का अर्थ होगा। सिस्टम के कई हिस्सों को एकल व्यवसाय परिवर्तन के अनुपालन के लिए परिवर्तनों की आवश्यकता हो सकती है। लेकिन शायद आपके पास एक बिंदु है और मुझे "जब भी सिस्टम की कार्यक्षमता को बदलना होगा" लिखा जाना चाहिए।

— 21

3

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

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

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

कई चीजें करने से कोड जटिलता बढ़ जाती है। सबसे सरल कोड से परे, जटिलता बढ़ने से कीड़े की संभावना बढ़ जाती है। इस दृष्टिकोण से आप चाहते हैं कि कक्षाएं यथासंभव सरल हों।

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

— BillThor
स्रोत

2

क्योंकि सॉफ्टवेयर जैविक है। आवश्यकताएँ लगातार बदलती रहती हैं इसलिए आपको यथासंभव कम सिरदर्द वाले घटकों में हेरफेर करना पड़ता है। SOLID सिद्धांतों का पालन नहीं करने से, आप एक कोड आधार के साथ समाप्त हो सकते हैं जो कंक्रीट में सेट किया गया है।

लोडिंग कंक्रीट की दीवार के साथ एक घर की कल्पना करें। जब आप बिना किसी सहारे के इस दीवार को बाहर निकालते हैं तो क्या होता है? घर शायद ढह जाएगा। सॉफ़्टवेयर में हम ऐसा नहीं चाहते हैं, इसलिए हम एप्लिकेशन को इस तरह से संरचना करते हैं ताकि आप बहुत सारे नुकसान पहुंचाए बिना घटकों को आसानी से स्थानांतरित / बदल सकें।

— CodeART
स्रोत

1

मैं विचार का पालन करता हूं 1 Class = 1 Job:।

एक फिजियोलॉजी सादृश्य का उपयोग करना: मोटर (तंत्रिका तंत्र), श्वसन (फेफड़े), पाचन (पेट), ओफ़ेक्टिवल (अवलोकन), आदि इनमें से प्रत्येक में नियंत्रकों का एक सबसेट होगा, लेकिन वे प्रत्येक में केवल 1 ज़िम्मेदारी है, चाहे इसका प्रबंधन करना हो जिस तरह से उनके प्रत्येक सबसिस्टम काम करते हैं या क्या वे एक एंड-पॉइंट सबसिस्टम हैं और केवल 1 कार्य करते हैं, जैसे कि उंगली उठाना या बाल-कूप बढ़ना।

इस तथ्य को भ्रमित न करें कि यह एक कार्यकर्ता के बजाय एक प्रबंधक के रूप में कार्य कर सकता है। कुछ कार्यकर्ता अंततः प्रबंधक के रूप में पदोन्नत हो जाते हैं, जब वे जो काम कर रहे थे, वह एक प्रक्रिया के लिए खुद से निपटने के लिए बहुत जटिल हो गया है।

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

जब एक क्लास / ऑब्जेक्ट इन प्रकार की भूमिकाओं में से 1 से अधिक प्रदर्शन करता है, तो आप पाएंगे कि समग्र प्रक्रिया में प्रदर्शन के मुद्दे, या बोतल-गर्दन की प्रक्रिया शुरू होगी।

— GoldBishop
स्रोत

भले ही हीमोग्लोबिन में वायुमंडलीय ऑक्सीजन के प्रसंस्करण के कार्यान्वयन को एक Lungवर्ग के रूप में संभाला जाना चाहिए , मैं यह कहना चाहूंगा कि Personअभी भी इसका एक उदाहरण है Breathe, और इस प्रकार Personवर्ग में कम से कम, उस पद्धति से जुड़ी जिम्मेदारियों को सौंपने के लिए पर्याप्त तर्क होना चाहिए। मैं आगे सुझाव देना चाहता हूं कि परस्पर संबंधित संस्थाओं का एक जंगल, जो केवल एक आम मालिक के माध्यम से सुलभ हैं, अक्सर एक जंगल के बारे में तर्क करना आसान होता है जिसमें कई स्वतंत्र पहुंच बिंदु होते हैं।

— सुपरकैट

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

— गोल्डबिशप

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

— सुपरकाट

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

— गोल्डबिशप

@GoldBishop: काश "एक" अल्पकालिक "प्रकार की घोषणा करने के कुछ तरीके थे, जैसे कि बाहर का कोड इस पर सदस्यों को आमंत्रित कर सकता है या इसे टाइप करने के लिए अपने स्वयं के तरीकों के लिए एक पैरामीटर के रूप में पारित कर सकता है, लेकिन कुछ और नहीं। एक कोड संगठन के दृष्टिकोण से, उप-विभाजित कर कक्षाएं समझ में आता है, और यहां तक कि तरीकों एक स्तर नीचे (जैसे आह्वान बाहर कोड होने Fred.vision.lookAt(George)समझ में आता है, लेकिन यह कहना कोड की इजाजत दी someEyes = Fred.vision; someTubes = Fred.digestionभावुक लगता है के बाद से यह के बीच के रिश्ते को धुंधला someEyesऔर someTubes।

— supercat

1

विशेष रूप से एकल जिम्मेदारी के रूप में इस तरह के महत्वपूर्ण सिद्धांत के साथ, मैं व्यक्तिगत रूप से उम्मीद करूंगा कि लोग इस सिद्धांत को अपनाने के कई कारण हैं।

उनमें से कुछ कारण हो सकते हैं:

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

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

— जश्न
स्रोत

... test is not affected by other responsibilities the class has, क्या आप इस पर विस्तार से बता सकते हैं?

— महदी

1

इन सिद्धांतों के महत्व को समझने का सबसे अच्छा तरीका आवश्यकता है।

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

छोटी परियोजनाओं पर, यह बात नहीं हो सकती है, लेकिन बड़ी परियोजनाओं में, चीजें बहुत बुरे हो सकती हैं। बाद में जब मुझे डिज़ाइन पेटेंट की अवधारणाएँ आईं, तो मैंने अपने आप से कहा, "ओह याह, ऐसा करने से चीजें इतनी आसान हो जाती हैं"।

आप वास्तव में डिज़ाइन पैटर्न के महत्व को तब तक नहीं समझ सकते जब तक कि आवश्यकता नहीं उठती। मैं पैटर्न का सम्मान करता हूं क्योंकि अनुभव से मैं कह सकता हूं कि वे कोड रखरखाव को आसान और कोड को मजबूत बनाते हैं।

हालाँकि, आपकी तरह, मैं अभी भी "आसान परीक्षण" के बारे में अनिश्चित हूं, क्योंकि मुझे अभी तक इकाई परीक्षण में शामिल होने की आवश्यकता नहीं है।

— harsimranb
स्रोत

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

— मैकीज छलापुक

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

— हरसिमरनब

1

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

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

मुझे लगता है कि इसे एक शब्द में सम्‍मिलित किया जा सकता है: गुंजाइश। कलाकृतियों के दायरे पर पूरा ध्यान दें, किसी विशेष बिंदु पर किसी चीज के दायरे में कम चीजें बेहतर होंगी।

विस्तारित दायरा = अधिक जटिलता = चीजों के गलत होने के लिए और अधिक तरीके।

— jmoreno
स्रोत

1

यदि कोई कक्षा बहुत बड़ी है, तो उसे बनाए रखना, परीक्षण करना और समझना कठिन हो जाता है, अन्य उत्तरों ने इस इच्छा को कवर किया है।

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

हालांकि "केवल एक जिम्मेदारी" का एक सरल नियम होने से यह जानना आसान हो जाता है कि आपको एक नए वर्ग की आवश्यकता कब है ।

हालांकि "जिम्मेदारी" को परिभाषित करना कठिन है, इसका मतलब यह नहीं है कि "सब कुछ आवेदन की युक्ति कहता है", असली कौशल यह है कि समस्या को "जिम्मेदारी" की छोटी इकाइयों में कैसे तोड़ा जाए।

— इयान
स्रोत