اڪيلو ذميواري اصول. ايترو سادو ناهي جيترو اهو لڳي ٿو

اڪيلو ذميواري اصول، پڻ سڃاتو وڃي ٿو اڪيلو ذميواري جي اصول،
عرف يونيفارم جي تبديليءَ جو اصول - سمجھڻ لاءِ هڪ انتهائي پست ڇوڪرو ۽ پروگرامر جي انٽرويو ۾ اهڙو اعصابي سوال.

هن اصول سان منهنجي پهرين سنجيده واقفيت پهرين سال جي شروعات ۾ ٿي، جڏهن نوجوان ۽ سائي جهنگ ۾ شاگردن کي لاروا مان ڪڍڻ لاءِ وٺي ويا هئا يعني حقيقي شاگرد.

ٻيلي ۾، اسان کي 8-9 ماڻهن جي ٽولن ۾ ورهايو ويو هو ۽ هر هڪ ۾ مقابلو هو - ڪهڙو گروپ سڀ کان تيز ووڊڪا جي بوتل پيئندو، بشرطيڪ گروپ مان پهريون ماڻهو ووڊڪا کي گلاس ۾ وجهي، ٻيو ان کي پيئي، ۽ ٽئين وٽ ناشتو آهي. اهو يونٽ جيڪو پنهنجو آپريشن مڪمل ڪري چڪو آهي گروپ جي قطار جي آخر تائين هلندو آهي.

اهو ڪيس جتي قطار جي سائيز ٽن مان گھڻائي هئي SRP جو سٺو عمل هو.

وصف 1. اڪيلو ذميواري.

واحد ذميواري اصول (SRP) جي سرڪاري تعريف بيان ڪري ٿي ته هر اداري جي پنهنجي ذميواري ۽ وجود جو سبب آهي، ۽ ان جي صرف هڪ ذميواري آهي.

اعتراض تي غور ڪريو "پيئندڙ" (ٽپڙ).
SRP اصول کي لاڳو ڪرڻ لاء، اسان ذميوارين کي ٽن حصن ۾ ورهائينداسين:

• هڪ ڀريو (آپريشن)
• هڪ پيئڻ (پيئڻ جو آپريشن)
• ھڪڙو ناشتو آھي (ٽيڪ بائيٽ آپريشن)

عمل ۾ شرڪت ڪندڙن مان هر هڪ پروسيس جي هڪ جزو لاء ذميوار آهي، اهو آهي، هڪ ائٽمي ذميواري آهي - پيئڻ، وجھڻ يا ناشتو ڪرڻ.

پيئڻ جو سوراخ، موڙ ۾، انهن عملن لاء هڪ منهن آهي:

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

ڇو؟

انساني پروگرامر ايپي انسان لاءِ ڪوڊ لکندو آهي، ۽ بندر انسان بي پرواهه، بيوقوف ۽ هميشه جلدي ۾ هوندو آهي. هو هڪ وقت ۾ 3 - 7 اصطلاحن کي سمجهي ۽ سمجهي سگهي ٿو.
شرابي جي صورت ۾، انهن مان ٽي شرط آهن. تنهن هوندي به، جيڪڏهن اسان ڪوڊ کي هڪ ورق سان لکون ٿا، ته ان ۾ هٿ، چشمي، جنگ ۽ سياست بابت لامحدود دليل هوندا. ۽ اهو سڀ ڪجهه هڪ طريقي جي جسم ۾ ٿيندو. مون کي پڪ آهي ته توهان پنهنجي مشق ۾ اهڙو ڪوڊ ڏٺو هوندو. نفسيات لاء سڀ کان وڌيڪ انساني امتحان نه آهي.

ٻئي طرف، بندر انسان پنهنجي سر ۾ حقيقي دنيا جي شين کي تخليق ڪرڻ لاء ٺهيل آهي. هن جي تصور ۾، هو انهن کي گڏ ڪري سگهي ٿو، انهن مان نيون شيون گڏ ڪري سگهي ٿو، ۽ ساڳئي طريقي سان انهن کي جدا ڪري سگهي ٿو. تصور ڪريو هڪ پراڻي ماڊل ڪار. توهان جي تصور ۾، توهان دروازو کولي سگهو ٿا، دروازي جي ٽرم کي کوليو ۽ اتي ونڊو لفٽ ميڪانيزم ڏسي سگهو ٿا، جنهن جي اندر گيئر هوندا. پر توهان هڪ ئي وقت مشين جا سڀئي حصا نه ڏسي سگهو ٿا، هڪ "فهرست" ۾. گهٽ ۾ گهٽ ”بندر ماڻهو“ نٿو ڪري سگهي.

