एकल उत्तरदायित्व सिद्धान्त। जस्तो देखिन्छ जस्तो सरल छैन

एकल जिम्मेवारी सिद्धान्त, जसलाई एकल जिम्मेवारीको सिद्धान्त पनि भनिन्छ,
एक समान परिवर्तनशीलता को सिद्धान्त उर्फ ​​- बुझ्न को लागी एक अत्यन्त चिप्लो मान्छे र एक प्रोग्रामर अन्तर्वार्ता मा यस्तो नर्वस प्रश्न।

यस सिद्धान्तसँग मेरो पहिलो गम्भीर परिचय पहिलो वर्षको सुरुमा भएको थियो, जब जवान र हरियोहरूलाई लार्भाबाट विद्यार्थीहरू बनाउन जंगलमा लगियो - वास्तविक विद्यार्थीहरू।

जङ्गलमा, हामी 8-9 जनाको समूहमा विभाजित थियौं र प्रतिस्पर्धा थियो - कुन समूहले भोड्काको बोतल सबैभन्दा छिटो पिउने हो, यदि समूहको पहिलो व्यक्तिले गिलासमा भोड्का खन्यायो, दोस्रोले यसलाई पिउने, र तेस्रोले खाजा खायो। आफ्नो सञ्चालन पूरा गरेको एकाइ समूहको लामको अन्त्यमा सर्छ।

लामको आकार तीन को गुणन भएको अवस्थामा SRP को राम्रो कार्यान्वयन थियो।

परिभाषा १. एकल जिम्मेवारी।

एकल उत्तरदायित्व सिद्धान्त (SRP) को आधिकारिक परिभाषाले बताउँछ कि प्रत्येक संस्थाको आफ्नै जिम्मेवारी र अस्तित्वको कारण छ, र यसको एक मात्र जिम्मेवारी छ।

"पिउने" वस्तुलाई विचार गर्नुहोस् (टिप्लर).
SRP सिद्धान्त लागू गर्न, हामी जिम्मेवारीहरूलाई तीन भागमा विभाजन गर्नेछौं:

• एक खन्याउछ (PourOperation)
• एक पेय (पेय अपरेशन)
• एउटा खाजा छ (TakeBiteOperation)

प्रक्रियामा प्रत्येक सहभागी प्रक्रियाको एक घटकको लागि जिम्मेवार छ, त्यो हो, एक परमाणु जिम्मेवारी छ - पिउन, खन्याउन वा खाजा।

पिउने प्वाल, बारीमा, यी कार्यहरूको लागि मुखौटा हो:

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налить
        _drinkUpOperation.Do() // выпить
        _takeBiteOperation.Do() // закусить
    }
}

किन?

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

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

त्यसकारण, मानव प्रोग्रामरहरूले जटिल संयन्त्रहरूलाई कम जटिल र काम गर्ने तत्वहरूको सेटमा विघटन गर्छन्। यद्यपि, यसलाई विभिन्न तरिकामा विघटन गर्न सकिन्छ: धेरै पुरानो कारहरूमा, हावा नलिका ढोकामा जान्छ, र आधुनिक कारहरूमा, लक इलेक्ट्रोनिक्समा विफलताले इन्जिनलाई सुरु गर्नबाट रोक्छ, जुन मर्मतको समयमा समस्या हुन सक्छ।

अहिले, SRP एउटा सिद्धान्त हो जसले कसरी विघटन गर्ने भनेर व्याख्या गर्छ, अर्थात्, विभाजन रेखा कहाँ कोर्ने.

उनी भन्छन् कि यो "जिम्मेवारी" को विभाजन को सिद्धान्त अनुसार विघटन गर्न आवश्यक छ, अर्थात्, केहि वस्तुहरु को कार्यहरु को अनुसार।

रक्सी पिउने र विघटन हुँदा बाँदरले प्राप्त गर्ने फाइदाहरूमा फर्कौं:

