एकल उत्तरदायित्व सिद्धांत. यह उतना सरल नहीं है जितना लगता है

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

इस सिद्धांत के साथ मेरा पहला गंभीर परिचय पहले वर्ष की शुरुआत में हुआ, जब युवा और हरे लोगों को लार्वा से वास्तविक छात्र बनाने के लिए जंगल में ले जाया गया।

जंगल में, हमें 8-9 लोगों के समूह में विभाजित किया गया था और एक प्रतियोगिता हुई थी - कौन सा समूह सबसे तेज़ वोदका की एक बोतल पीएगा, बशर्ते कि समूह का पहला व्यक्ति एक गिलास में वोदका डाले, दूसरा उसे पिए, और तीसरे के पास नाश्ता है। जिस इकाई ने अपना कार्य पूरा कर लिया है वह समूह की कतार के अंत में चली जाती है।

वह मामला जहां कतार का आकार तीन का गुणज था, एसआरपी का एक अच्छा कार्यान्वयन था।

परिभाषा 1. एकल जिम्मेदारी.

एकल उत्तरदायित्व सिद्धांत (एसआरपी) की आधिकारिक परिभाषा में कहा गया है कि प्रत्येक इकाई की अपनी जिम्मेदारी और अस्तित्व का कारण है, और इसकी केवल एक ही जिम्मेदारी है।

वस्तु "पीने ​​वाला" पर विचार करें (पियक्कड़).
एसआरपी सिद्धांत को लागू करने के लिए, हम जिम्मेदारियों को तीन में विभाजित करेंगे:

• एक डालता है (डालोऑपरेशन)
• एक पीता है (ड्रिंकअपऑपरेशन)
• एक के पास नाश्ता है (टेकबाइटऑपरेशन)

प्रक्रिया में भाग लेने वालों में से प्रत्येक प्रक्रिया के एक घटक के लिए जिम्मेदार है, अर्थात, उसकी एक परमाणु जिम्मेदारी है - पीना, डालना या नाश्ता करना।

पीने का गड्ढा, बदले में, इन कार्यों के लिए एक मुखौटा है:

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

क्यों?

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

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

इसलिए, मानव प्रोग्रामर जटिल तंत्रों को कम जटिल और कार्यशील तत्वों के एक सेट में विघटित करते हैं। हालाँकि, इसे अलग-अलग तरीकों से विघटित किया जा सकता है: कई पुरानी कारों में, वायु वाहिनी दरवाजे में जाती है, और आधुनिक कारों में, लॉक इलेक्ट्रॉनिक्स में खराबी इंजन को शुरू होने से रोकती है, जो मरम्मत के दौरान एक समस्या हो सकती है।

अब, एसआरपी एक सिद्धांत है जो बताता है कि कैसे विघटित होना है, यानी विभाजन रेखा कहां खींचनी है.

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

आइए शराब पीने और अपघटन के दौरान मंकी मैन को मिलने वाले फायदों पर लौटते हैं:

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

(ओह, ऐसा लगता है कि यह पहले से ही एक ओसीपी सिद्धांत है, और मैंने इस पोस्ट की ज़िम्मेदारी का उल्लंघन किया है)

और, ज़ाहिर है, विपक्ष:

• हमें और प्रकार बनाने होंगे.
• एक शराबी पहली बार कुछ घंटे देर से शराब पीता है, अन्यथा नहीं पीता।

परिभाषा 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);
    }
   }
}

ये दोनों वर्ग, एक बाहरी पर्यवेक्षक के दृष्टिकोण से, बिल्कुल एक जैसे दिखते हैं और "पीने" की समान जिम्मेदारी साझा करते हैं।

भ्रम!

फिर हम ऑनलाइन जाते हैं और एसआरपी की एक और परिभाषा - एकल परिवर्तनशीलता सिद्धांत - का पता लगाते हैं।

एससीपी का कहना है कि "एक मॉड्यूल में बदलाव का एक और केवल एक ही कारण होता है". अर्थात्, “जिम्मेदारी ही परिवर्तन का कारण है।”

(ऐसा लगता है कि जो लोग मूल परिभाषा के साथ आए थे वे वानर मानव की टेलीपैथिक क्षमताओं में आश्वस्त थे)