تنهن ڪري، انساني پروگرامر پيچيده ميڪانيزم کي گهٽ پيچيده ۽ ڪم ڪندڙ عناصر جي هڪ سيٽ ۾ ختم ڪري ٿو. بهرحال، اهو مختلف طريقن سان ختم ٿي سگهي ٿو: ڪيترن ئي پراڻين ڪارن ۾، هوائي ڊڪٽ دروازن ۾ وڃي ٿو، ۽ جديد ڪارن ۾، برقيات جي تالا ۾ ناڪامي انجڻ کي شروع ٿيڻ کان روڪي ٿو، جيڪو مرمت دوران مسئلو ٿي سگهي ٿو.

ائين، SRP هڪ اصول آهي جيڪو وضاحت ڪري ٿو ته ڪيئن ڊمپوز ڪجي، يعني ڪٿي ورهائڻ واري لڪير کي ڇڪيو وڃي.

هن جو چوڻ آهي ته اهو ضروري آهي ته "ذميواري" جي ورهاڱي جي اصول جي مطابق، يعني ڪجهه شين جي ڪمن جي مطابق.

اچو ته پيئڻ ڏانهن موٽيون ۽ اهي فائدا جيڪي بندر انسان کي سڙڻ دوران حاصل ڪري ٿو:

• ڪوڊ هر سطح تي انتهائي واضح ٿي چڪو آهي
• ڪوڊ هڪ ئي وقت ڪيترن ئي پروگرامرن طرفان لکي سگهجي ٿو (هر هڪ الڳ عنصر لکي ٿو)
• خودڪار ٽيسٽنگ کي آسان ڪيو ويو آهي - عنصر جيترو آسان، اهو جانچڻ آسان آهي
• ڪوڊ جي جوڙجڪ ظاهر ٿئي ٿي - توھان تبديل ڪري سگھو ٿا پيئڻ جو آپريشن هڪ آپريشن ۾ جنهن ۾ شرابي ميز جي هيٺان مائع وجهي ٿو. يا انجڻ واري آپريشن کي هڪ آپريشن سان تبديل ڪريو جنهن ۾ توهان شراب ۽ پاڻي يا ووڊڪا ۽ بيئر ملايو. ڪاروباري گهرجن تي مدار رکندي، توهان طريقي جي ڪوڊ کي ڇڪڻ کان سواء سڀ ڪجهه ڪري سگهو ٿا ٽوپيندڙ. ايڪٽ.
• انهن عملن مان توهان گلوٽن کي فولڊ ڪري سگهو ٿا (صرف استعمال ڪندي TakeBitOperation)، الڪوحل (صرف استعمال ڪندي پيئڻ جو آپريشن سڌو بوتل مان) ۽ ٻين ڪيترن ئي ڪاروباري گهرجن کي پورا ڪريو.

(او، اهو لڳي ٿو ته اهو اڳ ۾ ئي هڪ OCP اصول آهي، ۽ مون هن پوسٽ جي ذميواري جي ڀڃڪڙي ڪئي آهي)

۽، يقينا، نقصان:

• اسان کي وڌيڪ قسم ٺاهڻو پوندو.
• هڪ شرابي پهريون ڀيرو پيئندو آهي جيڪو ڪجهه ڪلاڪن کان پوءِ ٻي صورت ۾ پيئي ها.

وصف 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 جي ٻي تعريف ڳوليون ٿا - واحد تبديليءَ وارو اصول.

SCP چوي ٿو ته "هڪ ماڊل کي تبديل ڪرڻ لاء هڪ ۽ صرف هڪ سبب آهي". اهو آهي، "ذميواري تبديلي جو هڪ سبب آهي."