• कोड हरेक तहमा अत्यन्त स्पष्ट भएको छ
• कोड एकै पटक धेरै प्रोग्रामरहरू द्वारा लेख्न सकिन्छ (प्रत्येकले छुट्टै तत्व लेख्छ)
• स्वचालित परीक्षणलाई सरलीकृत गरिएको छ - तत्व जति सरल हुन्छ, परीक्षण गर्न त्यति नै सजिलो हुन्छ
• कोडको संरचनात्मकता देखिन्छ - तपाइँ बदल्न सक्नुहुन्छ पेय अपरेशन एक अपरेसनमा जसमा एक रक्सीले टेबल मुनि तरल खन्याउछ। वा पोउरिङ अपरेशनलाई एउटा अपरेशनले बदल्नुहोस् जसमा तपाईंले वाइन र पानी वा भोड्का र बियर मिसाउनुहुन्छ। व्यापार आवश्यकताहरूमा निर्भर गर्दै, तपाइँ विधि कोड नछोइकन सबै गर्न सक्नुहुन्छ Tippler.Act.
• यी अपरेसनहरूबाट तपाईंले ग्लुटन फोल्ड गर्न सक्नुहुन्छ (केवल प्रयोग गरेर TakeBitOperation), रक्सी (केवल प्रयोग गरेर पेय अपरेशन सिधा बोतलबाट) र अन्य धेरै व्यवसाय आवश्यकताहरू पूरा गर्नुहोस्।

(ओह, यो पहिले नै OCP सिद्धान्त हो जस्तो देखिन्छ, र मैले यो पोस्टको जिम्मेवारी उल्लङ्घन गरेको छु)

र, निस्सन्देह, विपक्ष:

• हामीले थप प्रकारहरू सिर्जना गर्नुपर्नेछ।
• मादक पदार्थ पिउने व्यक्तिले अन्यथा पिउने भन्दा केही घण्टा पछि पहिलो पटक पिउछ।

परिभाषा २. एकीकृत परिवर्तनशीलता।

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

पिउने को दुई कार्यान्वयन विचार गरौं। पहिलो, माथि उल्लेखित, तीन वर्गहरू छन् - खन्य, पेय र खाजा।

दोस्रो "फर्वार्ड र ओन्ली फर्वार्ड" पद्धति मार्फत लेखिएको छ र विधिमा सबै तर्कहरू समावेश छन्। अधिनियम:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
сlass BrutTippler {
   //...
   void Act(){
        // наливаем
    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))
        throw new OverdrunkException();

    // выпиваем
    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))
        throw new OverdrunkException();

    //Закусываем
    for(int i = 0; i< 3; i++){
        var food = _foodStore.TakeOrDefault();
        if(food==null)
            throw new FoodIsOverException();

        _hand.TryEat(food);
    }
   }
}

यी दुवै वर्गहरू, बाहिरी पर्यवेक्षकको दृष्टिकोणबाट, ठ्याक्कै उस्तै देखिन्छन् र "पिउने" को समान जिम्मेवारी साझा गर्छन्।

भ्रम!

त्यसपछि हामी अनलाइन जान्छौं र SRP को अर्को परिभाषा फेला पार्छौं - एकल परिवर्तनशीलता सिद्धान्त।

SCP ले भन्छ कि "मोड्युलमा परिवर्तनको एउटा मात्र कारण हुन्छ"। त्यो हो, "उत्तरदायित्व परिवर्तनको कारण हो।"

(यस्तो देखिन्छ कि मूल परिभाषाको साथ आएका केटाहरू एप म्यानको टेलिपाथिक क्षमताहरूमा विश्वस्त थिए)

अब सबै ठाउँमा खस्छ। अलग रूपमा, हामी खन्याउने, पिउने र स्न्याकिङ प्रक्रियाहरू परिवर्तन गर्न सक्छौं, तर पिउनेमा हामी मात्र कार्यहरूको अनुक्रम र संरचना परिवर्तन गर्न सक्छौं, उदाहरणका लागि, पिउनु अघि खाजा सार्न वा टोस्टको पढाइ थपेर।

