एकल उत्तरदायित्व सिद्धांत और चिंता का पृथक्करण

Question

एकल उत्तरदायित्व सिद्धांत और चिंता का पृथक्करण के बीच क्या अंतर है?

Answer 1

एकल जिम्मेदारी सिद्धांत (SRP) - प्रत्येक वर्ग के सिर्फ एक परिवर्तन के कारण दे; और "बदलने का कारण" == "ज़िम्मेदारी"। उदाहरण में: चालान कक्षा में खुद को मुद्रित करने के लिए की ज़िम्मेदारी नहीं है।

चिंता का पृथक्करण (1 9 74 से)। चिंता == प्रणाली की सुविधा। प्रत्येक चिंताओं का ख्याल रखना: प्रत्येक एक चिंता के लिए, अन्य चिंताएं अप्रासंगिक हैं। व्यवहार के कार्यान्वयन को छुपाएं।

here से।

Answer 2

Separation of Concern vs Single Responsibility Principle (SoC vs SRP)

जुड़ा हुआ लेख से:

चिंताएं (SoC) का पृथक्करण - अलग विशेषताएं है कि संभव के रूप में छोटे रूप में कार्यक्षमता में ओवरलैप में एक कंप्यूटर प्रोग्राम तोड़ने की प्रक्रिया है। चिंता एक कार्यक्रम में रुचि या फोकस का कोई टुकड़ा है। आम तौर पर, चिंताओं विशेषताओं या व्यवहार के पर्याय हैं। http://en.wikipedia.org/wiki/Separation_of_concerns

एकल जिम्मेदारी सिद्धांत (SRP) - हर वस्तु एक भी जिम्मेदारी होनी चाहिए, और अपने सभी सेवाओं बाल बाल कि जिम्मेदारी के साथ गठबंधन किया जाना चाहिए। कुछ स्तर पर कोसियन को एसआरपी के पर्याय के रूप में माना जाता है। http://en.wikipedia.org/wiki/Single_responsibility_principle

Answer 3

एकल उत्तरदायित्व बताती है कि एक वस्तु काम की एक इकाई के लिए जिम्मेदार है।

चिंता का पृथक्करण बताता है कि अनुप्रयोगों को मॉड्यूल में विभाजित किया जाना चाहिए जिनकी कार्यक्षमता जितनी कम हो सके ओवरलैप हो।

इसी तरह के अंतिम परिणाम ... थोड़ा अलग अनुप्रयोग।

Answer 4

मेरी राय में एकल उत्तरदायित्व सिद्धांत चिंता के पृथक्करण को प्राप्त करने के लिए उपकरण/मुहावरों में से एक है।

Answer 5

चिंता का पृथक्करण एक प्रक्रिया है; एकल जिम्मेदारी सिद्धांत एक डिजाइन/वास्तुकला दर्शन है। वे पूरी तरह से विवाद नहीं कर रहे हैं, लेकिन वे विभिन्न उद्देश्यों की सेवा करते हैं।

Answer 6

इसी प्रकार, लेकिन एसओसी चिंताओं से संबंधित है: कई चिंताओं में जटिल समस्या को तोड़ने के लिए, एसआरपी सिर्फ एक जिम्मेदारी है।

Answer 7

एकल जिम्मेदारी सिद्धांत और चिंता का पृथक्करण वास्तव में वही बात है।

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

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

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

निचले स्तर पर इसे कक्षाओं में भी लागू किया जाना चाहिए। एक वर्ग में दर्जनों तरीकों को डालने के बजाय, कोड को कई में विभाजित करें। इसी कारण से।

इसके अलावा एक विधि स्तर पर, छोटी विधियों को बड़े तरीकों से विभाजित करें।

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

Answer 8

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

Answer 9

चिंताओं का पृथक्करण (एसओसी)। अपनी एप्लिकेशन को यथासंभव कार्यक्षमता में थोड़ा ओवरलैप के साथ अलग-अलग विशेषताओं में विभाजित करें। (Microsoft)।

"चिंता" = "अलग विशेषता" = "अलग अनुभाग"

"चिंता" उच्च और निम्न दोनों स्तरों पर काम करता

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

"उत्तरदायित्व" = "बदलने का कारण" क्या बदलता है? "सॉफ्टवेयर द्वारा प्रदान की कार्यक्षमता के किसी एक भाग" = बुनियादी इकाई

निष्कर्ष

• एकल जिम्मेदारी सिद्धांत बुनियादी इकाइयों पर काम करता है -> निम्न स्तर

• पृथक्करण पर काम करता है चिंताएं उच्च और निम्न दोनों स्तरों पर काम करती हैं

• एसआरपी और एसओसी अलग-अलग के लिए मिलकर काम करते हैं चिंताओं परवे
  निम्न स्तर पर ठीक उसी

Answer 10

मैं चिंताओं (SoC) का पृथक्करण और एकल जिम्मेदारी सिद्धांत (SRP) के बीच तुलना आकर्षित करने के लिए करने की कोशिश की है।

मतभेद

• SRP श्रेणी स्तर पर है, लेकिन SoC प्रत्येक कंप्यूटर प्रोग्राम, अमूर्त ... या कभी कभी वास्तु स्तर में है।

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

• एसआरपी की अवधारणा एकजुटता (उच्च समेकन) पर आधारित है, जबकि एसओसी आण्विकता, विभाजन और जीत (डी सी) के करीब है, ... प्रत्येक स्तर के अमूर्तता में।

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

समानताएँ

• इन सिद्धांतों में से प्रत्येक को लागू करने के बाद, अपने संदर्भ, है, और अधिक पुन: प्रयोज्य पोषणीय, मजबूत, पठनीय हो जाता है ...।