(اهو لڳي ٿو ته اهي ماڻهو جيڪي اصل تعريف سان آيا هئا، اهي بندر انسان جي ٽيليپيٿڪ صلاحيتن تي يقين رکندا هئا)

هاڻي هر شيء جاء تي پوي ٿو. الڳ الڳ، اسان پيئڻ، پيئڻ ۽ ناشتو ڪرڻ جي طريقيڪار کي تبديل ڪري سگھون ٿا، پر پاڻ پيئندڙ ۾ اسان صرف عملن جي ترتيب ۽ ترتيب کي تبديل ڪري سگھون ٿا، مثال طور، پيئڻ کان اڳ ناشتي کي منتقل ڪرڻ يا ٽوسٽ جي پڙھڻ کي شامل ڪندي.

"اڳتي ۽ صرف اڳتي" جي طريقي ۾، هر شيء جيڪا تبديل ٿي سگهي ٿي صرف طريقي سان تبديل ٿي ويندي آهي ايڪٽ. اهو پڙهي سگهجي ٿو ۽ اثرائتو ٿي سگهي ٿو جڏهن ٿورو منطق هجي ۽ اهو گهٽ ۾ گهٽ تبديل ٿئي ٿو، پر اڪثر اهو هر هڪ 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)
        }
    }
}

هوشيار پڙهندڙ ان کي نوٽيس ڪندو لاگ ان کانپوءِ, لاگ ان کان اڳ и غلطي تي انفرادي طور تي پڻ تبديل ڪري سگھجي ٿو، ۽، اڳئين قدمن سان قياس ڪندي، ٽي طبقا ٺاھيندو: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

۽ ياد رهي ته هڪ پيئندڙ لاء ٽي آپريشن آهن، اسان نو لاگنگ ڪلاس حاصل ڪندا آهيون. نتيجي طور، سڄي پيئڻ جو دائرو 14 (!!!) طبقن تي مشتمل آهي.

هائپربولا؟ مشڪل سان! هڪ بندر وارو ماڻهو جيڪو ڊمپوزيشن گرنيڊ سان گڏ ”پيئرر“ کي ڊيڪينٽر ۾ ورهائيندو، هڪ گلاس، ڀرڻ وارو آپريٽر، هڪ واٽر سپلائي سروس، ماليڪيولز جي ٽڪراءَ جو هڪ جسماني نمونو، ۽ ايندڙ ٽه ماهي لاءِ هو انحصار کي ختم ڪرڻ جي ڪوشش ڪندو. عالمي متغير. ۽ مون کي يقين رکو، هو روڪي نه سگهندو.

اهو هن نقطي تي آهي ته ڪيترائي ان نتيجي تي پهچندا آهن ته SRP گلابي بادشاهن کان افسانوي ڪهاڻيون آهن، ۽ نوڊلز کيڏڻ لاء پري ويندا آهن ...

... Srp جي ٽين تعريف جي وجود جي باري ۾ ڪڏهن به سکڻ کان سواء:

"اڪيلو ذميواري اصول ٻڌائي ٿو ته شيون جيڪي تبديلي سان ملندڙ جلندڙ آھن ھڪڙي جڳھ ۾ ذخيرو ٿيڻ گھرجي". يا "ڪهڙيون تبديليون گڏجي هڪ جاءِ تي رکڻ گهرجن"

اهو آهي، جيڪڏهن اسان هڪ آپريشن جي لاگنگ کي تبديل ڪندا آهيون، پوء اسان کي ان کي هڪ جاء تي تبديل ڪرڻ گهرجي.

هي هڪ تمام اهم نقطو آهي - ڇاڪاڻ ته مٿي ڄاڻايل SRP جي سڀني وضاحتن ۾ چيو ويو آهي ته اهو ضروري هو ته انهن قسمن کي کچلڻ دوران انهن کي ڪٽيو وڃي، اهو آهي، انهن اعتراض جي سائيز تي "مٿين حد" لاڳو ڪئي، ۽ هاڻي. اسان اڳ ۾ ئي "هيٺيون حد" بابت ڳالهائي رهيا آهيون. ٻين لفظن ۾، ايس آر پي کي نه رڳو ”ڪرشنگ دوران ڪرشنگ“ جي ضرورت آهي، پر ان کي وڌيڪ نه ڪرڻ جي ضرورت آهي - ”انٽرلاڪنگ شين کي نه ڪرش ڪريو“. هي آهي عظيم جنگ Occam جي ريزر ۽ Ape man جي وچ ۾!

