एकल जिम्मेदारी सिद्धांत स्पष्ट करें

64

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

आप कैसे वर्णन करेंगे कि "एक चीज" का क्या मतलब है? कुछ ठोस संकेत क्या हैं जो एक वर्ग वास्तव में "एक बात" से अधिक करता है?

design object-oriented

— dsimcha
स्रोत

6

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

— बॉबी टेबल्स

50

मैं वास्तव में जिस तरह से रॉबर्ट सी। मार्टिन (अंकल बॉब) ने सिंगल रिस्पांसिबिलिटी प्रिंसिपल (पीडीएफ से जुड़ा ) को बहाल किया है :

वर्ग बदलने के लिए एक से अधिक कारण कभी नहीं होने चाहिए

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

लिंक किए गए लेख में, अंकल बॉब ने निष्कर्ष निकाला:

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

— Paddyslacker
स्रोत

2

मुझे वह पसंद है जिस तरह से वह इसे भी बताता है, यह जांचने में आसान लगता है कि अमूर्त "जिम्मेदारी" के बजाय परिवर्तन से संबंधित है।

— मैथ्यू एम।

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

— कोडेक्सआर्कनम

1

बस यह मेरे ग्रेड के लिए दिखाया - महान पढ़ा और अपने आप को एक अच्छा अनुस्मारक।

— मार्टिज़न वेरबर्ग

1

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

— dsimcha

18

मैं खुद से पूछती रहती हूं कि एसआरपी हल करने की क्या समस्या है? SRP कब मेरी मदद करता है? यहाँ मैं क्या लेकर आया हूँ:

आपको कक्षा से बाहर होने पर जिम्मेदारी / कार्यक्षमता को वापस करना चाहिए:

1) आपने डुप्लिकेट कार्यक्षमता (DRY)

2) आप देखेंगे कि आपके कोड के क्रम में मदद करने के यह समझ में अमूर्त का एक और स्तर की जरूरत है लगता है (चुंबन)

3) आप पाते हैं कि कार्यक्षमता के टुकड़े आपके डोमेन विशेषज्ञों द्वारा एक अलग घटक के रूप में समझे जा रहे हैं (सर्वव्यापी भाषा)

जब आप एक कक्षा से बाहर की जिम्मेदारी को वापस लेने की जिम्मेदारी देंगे:

1) कोई डुप्लिकेट कार्यक्षमता नहीं है।

2) कार्यक्षमता आपके वर्ग के संदर्भ से बाहर नहीं है। दूसरा तरीका रखो, आपकी कक्षा एक संदर्भ प्रदान करती है जिसमें कार्यक्षमता को समझना आसान है।

3) आपके डोमेन विशेषज्ञों के पास उस जिम्मेदारी की अवधारणा नहीं है।

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

जब संदेह में, इसे छोड़ दो! आप हमेशा बाद में रिफ्लेक्टर कर सकते हैं, जब इसके लिए कोई स्पष्ट मामला हो।

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

— ब्रैंडन
स्रोत

हालांकि ये दिशा-निर्देश मददगार हो सकते हैं या नहीं भी हो सकते हैं, लेकिन इसका एसआरपी से कोई लेना-देना नहीं है, जैसा कि एसओएलआईडी में परिभाषित है, क्या ऐसा होता है?

— सारा

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

— निकोलस पीटरसन

4

मुझे नहीं पता कि इसका कोई ऑब्जेक्टिव पैमाना है लेकिन इससे दूर होने के क्या तरीके होंगे - इतनी संख्या में नहीं बल्कि उनके फंक्शन की विविधता। मैं मानता हूं कि आप बहुत दूर तक विघटित हो सकते हैं, लेकिन मैं इसके बारे में कोई कठिन और तेज नियमों का पालन नहीं करूंगा।

— जेरेमी
स्रोत

4

उत्तर परिभाषा में निहित है

आप जिस जिम्मेदारी को परिभाषित करते हैं, वह अंत में आपको सीमा देती है।

