د واحد مسؤلیت اصول. دومره ساده ندی لکه څنګه چې ښکاري

د واحد مسؤلیت اصول، چې د واحد مسؤلیت اصول هم پیژندل کیږي،
د یونیفورم تغیراتو اصول - د پوهیدو لپاره خورا ټیټ سړی او د پروګرامر مرکه کې دا ډول عصبي پوښتنه.

د دې اصل سره زما لومړی جدي پیژندنه د لومړي کال په پیل کې هغه وخت وشوه چې ځوان او شین ځنګل ته د لاروا څخه زده کونکي جوړ کړي - اصلي زده کونکي.

په ځنګل کې، موږ هر یو د 8-9 کسانو په ګروپونو ویشل شوي وو او سیالي یې درلوده - کومه ډله به په چټکۍ سره د وودکا بوتل وڅښي، په دې شرط چې د ډلې لومړی کس په ګیلاس کې وودکا واچوي، دویم یې وڅښي، او دریم ناشته لري. هغه واحد چې خپل عملیات بشپړ کړي د ګروپ کتار پای ته ځي.

هغه قضیه چیرې چې د قطار اندازه د دریو څخه ډیری وه د SRP ښه تطبیق و.

تعریف 1. واحد مسؤلیت.

د واحد مسؤلیت اصول (SRP) رسمي تعریف داسې بیانوي چې هره اداره خپل مسؤلیت او د شتون دلیل لري، او دا یوازې یو مسؤلیت لري.

د "څښاک" څیز ته پام وکړئ (ټیپلر).
د SRP اصول پلي کولو لپاره، موږ به مسؤلیتونه په دریو برخو وویشو:

• یو توزیع (عملیات)
• یو څښاک (د څښاک عملیات)
• یو ناشته لري (ټیک بایټ عملیات)

په پروسه کې هر یو ګډونوال د پروسې د یوې برخې لپاره مسؤل دی، دا یو اټومي مسؤلیت لري - څښاک، اچول یا ناشونی.

د څښاک سوري، په پایله کې، د دې عملیاتو لپاره مخ دی:

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

ولې؟

د انسان برنامه کوونکی د ape-man لپاره کوډ لیکي، او Ape-man بې پامه، احمق او تل په بیړه کې وي. هغه کولی شي په یو وخت کې د 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 ټول توضیحات چې پورته یې ویل شوي چې دا اړینه وه چې ډولونه یې وخورئ پداسې حال کې چې دوی یې کرل شوي وو ، دا د شیانو په اندازې کې "پورته حد" وضع کړی ، او اوس موږ دمخه د "ټیټ حد" په اړه خبرې کوو. په بل عبارت، 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 لینونو لپاره د خدای میتود څرګند شو:

• 1C ته لاړ شئ او یو حساب جوړ کړئ
• د دې حساب سره، د تادیې ماډل ته لاړ شئ او هلته یې جوړ کړئ
• وګورئ چې د داسې حساب سره حساب په اصلي سرور کې ندی رامینځته شوی
• یو نوی حساب جوړ کړئ
• د راجسټریشن پایلې د تادیې ماډل کې او د 1c شمیره د راجسټریشن پایلو خدماتو ته اضافه کړئ
• دې جدول ته د حساب معلومات اضافه کړئ
• د پوائنټ خدمت کې د دې پیرودونکي لپاره د نقطې شمیره جوړه کړئ. خپل 1c حساب شمیره دې خدمت ته واستوئ.

او په دې لیست کې شاوخوا 10 نور سوداګریز عملیات وو چې د ویرونکي ارتباط سره. نږدې هرڅوک د حساب توکي ته اړتیا لري. د ټکي ID او د پیرودونکي نوم په نیمایي تلیفونونو کې اړین و.

د یو ساعت بیا جوړونې وروسته، موږ وکولی شو د زیربنا کوډ او د حساب سره د کار کولو ځینې لنډیزونه په جلا میتودونو / ټولګیو کې جلا کړو. د خدای طریقه دا اسانه کړې، مګر د کوډ 100 کرښې پاتې وې چې نه یې غوښتل بې ځایه شي.

یوازې د څو ورځو وروسته دا څرګنده شوه چې د دې "لږ وزن" میتود جوهر د سوداګرۍ الګوریتم دی. او دا چې د تخنیکي مشخصاتو اصلي توضیح خورا پیچلی و. او دا هڅه ده چې دا طریقه ټوټې ټوټې کړي چې د SRP څخه سرغړونه کوي، نه برعکس.

رسميت.

دا وخت دی چې خپل شراب یوازې پریږدو. خپلې اوښکې وچې کړئ - موږ به خامخا یوه ورځ ورته راستون شو. اوس راځئ چې د دې مقالې څخه پوهه رسمي کړو.

رسميت 1. د SRP تعریف

1. عناصر جلا کړئ ترڅو هر یو د یو شی لپاره مسؤل وي.
2. مسؤلیت د "بدلون دلیل" لپاره ولاړ دی. دا دی، هر عنصر د سوداګرۍ منطق په شرایطو کې د بدلون لپاره یوازې یو دلیل لري.
3. د سوداګرۍ منطق کې احتمالي بدلونونه. باید محلي شي. هغه عناصر چې په همغږي ډول بدلیږي باید نږدې وي.

رسمیزم 2. د ځان ازموینې اړین معیارونه.

ما د SRP پوره کولو لپاره کافي معیارونه ندي لیدلي. مګر اړین شرایط شتون لري:

1) له ځانه وپوښتئ چې دا ټولګي/طریقه/ماډول/خدمت څه کوي. تاسو باید دا په ساده تعریف سره ځواب کړئ. ( له تاسو مننه برائٹوري )