هاڻي پيئڻ وارو بهتر محسوس ڪرڻ گهرجي. انهي حقيقت کان علاوه IPourLogger logger کي ٽن طبقن ۾ ورهائڻ جي ڪا ضرورت ناهي، اسان سڀني لاگرز کي هڪ قسم ۾ گڏ ڪري سگهون ٿا:

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. لازمي خود آزمائشي معيار.

SRP کي پورو ڪرڻ لاءِ مون ڪافي معيار نه ڏٺا آهن. پر اتي ضروري شرطون آهن:

1) پنهنجو پاڻ کان پڇو ته هي ڪلاس/طريقو/ماڊل/خدمت ڇا ڪندو آهي. توھان کي اھو جواب ڏيڻ گھرجي ھڪڙي سادي تعريف سان. ( تنهنجي مهرباني برائٽوري )

وضاحتون

بهرحال، ڪڏهن ڪڏهن اهو تمام ڏکيو آهي ته هڪ سادي تعريف ڳولڻ لاء

2) بگ کي درست ڪرڻ يا نئين خصوصيت شامل ڪرڻ سان گھٽ ۾ گھٽ فائلن/ڪلاسن جو تعداد متاثر ٿئي ٿو. مثالي - هڪ.

وضاحتون

جيئن ته ذميواري (هڪ فيچر يا بگ لاءِ) هڪ فائل/ڪلاس ۾ سمايل آهي، توهان کي خبر آهي ته ڪٿي ڏسڻو آهي ۽ ڪهڙي ترميم ڪرڻي آهي. مثال طور: لاگنگ عملن جي پيداوار کي تبديل ڪرڻ جي خصوصيت صرف لاگر کي تبديل ڪرڻ جي ضرورت پوندي. باقي ڪوڊ ذريعي هلائڻ جي ڪا ضرورت ناهي.

ٻيو مثال هڪ نئون UI ڪنٽرول شامل ڪري رهيو آهي، اڳئين وانگر. جيڪڏهن هي توهان کي 10 مختلف ادارن ۽ 15 مختلف ڪنورٽرز کي شامل ڪرڻ تي مجبور ڪري ٿو، اهو لڳي ٿو ته توهان ان کي وڌيڪ ڪري رهيا آهيو.

3) جيڪڏهن ڪيترائي ڊولپرز توهان جي پروجيڪٽ جي مختلف خاصيتن تي ڪم ڪري رهيا آهن، ته پوءِ ضم ٿيڻ جي تڪرار جو امڪان، اهو آهي ته، هڪ ئي وقت ڪيترن ئي ڊولپرز طرفان ساڳي فائل/ڪلاس کي تبديل ڪيو ويندو، گهٽ ۾ گهٽ آهي.

وضاحتون

جيڪڏهن، جڏهن هڪ نئون آپريشن شامل ڪيو ويو آهي "ٽيبل جي هيٺان ووڊڪا وجھو"، توهان کي لاگر کي متاثر ڪرڻ جي ضرورت آهي، پيئڻ ۽ وجھڻ جي آپريشن، پوء اهو لڳي ٿو ته ذميواريون ورهايل آهن. يقينا، اهو هميشه ممڪن ناهي، پر اسان کي هن انگ کي گهٽائڻ جي ڪوشش ڪرڻ گهرجي.

4) جڏهن ڪاروباري منطق جي باري ۾ هڪ واضح سوال پڇيو (هڪ ڊولپر يا مينيجر کان)، توهان سختي سان هڪ ڪلاس/فائل ۾ وڃو ۽ صرف اتان کان معلومات حاصل ڪريو.

وضاحتون

خاصيتون، ضابطا يا الگورٿم ٺھيل آھن، ھر ھڪ ھڪڙي جڳھ تي، ۽ ڪوڊ جي جڳھ ۾ جھنڊن سان ڀريل نه آھن.

5) نالو صاف آهي.