"फर्वार्ड र ओन्ली फर्वार्ड" दृष्टिकोणमा, परिवर्तन गर्न सकिने सबै कुरा विधिमा मात्र परिवर्तन हुन्छ अधिनियम। यो पढ्न योग्य र प्रभावकारी हुन सक्छ जब त्यहाँ थोरै तर्क हुन्छ र यो विरलै परिवर्तन हुन्छ, तर प्रायः यो 500 लाइनहरूको भयानक विधिहरूमा समाप्त हुन्छ, रूसलाई NATO मा सामेल हुन आवश्यक भन्दा बढी यदि-कथनहरू सहित।

परिभाषा 3. परिवर्तनहरूको स्थानीयकरण।

मदिरा पिउनेहरूले अक्सर बुझ्दैनन् किन तिनीहरू अरू कसैको अपार्टमेन्टमा उठे, वा तिनीहरूको मोबाइल फोन कहाँ छ। यो विस्तृत लगिङ थप्न समय हो।

खन्याउने प्रक्रियाको साथ लगिङ सुरु गरौं:

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Before pour with {_hand} and {_bottle}");
        //Pour business logic ...
        _log.Log($"After pour with {_hand} and {_bottle}");
    }
}

यसलाई इनक्याप्सुलेट गरेर PourOperation, हामीले जिम्मेवारी र इन्क्याप्सुलेशनको दृष्टिकोणबाट बुद्धिमानीपूर्वक काम गर्यौं, तर अब हामी परिवर्तनशीलताको सिद्धान्तमा अलमलमा छौं। अपरेशनको अतिरिक्त, जुन परिवर्तन हुन सक्छ, लगिङ आफै पनि परिवर्तनीय हुन्छ। तपाईंले खन्याउने कार्यको लागि छुट्टै र विशेष लगर सिर्जना गर्नुपर्नेछ:

interface IPourLogger{
    void LogBefore(IHand, IBottle){}
    void LogAfter(IHand, IBottle){}
    void OnError(IHand, IBottle, Exception){}
}

class PourOperation: IOperation{
    PourOperation(IPourLogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.LogBefore(_hand, _bottle);
        try{
             //... business logic
             _log.LogAfter(_hand, _bottle");
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e)
        }
    }
}

सचेत पाठकले यो याद गर्नेछ लग अफ्टर, लगबफर и त्रुटि व्यक्तिगत रूपमा पनि परिवर्तन गर्न सकिन्छ, र, अघिल्लो चरणहरूसँग समानता गरेर, तीन वर्गहरू सिर्जना गर्नेछ: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

र पिउनेको लागि त्यहाँ तीनवटा अपरेशनहरू छन् भनेर सम्झँदा, हामीले नौवटा लगिङ कक्षाहरू पाउँछौं। नतिजाको रूपमा, सम्पूर्ण पेय सर्कलमा 14 (!!!) कक्षाहरू हुन्छन्।

हाइपरबोला? मुश्किलले! डिकम्पोजिसन ग्रेनेड भएको बाँदरले डिक्यान्टर, गिलास, पोयरिङ अपरेटरहरू, पानी आपूर्ति सेवा, अणुहरूको टक्करको भौतिक मोडेलमा "पोरर" विभाजित गर्नेछ, र अर्को क्वार्टरको लागि उसले बिना निर्भरताहरू हटाउने प्रयास गर्नेछ। वैश्विक चर। र मलाई विश्वास गर्नुहोस्, ऊ रोकिनेछैन।

यस बिन्दुमा धेरैले निष्कर्षमा पुग्छन् कि SRP गुलाबी राज्यहरूका परी कथाहरू हुन्, र चाउचाउ खेल्न टाढा जान्छन् ...

... Srp को तेस्रो परिभाषाको अस्तित्वको बारेमा कहिल्यै नजानेको:

"एकल उत्तरदायित्व सिद्धान्तले बताउँछ परिवर्तनसँग मिल्दोजुल्दो चीजहरू एकै ठाउँमा भण्डार गर्नुपर्छ"। वा "के परिवर्तनहरू एकै ठाउँमा राख्नुपर्छ"