توضیحات

په هرصورت، ځینې وختونه دا خورا ستونزمن وي چې ساده تعریف ومومئ

2) د بګ حل کول یا د نوي فیچر اضافه کول لږترلږه فایلونه / ټولګیو اغیزه کوي. په مثالي توګه - یو.

توضیحات

څرنګه چې مسؤلیت (د یو فیچر یا بګ لپاره) په یوه فایل / ټولګي کې پوښل شوی، تاسو په سمه توګه پوهیږئ چې چیرته وګورئ او څه شی ترمیم کړئ. د مثال په توګه: د ننوتلو عملیاتو محصول بدلولو ځانګړتیا به یوازې د لاګر بدلولو ته اړتیا ولري. د پاتې کوډ له لارې چلولو ته اړتیا نشته.

بله بیلګه د نوي UI کنټرول اضافه کول دي ، د تیرو ورته ورته. که دا تاسو مجبوروي چې 10 مختلف ادارې او 15 مختلف کنورټرونه اضافه کړئ ، داسې ښکاري چې تاسو دا ډیر کوئ.

3) که چیرې ډیری پراختیا کونکي ستاسو د پروژې مختلف ب featuresو باندې کار کوي ، نو د یوځای کیدو احتمال ، دا احتمال چې ورته فایل / ټولګي به په ورته وخت کې د ډیری پراختیا کونکو لخوا بدل شي ، لږترلږه دی.

توضیحات

که چیرې ، کله چې یو نوی عملیات اضافه کړئ "د میز لاندې ووډکا واچوئ" ، تاسو اړتیا لرئ په لوګر اغیزه وکړئ ، د څښاک او تویولو عملیات ، نو داسې ښکاري چې مسؤلیتونه په کره ډول ویشل شوي. البته، دا تل ممکنه نه ده، مګر موږ باید هڅه وکړو چې دا ارقام کم کړو.

4) کله چې د سوداګرۍ منطق (د پراختیا کونکي یا مدیر څخه) په اړه روښانه پوښتنې وپوښتئ ، تاسو په کلکه یو ټولګي / فایل ته ځئ او یوازې له هغه ځایه معلومات ترلاسه کوئ.

توضیحات

ځانګړتیاوې، قواعد یا الګوریتمونه په متناسب ډول لیکل شوي، هر یو په یو ځای کې، او د کوډ ځای کې د بیرغونو سره نه ویشل شوي.

5) نوم ورکول روښانه دي.

توضیحات

زموږ طبقه یا طریقه د یو شی لپاره مسؤل دی، او مسؤلیت د هغه په ​​نوم منعکس کیږي

AllManagersManagerService - ډیری احتمال د خدای ټولګي
محلي تادیه - شاید نه

رسمیزم 3. د Occam-لومړی پرمختیا میتودولوژی.

د ډیزاین په پیل کې، د بندر سړی نه پوهیږي او د ستونزې د حل کولو ټولې نیمګړتیاوې نه احساسوي او کولی شي غلطي وکړي. تاسو کولی شئ په مختلفو لارو غلطي وکړئ:

• د مختلف مسؤلیتونو په یوځای کولو سره توکي خورا لوی کړئ
• د یو واحد مسؤلیت په ډیری بیلابیلو ډولونو ویشلو سره بیاکتنه
• د مسؤلیت حدود په غلط ډول تعریف کړئ

دا مهمه ده چې دا قاعده په یاد ولرئ: "دا غوره ده چې لویه تېروتنه وکړئ،" یا "که تاسو ډاډه نه یاست، دا مه ویشئ." که، د مثال په توګه، ستاسو ټولګي دوه مسؤلیتونه لري، نو دا لاهم د پوهیدو وړ دی او د پیرودونکي کوډ کې لږترلږه بدلونونو سره په دوه ویشل کیدی شي. د شیشې ټوټو څخه د شیشې راټولول معمولا خورا ستونزمن وي ځکه چې شرایط په ډیری فایلونو کې خپریږي او د پیرودونکي کوډ کې د اړین انحصار نشتوالی.

دا وخت دی چې یوه ورځ ورته ووایاست

د SRP ساحه په OOP او SOLID پورې محدود نه ده. دا په میتودونو، دندو، ټولګیو، ماډلونو، مایکرو خدماتو او خدماتو باندې تطبیق کیږي. دا د "فګاکس-فګاکس-او-پراډ" او "راکټ ساینس" پراختیا دواړو باندې پلي کیږي، چې نړۍ هرچیرې یو څه ښه کوي. که تاسو د هغې په اړه فکر کوئ، دا تقریبا د ټولو انجینرۍ بنسټیز اصول دی. میخانیکي انجینرۍ، د کنټرول سیسټمونه، او په حقیقت کې ټول پیچلي سیسټمونه د اجزاوو څخه جوړ شوي، او "انډر فریګمینشن" ډیزاینران د انعطاف وړتیا څخه محروموي، "زیات ټوټه کول" ډیزاینران د موثریت څخه محروموي، او غلط سرحدونه دوی د عقل او ذهني سکون څخه محروموي.

SRP د طبیعت لخوا نه ایجاد شوی او د دقیق ساینس برخه نه ده. دا زموږ د بیولوژیکي او رواني محدودیتونو څخه ماتیږي دا یوازې د انسان دماغ په کارولو سره د پیچلي سیسټمونو کنټرول او پراختیا لپاره یوه لاره ده. هغه موږ ته وايي چې څنګه یو سیسټم تخریب کړو. اصلي فورمول په کافي اندازه ټیلی پیټي ته اړتیا لري، مګر زه هیله لرم چې دا مقاله یو څه د سګرټ سکرین پاک کړي.

سرچینه: www.habr.com