उदाहरण:

मेरे पास एक घटक है जिसमें चालान प्रदर्शित करने की जिम्मेदारी है -> इस मामले में, अगर मैंने कुछ और जोड़ना शुरू किया तो मैं सिद्धांत को तोड़ रहा हूं।

दूसरी ओर, अगर मैं की जिम्मेदारी कहा हैंडलिंग चालान -> कई छोटे कार्यों को जोड़ने (मुद्रण जैसे चालान , अद्यतन करने के चालान ) सभी कि सीमा के भीतर हैं।

हालाँकि अगर उस मॉड्यूल ने चालानों के बाहर किसी भी कार्यक्षमता को संभालना शुरू किया , तो यह उस सीमा के बाहर होगा।

— अँधेरी रात
स्रोत

मुझे लगता है कि मुख्य समस्या "हैंडलिंग" शब्द है। यह एक जिम्मेदारी को परिभाषित करने के लिए बहुत सामान्य है। मुझे लगता है कि प्रिंट इनवॉइस के लिए एक घटक के लिए जिम्मेदार होना बेहतर होगा और एक एकल घटक हैंडल {प्रिंट, अपडेट, और - के बजाय अपडेट इनवॉइस के लिए एक और क्यों? - प्रदर्शन, जो कुछ भी} चालान ।

— मचाडो

1

ओपी अनिवार्य रूप से पूछ रहा है "आप एक जिम्मेदारी कैसे परिभाषित करते हैं?" इसलिए जब आप कहते हैं कि ज़िम्मेदारी वह है जो आप इसे परिभाषित करते हैं तो ऐसा लगता है जैसे यह सिर्फ सवाल दोहरा रहा है।

— डेस्परर्ट

2

मैं हमेशा इसे दो स्तरों पर देखता हूं:

मुझे यकीन है कि मेरे तरीके केवल एक ही काम करते हैं और इसे अच्छी तरह से करते हैं
मैं एक वर्ग को उन तरीकों के एक तार्किक (OO) समूह के रूप में देखता हूं जो एक बात का अच्छी तरह से प्रतिनिधित्व करते हैं

तो डॉग नामक एक डोमेन ऑब्जेक्ट की तरह कुछ:

Dogमेरी कक्षा है लेकिन कुत्ते कई काम कर सकते हैं! मेरे पास ऐसे तरीके हो सकते हैं walk(), run()और bite(DotNetDeveloper spawnOfBill)(क्षमा नहीं कर सकता; पी)।

अगर Dogमैं अनजान बन जाता हूं, तो मैं इस बारे में सोचूंगा कि कैसे उन तरीकों के समूहों को एक अन्य वर्ग में एक साथ मॉडल किया जा सकता है, जैसे कि एक Movementवर्ग, जिसमें मेरे walk()और run()तरीके शामिल हो सकते हैं ।

कोई कठिन और तेज़ नियम नहीं है, आपका OO डिज़ाइन समय के साथ विकसित होगा। मैं एक स्पष्ट कट इंटरफ़ेस / सार्वजनिक एपीआई के साथ-साथ सरल तरीकों के लिए जाने की कोशिश करता हूं जो एक चीज और एक अच्छी तरह से करते हैं।

— मार्टिजन वर्बर्ग
स्रोत

बाइट को वास्तव में ऑब्जेक्ट का एक उदाहरण लेना चाहिए, और एक डॉटनेटड्यूपर को व्यक्ति का उपवर्ग होना चाहिए (आमतौर पर, वैसे भी!)

— एलन पीयर्स

@ एलन - वहाँ - आप के लिए तय है कि :-)

— मार्टिज्न वर्बर्ग

1