त्यो हो, यदि हामीले अपरेशनको लगिङ परिवर्तन गर्छौं भने, हामीले यसलाई एकै ठाउँमा परिवर्तन गर्नुपर्छ।

यो एक धेरै महत्त्वपूर्ण बिन्दु हो - किनकि माथिका SRP को सबै व्याख्याहरूले भनिएको छ कि प्रकारहरू कुचल्दा कुच्नु आवश्यक छ, अर्थात्, तिनीहरूले वस्तुको आकारमा "माथिल्लो सीमा" लगाए, र अब। हामी पहिले नै "तल्लो सीमा" को बारेमा कुरा गर्दैछौं। अर्को शब्दमा, SRP लाई "क्रसिंग गर्दा क्रसिङ" मात्र चाहिन्छ, तर यसलाई अति गर्न पनि हुँदैन - "इन्टरलकिङ चीजहरू क्रश नगर्नुहोस्"। यो Occam को रेजर र एप म्यान बीचको ठूलो युद्ध हो!

अब पिउनेले राम्रो महसुस गर्नुपर्छ। यस तथ्यको अतिरिक्त कि त्यहाँ IPourLogger लगरलाई तीन वर्गहरूमा विभाजन गर्न आवश्यक छैन, हामी सबै लगरहरूलाई एक प्रकारमा जोड्न सक्छौं:

class OperationLogger{
    public OperationLogger(string operationName){/*..*/}
    public void LogBefore(object[] args){/*...*/}       
    public void LogAfter(object[] args){/*..*/}
    public void LogError(object[] args, exception e){/*..*/}
}

र यदि हामीले चौथो प्रकारको अपरेशन थप्यौं भने, यसको लागि लगिङ पहिले नै तयार छ। र सञ्चालनको कोड आफैं सफा र पूर्वाधार शोर मुक्त छ।

नतिजाको रूपमा, हामीसँग पेय समस्या समाधान गर्न 5 कक्षाहरू छन्:

• खन्याउने कार्य
• पिउने अपरेशन
• जामिङ अपरेशन
• लगर
• पिउने मुखौटा

तिनीहरूमध्ये प्रत्येक एक प्रकार्यको लागि सख्त रूपमा जिम्मेवार छ र परिवर्तनको लागि एक कारण छ। परिवर्तन जस्तै सबै नियमहरू नजिकै अवस्थित छन्।

वास्तविक जीवन उदाहरण

हामीले एक पटक स्वचालित रूपमा b2b ग्राहक दर्ताको लागि सेवा लेख्यौं। र समान सामग्रीको 200 लाइनहरूको लागि भगवान विधि देखा पर्‍यो:

• 1C मा जानुहोस् र एउटा खाता सिर्जना गर्नुहोस्
• यस खाताको साथ, भुक्तानी मोड्युलमा जानुहोस् र त्यहाँ सिर्जना गर्नुहोस्
• जाँच गर्नुहोस् कि यस्तो खाता भएको खाता मुख्य सर्भरमा सिर्जना गरिएको छैन
• नयाँ खाता खोल्नुहोस्
• दर्ता परिणामहरू भुक्तानी मोड्युलमा र 1c नम्बर दर्ता परिणाम सेवामा थप्नुहोस्
• यस तालिकामा खाता जानकारी थप्नुहोस्
• बिन्दु सेवामा यो ग्राहकको लागि बिन्दु नम्बर सिर्जना गर्नुहोस्। यस सेवामा आफ्नो 1c खाता नम्बर पास गर्नुहोस्।

र यस सूचीमा डरलाग्दो जडानको साथ लगभग 10 थप व्यवसाय सञ्चालनहरू थिए। लगभग सबैलाई खाता वस्तु चाहिन्छ। आधा कलहरूमा बिन्दु ID र ग्राहकको नाम आवश्यक थियो।

रिफ्याक्टरिङको एक घण्टा पछि, हामीले पूर्वाधार कोड र खातासँग काम गर्ने केही बारीकताहरूलाई छुट्टाछुट्टै विधि/वर्गहरूमा अलग गर्न सक्षम भयौं। भगवान विधिले यसलाई सजिलो बनायो, तर त्यहाँ कोडका 100 लाइनहरू बाँकी थिए जसलाई बेवास्ता गर्न चाहँदैनन्।