अब सब कुछ ठीक हो गया है। अलग-अलग, हम डालने, पीने और स्नैकिंग प्रक्रियाओं को बदल सकते हैं, लेकिन ड्रिंकर में हम केवल संचालन के अनुक्रम और संरचना को बदल सकते हैं, उदाहरण के लिए, पीने से पहले स्नैक को स्थानांतरित करके या टोस्ट की रीडिंग जोड़कर।

"फॉरवर्ड एंड ओनली फॉरवर्ड" दृष्टिकोण में, जो कुछ भी बदला जा सकता है वह केवल विधि में बदला जाता है अधिनियम. यह पठनीय और प्रभावी हो सकता है जब इसमें थोड़ा तर्क हो और यह शायद ही कभी बदलता है, लेकिन अक्सर यह 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}");
    }
}

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

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)
        }
    }
}

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

और यह याद रखते हुए कि एक शराब पीने वाले के लिए तीन ऑपरेशन होते हैं, हमें नौ लॉगिंग कक्षाएं मिलती हैं। परिणामस्वरूप, संपूर्ण पेय मंडली में 14 (!!!) वर्ग शामिल हैं।

अतिपरवलय? मुश्किल से! अपघटन ग्रेनेड के साथ एक बंदर आदमी "डालने वाले" को एक डिकैन्टर, एक गिलास, डालने वाले ऑपरेटर, एक जल आपूर्ति सेवा, अणुओं की टक्कर का एक भौतिक मॉडल में विभाजित करेगा, और अगली तिमाही के लिए वह बिना निर्भरता को सुलझाने की कोशिश करेगा सार्वत्रिक चर। और मेरा विश्वास करो, वह नहीं रुकेगा।

इस बिंदु पर कई लोग इस निष्कर्ष पर पहुंचते हैं कि एसआरपी गुलाबी साम्राज्यों की परीकथाएं हैं, और नूडल्स खेलने चले जाते हैं...

... 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 विधि सामने आई:

• 1सी पर जाएं और एक अकाउंट बनाएं
• इस खाते से भुगतान मॉड्यूल पर जाएं और वहां इसे बनाएं
• जांचें कि मुख्य सर्वर पर ऐसे खाते वाला कोई खाता तो नहीं बनाया गया है
• एक नया खाता बनाएं
• भुगतान मॉड्यूल में पंजीकरण परिणाम और पंजीकरण परिणाम सेवा में 1सी नंबर जोड़ें
• इस तालिका में खाता जानकारी जोड़ें
• पॉइंट सेवा में इस क्लाइंट के लिए एक पॉइंट नंबर बनाएं। इस सेवा को अपना 1सी खाता नंबर भेजें।

और इस सूची में भयानक कनेक्टिविटी वाले लगभग 10 और व्यावसायिक संचालन थे। लगभग सभी को अकाउंट ऑब्जेक्ट की आवश्यकता थी। आधे कॉलों में पॉइंट आईडी और क्लाइंट नाम की आवश्यकता थी।

एक घंटे की रीफैक्टरिंग के बाद, हम इन्फ्रास्ट्रक्चर कोड और खाते के साथ काम करने की कुछ बारीकियों को अलग-अलग तरीकों/वर्गों में अलग करने में सक्षम हुए। गॉड मेथड ने इसे आसान बना दिया, लेकिन कोड की 100 पंक्तियाँ बची थीं जो सुलझना नहीं चाहती थीं।

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

रीतिवाद।

अब समय आ गया है कि हम अपने शराबी को अकेला छोड़ दें। अपने आँसू सुखाओ - हम निश्चित रूप से किसी दिन इस पर लौटेंगे। आइए अब इस लेख से प्राप्त ज्ञान को औपचारिक रूप दें।

औपचारिकता 1. एसआरपी की परिभाषा

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

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

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

1) अपने आप से पूछें कि यह कक्षा/विधि/मॉड्यूल/सेवा क्या करती है। आपको इसका उत्तर एक सरल परिभाषा के साथ देना होगा। ( धन्यवाद ब्राइटोरी )

स्पष्टीकरण

हालाँकि, कभी-कभी इसकी सरल परिभाषा ढूँढ़ना बहुत कठिन होता है

2) किसी बग को ठीक करने या कोई नई सुविधा जोड़ने से न्यूनतम संख्या में फ़ाइलें/कक्षाएँ प्रभावित होती हैं। आदर्श रूप से - एक.

स्पष्टीकरण

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