मैं इसे एक वर्ग की तर्ज पर अधिक देखता हूं, केवल एक चीज का प्रतिनिधित्व करना चाहिए । उपयुक्त @ कृण्णा के उदाहरण के लिए, मेरे पास मेरी Dogकक्षा है, जिसके लिए तरीके हैं walk(), run()और bark()। मैं के लिए तरीकों को जोड़ने के लिए नहीं जा रहा हूँ meaow(), squeak(), slither()या fly()क्योंकि उन चीजों कुत्तों है कि नहीं कर रहे हैं। वे ऐसी चीजें हैं जो अन्य जानवर करते हैं, और उन अन्य जानवरों के पास उनका प्रतिनिधित्व करने के लिए उनकी अपनी कक्षाएं होंगी।

(BTW, अगर अपने कुत्ते करता है के लिए उड़ान भरने, तो आप शायद उसे खिड़की से बाहर फेंक बंद कर देना चाहिए)।

— JohnL
स्रोत

+1 के लिए "यदि आपका कुत्ता उड़ता है, तो आपको शायद उसे खिड़की से बाहर फेंकना बंद कर देना चाहिए"। :)

— बॉबी टेबल्स

इस सवाल से परे कि किस वर्ग को प्रतिनिधित्व करना चाहिए, एक उदाहरण क्या दर्शाता है? यदि किसी की SeesFoodविशेषता के रूप में संबंध है DogEyes, Barkजैसा कि कुछ के द्वारा किया जाता है DogVoice, और Eatजैसा कि कुछ द्वारा किया जाता है DogMouth, तो तर्क जैसे if (dog.SeesFood) dog.Eat(); else dog.Bark();बन जाएगा if (eyes.SeesFood) mouth.Eat(); else voice.Bark();, पहचान की किसी भी भावना को खो देते हैं कि आंख, मुंह और आवाज सभी एक एकलता से जुड़े होते हैं।

— सुपरकैट

@supercat यह एक उचित बिंदु है, हालांकि संदर्भ महत्वपूर्ण है। यदि आप जिस कोड का उल्लेख करते हैं Dog, वह कक्षा के भीतर है , तो यह संभवतः- Dogसंबंधित है। यदि नहीं, तो आप शायद myDog.Eyes.SeesFoodकेवल के बजाय कुछ के साथ समाप्त हो जाएगा eyes.SeesFood। एक और संभावना यह है कि इंटरफ़ेस Dogको उजागर करता ISeeहै जो Dog.Eyesसंपत्ति और SeesFoodविधि की मांग करता है ।

— जॉनएल

@ जॉन: यदि देखने के वास्तविक यांत्रिकी को कुत्ते की आंखों द्वारा संभाला जाता है, अनिवार्य रूप से बिल्ली या ज़ेबरा के द्वारा उसी तरह, तो यह समझ में आ सकता है कि यांत्रिकी को एक Eyeवर्ग द्वारा नियंत्रित किया गया है , लेकिन एक कुत्ते को "देखना चाहिए" इसकी आँखों का उपयोग करने के बजाय, केवल आँखें होने से जो देख सकती हैं। एक कुत्ता एक आँख नहीं है, लेकिन न ही यह केवल एक आँख-धारक है। यह एक "बात है जो कम से कम [देखने की कोशिश] कर सकता है, और इस तरह के होने के नाते इंटरफ़ेस के माध्यम से वर्णित किया जाना चाहिए। यहां तक कि एक अंधे कुत्ते से पूछा जा सकता है कि क्या वह भोजन देखता है; यह बहुत उपयोगी नहीं होगा, क्योंकि कुत्ते हमेशा "नहीं" कहेंगे, लेकिन पूछने में कोई बुराई नहीं है।

— सुपरकैट

फिर आप ISee इंटरफ़ेस का उपयोग करेंगे जैसे मैं अपनी टिप्पणी में वर्णित करता हूं।

— JohnL

1

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

मैं इसके लिए परीक्षण के रूप में वर्ग के नाम का उपयोग करता हूं। यदि मैं किसी वर्ग को एक संक्षिप्त विवरणात्मक नाम नहीं दे सकता, या यदि उस नाम में "एंड" जैसा शब्द है, तो मैं शायद सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल का उल्लंघन कर रहा हूं।