केहि दिन पछि यो स्पष्ट भयो कि यो "हल्का" विधि को सार एक व्यापार एल्गोरिथ्म हो। र प्राविधिक विशिष्टताहरूको मूल विवरण एकदम जटिल थियो। र यो यस विधिलाई टुक्रामा टुक्रा पार्ने प्रयास हो जसले SRP उल्लङ्घन गर्नेछ, न कि उल्टो।

औपचारिकता।

यो हाम्रो मादक पदार्थ एक्लै छोड्ने समय हो। आफ्नो आँसु सुकाउनुहोस् - हामी पक्कै एक दिन यसमा फर्कनेछौं। अब यस लेखबाट ज्ञानलाई औपचारिक गरौं।

औपचारिकता 1. SRP को परिभाषा

1. तत्वहरू अलग गर्नुहोस् ताकि तिनीहरू प्रत्येक एक चीजको लागि जिम्मेवार छन्।
2. जिम्मेवारी भनेको "परिवर्तनको कारण" हो। त्यो हो, प्रत्येक तत्वसँग व्यापार तर्कको सन्दर्भमा परिवर्तनको लागि मात्र एक कारण छ।
3. व्यापार तर्कमा सम्भावित परिवर्तनहरू। स्थानीयकरण हुनुपर्छ। सिंक्रोनस रूपमा परिवर्तन गर्ने तत्वहरू नजिकै हुनुपर्छ।

औपचारिकता 2. आवश्यक आत्म-परीक्षण मापदण्ड।

मैले एसआरपी पूरा गर्नका लागि पर्याप्त मापदण्ड देखेको छैन। तर त्यहाँ आवश्यक सर्तहरू छन्:

१) आफैलाई सोध्नुहोस् कि यो कक्षा/विधि/मोड्युल/सेवाले के गर्छ। तपाईंले यसलाई सरल परिभाषाको साथ जवाफ दिनुपर्छ। ( धन्यवाद ब्राइटोरी )

स्पष्टीकरणहरू

यद्यपि, कहिलेकाहीँ यो एक सरल परिभाषा फेला पार्न धेरै गाह्रो छ

2) बग फिक्स गर्न वा नयाँ सुविधा थप्दा फाइल/वर्गहरूको न्यूनतम संख्यालाई असर गर्छ। आदर्श - एक।

स्पष्टीकरणहरू

जिम्मेवारी (एक सुविधा वा बगको लागि) एक फाइल/वर्गमा समेटिएको हुनाले, तपाईलाई थाहा छ कहाँ हेर्ने र के सम्पादन गर्ने। उदाहरणका लागि: लगिङ अपरेसनहरूको आउटपुट परिवर्तन गर्ने सुविधाले लगर मात्र परिवर्तन गर्न आवश्यक छ। बाँकी कोड मार्फत चलाउन आवश्यक छैन।

अर्को उदाहरण अघिल्लो जस्तै नयाँ UI नियन्त्रण थप्दै छ। यदि यसले तपाइँलाई 10 फरक संस्थाहरू र 15 फरक कन्भर्टरहरू थप्न बाध्य पार्छ भने, तपाइँ यसलाई धेरै गरिरहनुभएको जस्तो देखिन्छ।

3) यदि धेरै विकासकर्ताहरूले तपाईंको परियोजनाका विभिन्न सुविधाहरूमा काम गरिरहेका छन् भने, मर्ज द्वन्द्वको सम्भावना, अर्थात्, एउटै फाइल/वर्ग एकै समयमा धेरै विकासकर्ताहरूले परिवर्तन गर्ने सम्भावना न्यून छ।

स्पष्टीकरणहरू

यदि, नयाँ अपरेशन "टेबल मुनि भोडका खन्याउ" थप्दा, तपाईंले लगर, पिउने र खन्याउने कार्यलाई असर गर्न आवश्यक छ, त्यसपछि जिम्मेवारीहरू बाङ्गो रूपमा विभाजित गरिएको जस्तो देखिन्छ। निस्सन्देह, यो सधैं सम्भव छैन, तर हामीले यो संख्या घटाउने प्रयास गर्नुपर्छ।