एक अन्य उदाहरण पिछले वाले के समान एक नया यूआई नियंत्रण जोड़ना है। यदि यह आपको 10 अलग-अलग इकाइयाँ और 15 अलग-अलग कन्वर्टर्स जोड़ने के लिए मजबूर करता है, तो ऐसा लगता है कि आप इसे ज़्यादा कर रहे हैं।

3) यदि कई डेवलपर आपके प्रोजेक्ट की विभिन्न विशेषताओं पर काम कर रहे हैं, तो मर्ज संघर्ष की संभावना, यानी, एक ही फ़ाइल/क्लास को एक ही समय में कई डेवलपर्स द्वारा बदले जाने की संभावना न्यूनतम है।

स्पष्टीकरण

यदि, एक नया ऑपरेशन "टेबल के नीचे वोदका डालो" जोड़ते समय, आपको लॉगर, पीने और डालने के संचालन को प्रभावित करने की आवश्यकता है, तो ऐसा लगता है कि जिम्मेदारियां टेढ़ी-मेढ़ी बांट दी गई हैं। बेशक, यह हमेशा संभव नहीं है, लेकिन हमें इस आंकड़े को कम करने का प्रयास करना चाहिए।

4) जब व्यावसायिक तर्क (डेवलपर या प्रबंधक से) के बारे में एक स्पष्ट प्रश्न पूछा जाता है, तो आप सख्ती से एक वर्ग/फ़ाइल में चले जाते हैं और केवल वहीं से जानकारी प्राप्त करते हैं।

स्पष्टीकरण

विशेषताएं, नियम या एल्गोरिदम को एक ही स्थान पर कॉम्पैक्ट रूप से लिखा जाता है, और पूरे कोड स्थान में झंडे के साथ बिखरे हुए नहीं होते हैं।

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

स्पष्टीकरण

हमारा वर्ग या पद्धति किसी एक चीज़ के लिए ज़िम्मेदार है, और ज़िम्मेदारी उसके नाम से झलकती है

AllManagersManagerService - संभवतः एक ईश्वर वर्ग
लोकलपेमेंट - शायद नहीं

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

डिज़ाइन की शुरुआत में, मंकी मैन हल की जा रही समस्या की सभी बारीकियों को नहीं जानता और महसूस नहीं करता है और गलती कर सकता है। आप विभिन्न तरीकों से गलतियाँ कर सकते हैं:

• विभिन्न जिम्मेदारियों को मिलाकर वस्तुओं को बहुत बड़ा बनाएं
• एक ही जिम्मेदारी को कई अलग-अलग प्रकारों में बांटकर पुनर्रचना करना
• जिम्मेदारी की सीमाओं को गलत तरीके से परिभाषित करना

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

अब इसे ख़त्म करने का समय आ गया है

SRP का दायरा OOP और SOLID तक सीमित नहीं है। यह विधियों, कार्यों, कक्षाओं, मॉड्यूल, माइक्रोसर्विसेज और सेवाओं पर लागू होता है। यह "फ़िगैक्स-फ़िगैक्स-एंड-प्रोड" और "रॉकेट-साइंस" विकास दोनों पर लागू होता है, जिससे दुनिया हर जगह थोड़ी बेहतर हो जाती है। यदि आप इसके बारे में सोचें, तो यह लगभग सभी इंजीनियरिंग का मूल सिद्धांत है। मैकेनिकल इंजीनियरिंग, नियंत्रण प्रणालियाँ, और वास्तव में सभी जटिल प्रणालियाँ घटकों से निर्मित होती हैं, और "अंडरफ्ग्मेंटेशन" डिजाइनरों को लचीलेपन से वंचित करता है, "अतिविखंडन" डिजाइनरों को दक्षता से वंचित करता है, और गलत सीमाएँ उन्हें कारण और मन की शांति से वंचित करती हैं।

एसआरपी का आविष्कार प्रकृति द्वारा नहीं किया गया है और यह सटीक विज्ञान का हिस्सा नहीं है। यह हमारी जैविक और मनोवैज्ञानिक सीमाओं को तोड़ता है। यह वानर-मानव मस्तिष्क का उपयोग करके जटिल प्रणालियों को नियंत्रित करने और विकसित करने का एक तरीका है। वह हमें बताता है कि किसी सिस्टम को कैसे विघटित किया जाए। मूल सूत्रीकरण के लिए उचित मात्रा में टेलीपैथी की आवश्यकता थी, लेकिन मुझे आशा है कि यह लेख कुछ अस्पष्टताओं को दूर कर देगा।

स्रोत: www.habr.com