मेरे अनुभव में, इस सिद्धांत को निचले स्तरों पर रखना आसान है, जहां चीजें अधिक ठोस हैं।

— डेविड थॉर्नले
स्रोत

0

यह एक अद्वितीय राउल होने के बारे में है ।

प्रत्येक वर्ग को एक भूमिका नाम से फिर से शुरू किया जाना चाहिए। एक भूमिका वास्तव में एक संदर्भ से जुड़ी क्रिया (सेट) की है।

उदाहरण के लिए :

फ़ाइल एक फ़ाइल का उपयोग प्रदान करती है। FileManager फ़ाइल ऑब्जेक्ट का प्रबंधन करता है।

संसाधन एक फ़ाइल से एक संसाधन के लिए डेटा रखता है। रिसोर्स मैनेजर सभी संसाधनों को रखता है और प्रदान करता है।

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

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

मैं अक्सर उन प्रबंधक वर्गों का निर्माण करता हूं जिनमें कई अलग-अलग वर्ग होते हैं। एक कारखाने, एक रजिस्ट्री, आदि की तरह, एक प्रबंधक वर्ग देखें जैसे कि समूह प्रमुख, एक ऑर्केस्ट्रा प्रमुख जो अन्य लोगों को एक उच्च स्तरीय विचार प्राप्त करने के लिए एक साथ काम करने के लिए मार्गदर्शन करता है। उनकी एक भूमिका है, लेकिन अंदर की अन्य अनोखी भूमिकाओं के साथ काम करना। आप यह भी देख सकते हैं कि कैसे एक कंपनी का आयोजन किया जाता है: एक सीईओ शुद्ध उत्पादकता स्तर पर उत्पादक नहीं है, लेकिन यदि वह वहां नहीं है, तो कुछ भी सही ढंग से काम नहीं कर सकता है। यही उनकी भूमिका है।

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

— Klaim
स्रोत

-1

SRP केवल वर्गों को विभाजित करने के बारे में नहीं है, बल्कि कार्यक्षमता को प्रत्यायोजित करने के बारे में भी है।

ऊपर दिए गए डॉग उदाहरण में, SRP का उपयोग औचित्य के रूप में न करें 3 अलग-अलग वर्गों जैसे कि डॉगबर्कर, डॉगवल्कर, आदि (कम सामंजस्य)। इसके बजाय, एक वर्ग के तरीकों के कार्यान्वयन को देखें और तय करें कि क्या वे "बहुत ज्यादा जानते हैं"। आपके पास अभी भी dog.walk () हो सकता है, लेकिन शायद वॉक () विधि को किसी अन्य वर्ग को सौंपना चाहिए कि कैसे चलना पूरा होता है।

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

SOLID का शुद्ध प्रभाव यह है कि हमें मौजूदा कोड को संशोधित करने की तुलना में अधिक बार नया कोड लिखना पड़ता है, और यह एक बड़ी जीत है।

— user1488779
स्रोत

-1

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

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

इसलिए, यदि हम जिम्मेदारी को और अधिक ठोस तरीके से परिभाषित कर रहे हैं, तो हमें इसे बदलने की आवश्यकता नहीं है।

कभी-कभी जिम्मेदारियां स्पष्ट रूप से स्पष्ट होंगी, लेकिन कभी-कभी यह सूक्ष्म हो सकती है और हमें विवेकपूर्ण तरीके से निर्णय लेने की आवश्यकता है।

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

— अक्स
स्रोत

-1

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

— kiwicomb123
स्रोत

1

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

— candied_orange

हमें सबसे अधिक संभावित परिवर्तनों की सूची क्यों नहीं बनानी चाहिए? सट्टा डिजाइन?

— कीवीकोम्बजैम

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

— कैंडिड_ऑरेंज

ठीक है, मैं समझता हूँ, यह "आपकी जरूरत नहीं है" सिद्धांत का उल्लंघन करता है।

— kivicomb123

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

— कैंडिड_ऑरेंज