एकल जबाबदारी तत्त्व. दिसते तितके सोपे नाही

एकल जबाबदारीचे तत्त्व, ज्याला एकल जबाबदारीचे तत्त्व असेही म्हणतात,
उर्फ ​​एकसमान परिवर्तनशीलतेचे तत्त्व - समजून घेण्यासाठी अत्यंत निसरडा माणूस आणि प्रोग्रामरच्या मुलाखतीत असा चिंताग्रस्त प्रश्न.

या तत्त्वाशी माझी पहिली गंभीर ओळख पहिल्या वर्षाच्या सुरुवातीला घडली, जेव्हा तरुण आणि हिरव्या मुलांना अळ्यांपासून विद्यार्थी बनवण्यासाठी जंगलात नेण्यात आले - वास्तविक विद्यार्थी.

जंगलात, आम्हाला प्रत्येकी 8-9 लोकांच्या गटांमध्ये विभागले गेले होते आणि एक स्पर्धा होती - कोणता गट सर्वात जलद व्होडकाची बाटली पिईल, बशर्ते की गटातील पहिल्या व्यक्तीने एका ग्लासमध्ये वोडका ओतला तर दुसरा प्याला, आणि तिसऱ्याला नाश्ता आहे. ज्या युनिटने त्याचे ऑपरेशन पूर्ण केले आहे ते गटाच्या रांगेच्या शेवटी जाते.

जेथे रांगेचा आकार तीनचा गुणाकार होता तो SRP ची चांगली अंमलबजावणी होती.

व्याख्या 1. एकल जबाबदारी.

सिंगल रिस्पॉन्सिबिलिटी प्रिन्सिपल (SRP) ची अधिकृत व्याख्या सांगते की प्रत्येक घटकाची स्वतःची जबाबदारी आणि अस्तित्वाचे कारण असते आणि तिची फक्त एक जबाबदारी असते.

"ड्रिंकर" या वस्तूचा विचार करा (टिप्लर).
SRP तत्त्वाची अंमलबजावणी करण्यासाठी, आम्ही जबाबदाऱ्यांची तीन भागात विभागणी करू:

• एक ओततो (पोरऑपरेशन)
• एक पेय (ड्रिंकअप ऑपरेशन)
• एक नाश्ता आहे (TakeBiteOperation)

प्रक्रियेतील प्रत्येक सहभागी प्रक्रियेच्या एका घटकासाठी जबाबदार आहे, म्हणजे, एक अणू जबाबदारी आहे - पिणे, ओतणे किंवा नाश्ता करणे.

ड्रिंकिंग होल, यामधून, या ऑपरेशन्ससाठी एक दर्शनी भाग आहे:

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

का?

मानवी प्रोग्रामर वानर-मनुष्यासाठी कोड लिहितो, आणि वानर-मनुष्य दुर्लक्षित, मूर्ख आणि नेहमी घाईत असतो. तो एका वेळी सुमारे 3 - 7 संज्ञा धारण करू शकतो आणि समजू शकतो.
मद्यपीच्या बाबतीत, यापैकी तीन संज्ञा आहेत. तथापि, जर आपण एका शीटने संहिता लिहिली तर त्यात हात, चष्मा, मारामारी आणि राजकारणाबद्दल अंतहीन वाद असतील. आणि हे सर्व एकाच पद्धतीच्या मुख्य भागामध्ये असेल. मला खात्री आहे की तुम्ही तुमच्या सरावात असा कोड पाहिला असेल. मानसासाठी सर्वात मानवी चाचणी नाही.

दुसरीकडे, वानर मनुष्य त्याच्या डोक्यात वास्तविक जगातील वस्तूंचे अनुकरण करण्यासाठी डिझाइन केलेले आहे. त्याच्या कल्पनेत, तो त्यांना एकत्र ढकलू शकतो, त्यांच्याकडून नवीन वस्तू एकत्र करू शकतो आणि त्याच प्रकारे वेगळे करू शकतो. जुन्या मॉडेलच्या कारची कल्पना करा. तुमच्या कल्पनेत तुम्ही दार उघडू शकता, दाराची ट्रिम काढू शकता आणि तेथे खिडकी उचलण्याची यंत्रणा पाहू शकता, ज्याच्या आत गीअर्स असतील. परंतु आपण एकाच वेळी मशीनचे सर्व घटक एका "सूची" मध्ये पाहू शकत नाही. किमान "माकड माणूस" करू शकत नाही.