وضاحتون

اسان جو طبقو يا طريقو هڪ شيء لاء ذميوار آهي، ۽ ذميواري ان جي نالي ۾ ظاهر ٿئي ٿي

AllManagersManagerService - گهڻو ڪري هڪ خدا ڪلاس
مقامي ادائگي - شايد نه

فارملزم 3. اوڪيم-پهرين ترقي جو طريقو.

ڊزائن جي شروعات ۾، بندر انسان کي خبر ناهي ۽ محسوس نٿو ڪري ته مسئلي جي سڀني ذيلي ذخيري کي حل ڪيو وڃي ۽ غلطي ڪري سگهي ٿي. توهان مختلف طريقن سان غلطي ڪري سگهو ٿا:

• مختلف ذميدارين کي ضم ڪندي شين کي تمام وڏو ڪريو
• ھڪڙي ذميواري کي ڪيترن ئي مختلف قسمن ۾ ورهائڻ سان
• غلط طور تي ذميواري جي حدن جي وضاحت ڪريو

اهو قاعدو ياد رکڻ ضروري آهي: "اها وڏي غلطي ڪرڻ بهتر آهي،" يا "جيڪڏهن توهان پڪ نه آهيو، ان کي ورهايو نه." جيڪڏهن، مثال طور، توهان جي ڪلاس ۾ ٻه ذميواريون شامل آهن، پوء اهو اڃا تائين سمجهي سگهجي ٿو ۽ ڪلائنٽ ڪوڊ ۾ گهٽ ۾ گهٽ تبديلين سان ٻن حصن ۾ ورهائي سگهجي ٿو. شيشي جي ٽڪرن مان شيشي کي گڏ ڪرڻ عام طور تي وڌيڪ ڏکيو هوندو آهي ڇاڪاڻ ته تناظر ڪيترن ئي فائلن ۾ پکڙيل آهي ۽ ڪلائنٽ ڪوڊ ۾ ضروري انحصار جي کوٽ.

ان کي هڪ ڏينهن سڏڻ جو وقت آهي

SRP جو دائرو او او پي ۽ سولڊ تائين محدود ناهي. اهو لاڳو ٿئي ٿو طريقن، افعال، طبقن، ماڊلز، مائڪرو سروسز ۽ خدمتن تي. اهو ٻنهي تي لاڳو ٿئي ٿو "فيگاڪس-فيگاڪس-۽-پروڊ" ۽ "راڪيٽ-سائنس" ترقي، دنيا کي هر جڳهه ٿورو بهتر بڻائي ٿو. جيڪڏهن توهان ان جي باري ۾ سوچيو، اهو تقريبا سڀني انجنيئرنگ جو بنيادي اصول آهي. ميڪيڪل انجنيئرنگ، ڪنٽرول سسٽم، ۽ حقيقت ۾ سڀ پيچيده سسٽم اجزاء مان ٺهيل آهن، ۽ "انڊر فريگمينٽيشن" ڊيزائنرز کي لچڪ کان محروم ڪري ٿو، "اوور فريگمينٽيشن" ڊيزائنرز کي ڪارڪردگي کان محروم ڪري ٿو، ۽ غلط حدون انهن کي عقل ۽ ذهن جي امن کان محروم ڪري ٿو.

SRP فطرت طرفان ايجاد نه ڪئي وئي آهي ۽ صحيح سائنس جو حصو ناهي. اهو اسان جي حياتياتي ۽ نفسياتي حدن کان ٻاهر نڪرندو آهي، اهو صرف هڪ طريقو آهي جنهن کي ڪنٽرول ڪرڻ ۽ پيچيده سسٽم کي ترقي ڪرڻ جو هڪ طريقو آهي جيڪو بندر انسان جي دماغ کي استعمال ڪري ٿو. هو اسان کي ٻڌائي ٿو ته هڪ نظام کي ڪيئن ختم ڪجي. اصل فارموليشن لاءِ ڪافي مقدار ۾ ٽيليپيٿي جي ضرورت هئي، پر مون کي اميد آهي ته هي آرٽيڪل ڪجهه تماڪ جي اسڪرين کي صاف ڪري ٿو.

جو ذريعو: www.habr.com