सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल और सेपरेशन ऑफ कंसर्न के बीच अंतर क्या है

Question

a) SRP और SoC में क्या अंतर है ? शायद वह एसआरपी वर्ग स्तर पर लागू होता है, जबकि एसओसी सिस्टम , सबसिस्टम , मॉड्यूल , क्लास या फ़ंक्शन स्तरों पर लागू किया जा सकता है ।

b) यदि उत्तर a) हाँ है, तो SoC को वर्ग स्तर पर SRP का पर्यायवाची कहा जाता है ?

धन्यवाद

Answer 1

सिंगल रिस्पांसिबिलिटी प्रिंसिपल आपके कोड के बारे में केवल 1 काम कर रहा है और आप सभी कार्यक्षमता को कई वर्गों में विभाजित कर सकते हैं जो सभी 1 विशिष्ट कार्य करने के लिए हैं। एक उदाहरण सत्यापन के लिए एक विशिष्ट वर्ग है, कुछ व्यावसायिक तर्क करना, एक मॉडल को समृद्ध करना, डेटा को पुनः प्राप्त करना, डेटा को अपडेट करना, नेविगेशन, आदि।

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

कुछ SoC का उदाहरण है, लेकिन SRP नहीं है

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;

    public Foo(IValidator validator, IDataRetriever dataRetriever)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return ValidBusinessLogic();
            }
        }
        return InvalidItems();
    }

    private object DoSomeFancyCalculations(object item)
    {
        return new object();
    }
    private NavigationObject ValidBusinessLogic()
    {
        return new NavigationObject();
    }

    private NavigationObject InvalidItems()
    {
        return new NavigationObject();
    }
}

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

जैसा कि आप देख सकते हैं कि इस वर्ग में 3 निजी विधियां शामिल हैं जो कुछ फैंसी चीजें करती हैं। एसआरपी के दृष्टिकोण से, उन विधियों को संभवतः अपने स्वयं के कुछ वर्गों के भीतर रखा जाना चाहिए। उनमें से 2 नेविगेशन के साथ कुछ करते हैं, जो कुछ इंविवेशन क्लास में फिट होगा। एक आइटम पर अन्य कुछ फैंसी गणना करता है, इसे संभवत: IBusinessLogic वर्ग में रखा जा सकता है।

इस तरह से कुछ होने के बाद, आपके पास जगह में SoC और SRP दोनों हैं:

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;
    private readonly IBusinessLogic _businessLogic;
    private readonly INavigation _navigation;

    public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
        _businessLogic = businessLogic;
        _navigation = navigation;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = _businessLogic.DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return _navigation.ValidBusinessLogic();
            }
        }
        return _navigation.InvalidItems();
    }
}

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

Comments

"जेबी किंग के जवाब में पूरी पोस्ट पढ़ने के बाद, मुझे लगता है कि यह एक अच्छी पोस्ट है।" लेकिन जेबी किंग का जवाब आपके उत्तर के विपरीत का दावा कर रहा है - अर्थात कि एसओसी एकल जिम्मेदारी के बारे में भी है, केवल यह कि यह SRP की तुलना में उच्च स्तर पर लागू किया जा सकता है

— user1483278

Answer 2

एसआरपी के लिए केवल कक्षा स्तर पर लागू किया जा रहा है, उनकी पुस्तकों में रॉबर्ट सी। मार्टिन (जहां तक ​​मुझे पता है कि वे इस अवधारणा के साथ नहीं आए तो लोकप्रिय हुए):

क्लीन कोड, पेज। 138 : "सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल (एसआरपी) में कहा गया है कि एक वर्ग या मॉड्यूल में एक, और केवल एक, बदलने का कारण होना चाहिए।"

C # में फुर्तीली सिद्धांतों, प्रतिमानों और प्रथाओं, पृष्ठ 116 : "[...] और उन बलों से सामंजस्य का संबंध है जो एक मॉड्यूल , या एक वर्ग को बदलते हैं।"

जोर मेरा।

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

ऐसे कारण से मैं एसआरपी को एसओसी के रूप में योग्य नहीं बनाऊंगा क्योंकि आप अपने प्रश्न में सुझाव देते हैं।

Comments

इसलिए यदि हम मानते हैं कि SRP को उच्च स्तरों पर भी लागू किया जा सकता है, तो SRP और SoC के बीच का अंतर यह है कि SRP के पास एक ही जिम्मेदारी है, जबकि SoC में निकट संबंधी जिम्मेदारियों का एक सेट हो सकता है?

— user1483278

@ user1483278: वैसे तो मैं एसआरपी से बहुत परिचित हूं, लेकिन मैंने इस सवाल को पढ़ते हुए पहली बार एसओसी के बारे में सुना, इसलिए मैं आपकी टिप्पणी का जवाब नहीं दे सकता। शब्दार्थ से ऐसा लगता है कि एसआरपी में 1 जिम्मेदारी और एसओसी की चिंताएं हैं, मुझे पता है कि यह एक पांडित्यपूर्ण जवाब है, लेकिन आवेदन में परेशान करने वाले सिद्धांत समान परिणाम देते हैं।

— गाइल्स

Answer 3

यहां आप उन शब्दावली के बीच अंतर को स्पष्ट करते हुए एक छोटा वीडियो पा सकते हैं। https://www.youtube.com/watch?v=C7hkrV1oaSY

चिंताओं का अलग होना (SoC)। संभव के रूप में कार्यक्षमता में कम ओवरलैप के साथ अपने आवेदन को अलग-अलग विशेषताओं में विभाजित करें। (Microsoft)।

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

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

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

"जिम्मेदारी" = "बदलने का कारण"

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

निष्कर्ष

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

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

एसआरपी और एसओसी चिंताओं को अलग करने के लिए एक साथ काम करते हैं। वे निम्न स्तर पर बिल्कुल समान हैं

Answer 4

यहाँ इन सिद्धांतों के बारे में मेरी समझ है।

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

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

इसके अलावा, मैंने अपने ब्लॉग पोस्ट में इन सिद्धांतों का अधिक विवरण दिया है, कृपया देखें।

https://crosp.net/blog/software-architecture/srp-soc-android-settings-example/