म्हणून, मानवी प्रोग्रामर जटिल यंत्रणा कमी जटिल आणि कार्यरत घटकांच्या संचामध्ये विघटित करतात. तथापि, ते वेगवेगळ्या प्रकारे विघटित केले जाऊ शकते: बर्याच जुन्या कारमध्ये, हवा नलिका दारात जाते आणि आधुनिक कारमध्ये, लॉक इलेक्ट्रॉनिक्समधील बिघाड इंजिनला सुरू होण्यापासून प्रतिबंधित करते, जे दुरुस्तीदरम्यान समस्या असू शकते.

आता, SRP हे एक तत्व आहे जे विघटित कसे करायचे हे स्पष्ट करते, म्हणजेच विभाजक रेषा कुठे काढायची.

तो म्हणतो की "जबाबदारी" च्या विभाजनाच्या तत्त्वानुसार विघटन करणे आवश्यक आहे, म्हणजेच विशिष्ट वस्तूंच्या कार्यांनुसार.

चला मद्यपानाकडे परत जाऊया आणि कुजण्याच्या वेळी माकड माणसाला मिळणारे फायदे:

• संहिता प्रत्येक स्तरावर अत्यंत स्पष्ट झाली आहे
• कोड एकाच वेळी अनेक प्रोग्रामरद्वारे लिहिला जाऊ शकतो (प्रत्येक स्वतंत्र घटक लिहितो)
• स्वयंचलित चाचणी सरलीकृत आहे - घटक जितके सोपे तितके चाचणी करणे सोपे आहे
• कोडची रचना दिसते - आपण बदलू शकता ड्रिंकअप ऑपरेशन अशा ऑपरेशनसाठी ज्यामध्ये मद्यपी टेबलाखाली द्रव ओततो. किंवा ओतण्याचे ऑपरेशन एका ऑपरेशनने बदला ज्यामध्ये तुम्ही वाइन आणि पाणी किंवा वोडका आणि बिअर मिसळा. व्यवसायाच्या आवश्यकतांवर अवलंबून, आपण पद्धत कोडला स्पर्श न करता सर्वकाही करू शकता टिपलर.कायदा.
• या ऑपरेशन्समधून तुम्ही खादाड फोल्ड करू शकता (केवळ वापरून TakeBitOperation), मद्यपी (केवळ वापरणे ड्रिंकअप ऑपरेशन थेट बाटलीतून) आणि इतर अनेक व्यवसाय आवश्यकता पूर्ण करा.

(अरे, असे दिसते की हे आधीच एक ओसीपी तत्त्व आहे आणि मी या पोस्टच्या जबाबदारीचे उल्लंघन केले आहे)

आणि, अर्थातच, तोटे:

• आम्हाला आणखी प्रकार तयार करावे लागतील.
• मद्यपी प्रथमच मद्यपान करतो त्यापेक्षा काही तासांनंतर.

व्याख्या 2. युनिफाइड परिवर्तनशीलता.

मला परवानगी द्या, सज्जनांनो! मद्यपान करणाऱ्या वर्गाचीही एकच जबाबदारी असते - तो पितो! आणि सर्वसाधारणपणे, "जबाबदारी" हा शब्द एक अत्यंत अस्पष्ट संकल्पना आहे. कोणीतरी मानवतेच्या भवितव्यासाठी जबाबदार आहे, आणि कोणीतरी खांबावर उलटलेल्या पेंग्विनला वाढवण्यास जबाबदार आहे.

पिण्याच्या दोन अंमलबजावणीचा विचार करूया. वर नमूद केलेल्या पहिल्यामध्ये तीन वर्ग आहेत - ओतणे, पेय आणि नाश्ता.