4) व्यापार तर्क (विकासकर्ता वा प्रबन्धकबाट) को बारे मा स्पष्ट प्रश्न सोध्दा, तपाईं कडाईका साथ एक वर्ग / फाइल मा जानुहोस् र त्यहाँबाट मात्र जानकारी प्राप्त गर्नुहोस्।

स्पष्टीकरणहरू

विशेषताहरू, नियमहरू वा एल्गोरिदमहरू कम्प्याक्ट रूपमा लेखिएका छन्, प्रत्येक एक ठाउँमा, र कोड स्पेसमा झण्डाहरूसँग छरिएका छैनन्।

5) नामकरण स्पष्ट छ।

स्पष्टीकरणहरू

हाम्रो वर्ग वा विधि एउटा कुराको लागि जिम्मेवार छ, र जिम्मेवारी यसको नाममा प्रतिबिम्बित हुन्छ

AllManagersManagerService - सम्भवतः भगवान वर्ग
स्थानीय भुक्तानी - सायद छैन

औपचारिकता 3. Occam-पहिलो विकास पद्धति।

डिजाइनको सुरुमा, बाँदर मानिसलाई थाहा छैन र समस्या समाधान हुने सबै सूक्ष्मताहरू महसुस गर्दैन र गल्ती गर्न सक्छ। तपाईं विभिन्न तरिकामा गल्ती गर्न सक्नुहुन्छ:

• विभिन्न जिम्मेवारीहरू मर्ज गरेर वस्तुहरूलाई धेरै ठूलो बनाउनुहोस्
• एउटै जिम्मेवारीलाई विभिन्न प्रकारमा विभाजन गरेर रिफ्रेमिङ
• गलत रूपमा जिम्मेवारीको सीमा परिभाषित गर्नुहोस्

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

यो एक दिन कल गर्ने समय हो

SRP को दायरा OOP र SOLID मा सीमित छैन। यो विधिहरू, कार्यहरू, कक्षाहरू, मोड्युलहरू, माइक्रोसेवाहरू र सेवाहरूमा लागू हुन्छ। यो "figax-figax-and-prod" र "रकेट-विज्ञान" विकास दुवैमा लागू हुन्छ, जसले संसारलाई जताततै राम्रो बनाउँछ। यदि तपाइँ यसको बारेमा सोच्नुहुन्छ भने, यो लगभग सबै इन्जिनियरिङको आधारभूत सिद्धान्त हो। मेकानिकल ईन्जिनियरिङ्, नियन्त्रण प्रणालीहरू, र वास्तवमा सबै जटिल प्रणालीहरू कम्पोनेन्टहरूबाट बनेका हुन्छन्, र "अन्डरफ्रेग्मेन्टेसन" ले डिजाइनरहरूलाई लचिलोपनबाट वञ्चित गर्दछ, "ओभरफ्रेग्मेन्टेसन" ले डिजाइनरहरूलाई दक्षताबाट वञ्चित गर्दछ, र गलत सीमाहरूले उनीहरूलाई कारण र मानसिक शान्तिबाट वञ्चित गर्दछ।

SRP प्रकृति द्वारा आविष्कार गरिएको छैन र सही विज्ञान को भाग छैन। यसले हाम्रो जैविक र मनोवैज्ञानिक सीमितताहरूबाट बाहिर निस्कन्छ। यो एप-म्यान मस्तिष्क प्रयोग गरेर जटिल प्रणालीहरू नियन्त्रण र विकास गर्ने तरिका मात्र हो। उसले प्रणालीलाई कसरी विघटन गर्ने भनेर बताउँछ। मूल ढाँचाको लागि टेलिपाथीको उचित मात्रा चाहिन्छ, तर मलाई आशा छ कि यो लेखले केही धुम्रपान स्क्रिन खाली गर्दछ।

स्रोत: www.habr.com