दुसरा "फॉरवर्ड आणि ओन्ली फॉरवर्ड" पद्धतीद्वारे लिहिलेला आहे आणि त्या पद्धतीतील सर्व तर्कशास्त्र समाविष्ट आहे. कायदा:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
с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 ची दुसरी व्याख्या शोधतो - एकल परिवर्तनशीलता तत्त्व.

एससीपी म्हणते की "मॉड्यूलमध्ये बदल करण्याचे एकच कारण असते" म्हणजे, "जबाबदारी हे बदलाचे कारण आहे."

(असे दिसते की मूळ व्याख्येसह आलेल्या लोकांना वानर माणसाच्या टेलिपॅथिक क्षमतेवर विश्वास होता)

आता सर्वकाही जागेवर येते. स्वतंत्रपणे, आम्ही ओतणे, पिणे आणि स्नॅकिंग प्रक्रिया बदलू शकतो, परंतु मद्यपान करणार्‍यामध्ये आम्ही केवळ ऑपरेशन्सचा क्रम आणि रचना बदलू शकतो, उदाहरणार्थ, पिण्यापूर्वी स्नॅक हलवून किंवा टोस्टचे वाचन जोडून.

"फॉरवर्ड आणि ओन्ली फॉरवर्ड" दृष्टिकोनामध्ये, जे काही बदलले जाऊ शकते ते केवळ पद्धतीमध्ये बदलले जाते कायदा. हे वाचनीय आणि प्रभावी असू शकते जेव्हा थोडे तर्कशास्त्र असते आणि ते क्वचितच बदलते, परंतु बर्‍याचदा ते प्रत्येकी 500 ओळींच्या भयंकर पद्धतींमध्ये संपते, ज्यामध्ये रशियाला नाटोमध्ये सामील होण्यासाठी आवश्यकतेपेक्षा जास्त इफ-स्टेटमेंट असतात.

व्याख्या 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}");
    }
}

मध्ये encapsulating करून पोरऑपरेशन, आम्ही जबाबदारी आणि encapsulation च्या दृष्टिकोनातून शहाणपणाने वागलो, परंतु आता आम्ही परिवर्तनशीलतेच्या तत्त्वामध्ये गोंधळलो आहोत. ऑपरेशन व्यतिरिक्त, जे बदलू शकते, लॉगिंग देखील बदलण्यायोग्य बनते. ओतण्याच्या ऑपरेशनसाठी तुम्हाला वेगळे करावे लागेल आणि एक विशेष लॉगर तयार करावा लागेल:

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 ला फक्त "चिरताना क्रशिंग" आवश्यक नाही, तर ते जास्त करू नका - "इंटरलॉकिंग गोष्टींना क्रश करू नका". ओकॅमचा रेझर आणि वानर यांच्यातील ही मोठी लढाई आहे!

आता पिणाऱ्याला बरे वाटले पाहिजे. 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 ओळींसाठी एक GOD पद्धत दिसून आली:

• 1C वर जा आणि खाते तयार करा
• या खात्यासह, पेमेंट मॉड्यूलवर जा आणि ते तेथे तयार करा
• असे खाते असलेले खाते मुख्य सर्व्हरवर तयार झाले नसल्याचे तपासा
• नवीन खाते तयार करा
• नोंदणी परिणाम पेमेंट मॉड्यूलमध्ये आणि 1c क्रमांक नोंदणी परिणाम सेवेमध्ये जोडा
• या टेबलमध्ये खाते माहिती जोडा
• पॉइंट सेवेमध्ये या क्लायंटसाठी पॉइंट नंबर तयार करा. तुमचा 1c खाते क्रमांक या सेवेला द्या.

आणि या यादीत भयानक कनेक्टिव्हिटीसह सुमारे 10 अधिक व्यवसाय ऑपरेशन होते. जवळजवळ प्रत्येकाला खाते ऑब्जेक्टची आवश्यकता होती. अर्ध्या कॉलमध्ये पॉइंट आयडी आणि क्लायंटचे नाव आवश्यक होते.

एका तासाच्या रिफॅक्टरिंगनंतर, आम्ही इन्फ्रास्ट्रक्चर कोड आणि खात्यासह काम करण्याच्या काही बारकावे वेगळ्या पद्धती/वर्गांमध्ये वेगळे करू शकलो. देव पद्धतीने ते सोपे केले, परंतु कोडच्या 100 ओळी उरल्या होत्या ज्या फक्त उलगडू इच्छित नाहीत.

काही दिवसांनंतरच हे स्पष्ट झाले की या "हलके" पद्धतीचे सार एक व्यवसाय अल्गोरिदम आहे. आणि तांत्रिक वैशिष्ट्यांचे मूळ वर्णन खूपच गुंतागुंतीचे होते. आणि या पद्धतीचे तुकडे करण्याचा प्रयत्न आहे ज्यामुळे SRP चे उल्लंघन होईल, उलट नाही.

औपचारिकता.

आमच्या नशेत एकटे सोडण्याची वेळ आली आहे. आपले अश्रू कोरडे करा - आम्ही नक्कीच त्याकडे परत येऊ. आता या लेखातील ज्ञानाची औपचारिकता करूया.

औपचारिकता 1. SRP ची व्याख्या

1. घटक वेगळे करा जेणेकरून त्यातील प्रत्येक एका गोष्टीसाठी जबाबदार असेल.
2. जबाबदारी म्हणजे “बदलण्याचे कारण”. म्हणजेच, प्रत्येक घटकाकडे बदलाचे एकच कारण आहे, व्यवसायाच्या तर्कशास्त्राच्या दृष्टीने.
3. व्यावसायिक तर्कामध्ये संभाव्य बदल. स्थानिकीकरण करणे आवश्यक आहे. समकालिकपणे बदलणारे घटक जवळपास असले पाहिजेत.

औपचारिकता 2. आवश्यक स्व-चाचणी निकष.

SRP ची पूर्तता करण्यासाठी मला पुरेसे निकष दिसले नाहीत. परंतु आवश्यक अटी आहेत:

1) हा वर्ग/पद्धत/मॉड्युल/सेवा काय करते हे स्वतःला विचारा. तुम्ही याचे उत्तर सोप्या व्याख्येसह दिले पाहिजे. ( धन्यवाद ब्राइटोरी )

स्पष्टीकरण

तथापि, कधीकधी एक साधी व्याख्या शोधणे फार कठीण असते

2) बगचे निराकरण करणे किंवा नवीन वैशिष्ट्य जोडणे फायली/वर्गांच्या किमान संख्येवर परिणाम करते. आदर्शपणे - एक.

स्पष्टीकरण

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

दुसरे उदाहरण म्हणजे मागील प्रमाणेच नवीन UI नियंत्रण जोडणे. हे तुम्हाला 10 भिन्न संस्था आणि 15 भिन्न कन्व्हर्टर जोडण्यास भाग पाडत असल्यास, असे दिसते की तुम्ही ते जास्त करत आहात.

3) जर अनेक विकासक तुमच्या प्रकल्पाच्या विविध वैशिष्ट्यांवर काम करत असतील, तर विलीनीकरणाच्या संघर्षाची शक्यता, म्हणजेच एकाच वेळी अनेक विकासकांकडून समान फाइल/वर्ग बदलण्याची शक्यता कमी आहे.

स्पष्टीकरण

जर, नवीन ऑपरेशन "टेबलखाली व्होडका घाला" जोडताना, आपल्याला लॉगरवर, पिण्याच्या आणि ओतण्याच्या ऑपरेशनवर परिणाम करणे आवश्यक आहे, तर असे दिसते की जबाबदाऱ्या कुटिलपणे विभागल्या गेल्या आहेत. अर्थात, हे नेहमीच शक्य नसते, परंतु आपण हा आकडा कमी करण्याचा प्रयत्न केला पाहिजे.

4) व्यवसायाच्या तर्काबद्दल (विकासक किंवा व्यवस्थापकाकडून) स्पष्टीकरण देणारा प्रश्न विचारला असता, तुम्ही एका वर्ग/फाइलमध्ये काटेकोरपणे जा आणि तिथूनच माहिती मिळवता.

स्पष्टीकरण

वैशिष्ट्ये, नियम किंवा अल्गोरिदम कॉम्पॅक्टपणे लिहिलेले आहेत, प्रत्येक एकाच ठिकाणी, आणि संपूर्ण कोड स्पेसमध्ये ध्वजांसह विखुरलेले नाहीत.

5) नामकरण स्पष्ट आहे.

स्पष्टीकरण

आमचा वर्ग किंवा पद्धत एका गोष्टीसाठी जबाबदार आहे आणि जबाबदारी तिच्या नावावर दिसून येते

AllManagersManagerService - बहुधा देव वर्ग
स्थानिक पेमेंट - कदाचित नाही

औपचारिकता 3. ऑकॅम-प्रथम विकास पद्धत.

डिझाईनच्या सुरूवातीस, माकड माणसाला समस्येचे निराकरण करण्याच्या सर्व सूक्ष्मता माहित नाहीत आणि वाटत नाहीत आणि तो चूक करू शकतो. आपण वेगवेगळ्या प्रकारे चुका करू शकता:

• वेगवेगळ्या जबाबदाऱ्या विलीन करून वस्तू खूप मोठ्या करा
• एकाच जबाबदारीला अनेक प्रकारांमध्ये विभागून रिफ्रेमिंग
• जबाबदारीच्या सीमा चुकीच्या पद्धतीने परिभाषित करा

नियम लक्षात ठेवणे महत्त्वाचे आहे: "एक मोठी चूक करणे चांगले आहे," किंवा "तुम्हाला खात्री नसल्यास, ते विभाजित करू नका." जर, उदाहरणार्थ, तुमच्या वर्गात दोन जबाबदाऱ्या असतील, तर ते अजूनही समजण्यासारखे आहे आणि क्लायंट कोडमध्ये कमीतकमी बदल करून दोन भागांमध्ये विभागले जाऊ शकते. काचेच्या तुकड्यांमधून ग्लास एकत्र करणे सहसा अधिक कठीण असते कारण संदर्भ अनेक फाईल्समध्ये पसरलेला असतो आणि क्लायंट कोडमध्ये आवश्यक अवलंबन नसल्यामुळे.

त्याला एक दिवस म्हणण्याची वेळ आली आहे

SRP ची व्याप्ती OOP आणि SOLID पुरती मर्यादित नाही. हे पद्धती, कार्ये, वर्ग, मॉड्यूल, मायक्रोसेवा आणि सेवांना लागू होते. हे "फिगॅक्स-फिगॅक्स-आणि-प्रॉड" आणि "रॉकेट-विज्ञान" विकास दोन्हीवर लागू होते, ज्यामुळे जग सर्वत्र थोडे चांगले बनते. आपण याबद्दल विचार केल्यास, हे जवळजवळ सर्व अभियांत्रिकीचे मूलभूत तत्त्व आहे. यांत्रिक अभियांत्रिकी, नियंत्रण प्रणाली आणि खरंच सर्व जटिल प्रणाली घटकांपासून बनविल्या जातात आणि "अंडरफ्रॅगमेंटेशन" डिझाइनरला लवचिकतेपासून वंचित ठेवते, "ओव्हरफ्रॅगमेंटेशन" डिझाइनर्सच्या कार्यक्षमतेपासून वंचित ठेवते आणि चुकीच्या सीमा त्यांना कारण आणि मनःशांतीपासून वंचित ठेवतात.

SRP निसर्गाने शोधलेला नाही आणि अचूक विज्ञानाचा भाग नाही. हे आपल्या जैविक आणि मानसिक मर्यादांमधून बाहेर पडते. वानर-मनुष्याच्या मेंदूचा वापर करून जटिल प्रणाली नियंत्रित आणि विकसित करण्याचा हा एक मार्ग आहे. प्रणालीचे विघटन कसे करायचे ते तो सांगतो. मूळ फॉर्म्युलेशनसाठी मोठ्या प्रमाणात टेलिपॅथी आवश्यक होती, परंतु मला आशा आहे की हा लेख काही स्मोक्सस्क्रीन साफ ​​करेल.

स्त्रोत: www.habr.com