એક જવાબદારી સિદ્ધાંત. તે લાગે છે તેટલું સરળ નથી

સિંગલ જવાબદારી સિદ્ધાંત, જેને સિંગલ જવાબદારીના સિદ્ધાંત તરીકે પણ ઓળખવામાં આવે છે,
સમાન પરિવર્તનશીલતાનો સિદ્ધાંત ઉર્ફ - સમજવા માટે એક અત્યંત લપસણો વ્યક્તિ અને પ્રોગ્રામર ઇન્ટરવ્યુમાં આવો નર્વસ પ્રશ્ન.

આ સિદ્ધાંત સાથેનો મારો પ્રથમ ગંભીર પરિચય પ્રથમ વર્ષની શરૂઆતમાં થયો હતો, જ્યારે યુવાન અને લીલા બાળકોને લાર્વામાંથી વિદ્યાર્થીઓ - વાસ્તવિક વિદ્યાર્થીઓ બનાવવા માટે જંગલમાં લઈ જવામાં આવ્યા હતા.

જંગલમાં, અમને 8-9 લોકોના જૂથોમાં વહેંચવામાં આવ્યા હતા અને એક સ્પર્ધા હતી - કયું જૂથ વોડકાની બોટલ સૌથી ઝડપી પીશે, જો કે જૂથમાંથી પ્રથમ વ્યક્તિ વોડકાને ગ્લાસમાં રેડે, બીજો તેને પીવે, અને ત્રીજાને નાસ્તો છે. એકમ કે જેણે તેની કામગીરી પૂર્ણ કરી છે તે જૂથની કતારના અંતમાં જાય છે.

કેસ જ્યાં કતારનું કદ ત્રણના ગુણાંકમાં હતું તે SRPનો સારો અમલ હતો.

વ્યાખ્યા 1. એકલ જવાબદારી.

સિંગલ રિસ્પોન્સિબિલિટી પ્રિન્સિપલ (એસઆરપી) ની સત્તાવાર વ્યાખ્યા જણાવે છે કે દરેક એન્ટિટીની પોતાની જવાબદારી અને અસ્તિત્વ માટેનું કારણ હોય છે અને તેની માત્ર એક જ જવાબદારી હોય છે.

ઑબ્જેક્ટ "પીનાર" ને ધ્યાનમાં લો (ટીપ્પલર).
SRP સિદ્ધાંતનો અમલ કરવા માટે, અમે જવાબદારીઓને ત્રણ ભાગમાં વહેંચીશું:

• એક રેડવું (PourOperation)
• એક પીણું (ડ્રિંકઅપ ઓપરેશન)
• એક નાસ્તો છે (ટેકબાઇટ ઓપરેશન)

પ્રક્રિયાના દરેક સહભાગીઓ પ્રક્રિયાના એક ઘટક માટે જવાબદાર છે, એટલે કે, એક પરમાણુ જવાબદારી છે - પીવું, રેડવું અથવા નાસ્તો.

પીવાના છિદ્ર, બદલામાં, આ કામગીરી માટે રવેશ છે:

с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}");
    }
}

તેમાં સમાવિષ્ટ કરીને 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)
        }
    }
}

ઝીણવટપૂર્વક વાંચનાર તેની નોંધ લેશે લોગઆફ્ટર, LogBefore и OnError વ્યક્તિગત રીતે પણ બદલી શકાય છે, અને, અગાઉના પગલાં સાથે સામ્યતા દ્વારા, ત્રણ વર્ગો બનાવશે: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

અને યાદ રાખવું કે પીનાર માટે ત્રણ ઓપરેશન છે, અમને નવ લોગીંગ ક્લાસ મળે છે. પરિણામે, સમગ્ર પીવાના વર્તુળમાં 14 (!!!) વર્ગોનો સમાવેશ થાય છે.

હાયપરબોલા? ભાગ્યે જ! વિઘટન કરનાર ગ્રેનેડ ધરાવતો વાનર માણસ "રેડનાર" ને ડિકેન્ટર, ગ્લાસ, રેડતા ઓપરેટર્સ, પાણી પુરવઠા સેવા, પરમાણુઓની અથડામણનું ભૌતિક મોડેલમાં વિભાજિત કરશે અને આગામી ક્વાર્ટરમાં તે નિર્ભરતાને દૂર કરવાનો પ્રયાસ કરશે. વૈશ્વિક ચલો. અને મારા પર વિશ્વાસ કરો, તે અટકશે નહીં.

તે આ સમયે છે કે ઘણા એવા નિષ્કર્ષ પર આવે છે કે 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. જરૂરી સ્વ-પરીક્ષણ માપદંડ.

SRP ને પરિપૂર્ણ કરવા માટે મેં પૂરતા માપદંડ જોયા નથી. પરંતુ ત્યાં જરૂરી શરતો છે:

1) તમારી જાતને પૂછો કે આ વર્ગ/પદ્ધતિ/મોડ્યુલ/સેવા શું કરે છે. તમારે તેને સરળ વ્યાખ્યા સાથે જવાબ આપવો જોઈએ. ( આભાર બ્રાઇટોરી )

સ્પષ્ટતા

જો કે, કેટલીકવાર સરળ વ્યાખ્યા શોધવાનું ખૂબ મુશ્કેલ છે

2) ભૂલને ઠીક કરવી અથવા નવી સુવિધા ઉમેરવાથી ફાઇલો/વર્ગોની ન્યૂનતમ સંખ્યાને અસર થાય છે. આદર્શ રીતે - એક.

સ્પષ્ટતા

જવાબદારી (સુવિધા અથવા બગ માટે) એક ફાઇલ/વર્ગમાં સમાવિષ્ટ હોવાથી, તમે બરાબર જાણો છો કે ક્યાં જોવું અને શું સંપાદિત કરવું. ઉદાહરણ તરીકે: લૉગિંગ ઑપરેશન્સના આઉટપુટને બદલવાની સુવિધા માટે માત્ર લૉગર બદલવાની જરૂર પડશે. બાકીના કોડને ચલાવવાની જરૂર નથી.

બીજું ઉદાહરણ એ એક નવું UI કંટ્રોલ ઉમેરવાનું છે, જે અગાઉના લોકો જેવું જ છે. જો આ તમને 10 અલગ અલગ એન્ટિટી અને 15 અલગ કન્વર્ટર ઉમેરવા દબાણ કરે છે, તો એવું લાગે છે કે તમે તેને વધારે કરી રહ્યાં છો.

3) જો ઘણા વિકાસકર્તાઓ તમારા પ્રોજેક્ટની વિવિધ સુવિધાઓ પર કામ કરી રહ્યા હોય, તો મર્જ સંઘર્ષની સંભાવના, એટલે કે, એક જ સમયે ઘણા વિકાસકર્તાઓ દ્વારા સમાન ફાઇલ/ક્લાસ બદલવાની સંભાવના ન્યૂનતમ છે.

સ્પષ્ટતા

જો, જ્યારે નવું ઑપરેશન “પૉર વોડકા અન્ડર ધ ટેબલ” ઉમેરી રહ્યા હોય, તો તમારે લોગરને સ્પર્શ કરવાની જરૂર છે, પીવાનું અને રેડવાનું ઑપરેશન, તો એવું લાગે છે કે જવાબદારીઓ કુટિલ રીતે વહેંચાયેલી છે. અલબત્ત, આ હંમેશા શક્ય નથી, પરંતુ આપણે આ આંકડો ઘટાડવાનો પ્રયાસ કરવો જોઈએ.

4) જ્યારે બિઝનેસ લોજિક (વિકાસકર્તા અથવા મેનેજર તરફથી) વિશે સ્પષ્ટતા કરતો પ્રશ્ન પૂછવામાં આવે, ત્યારે તમે સખત રીતે એક વર્ગ/ફાઈલમાં જાવ અને ત્યાંથી જ માહિતી મેળવો.

સ્પષ્ટતા

સુવિધાઓ, નિયમો અથવા અલ્ગોરિધમ્સ સઘન રીતે લખવામાં આવે છે, દરેક એક જગ્યાએ, અને સમગ્ર કોડ સ્પેસમાં ફ્લેગ્સ સાથે વિખેરાયેલા નથી.

5) નામકરણ સ્પષ્ટ છે.

સ્પષ્ટતા

આપણો વર્ગ અથવા પદ્ધતિ એક વસ્તુ માટે જવાબદાર છે, અને જવાબદારી તેના નામમાં પ્રતિબિંબિત થાય છે

AllManagersManagerService - સંભવતઃ ભગવાન વર્ગ
સ્થાનિક ચુકવણી - કદાચ નહીં

ઔપચારિકતા 3. ઓકેમ-પ્રથમ વિકાસ પદ્ધતિ.

ડિઝાઇનની શરૂઆતમાં, વાનર માણસ જાણતો નથી અને સમસ્યા હલ કરવામાં આવતી તમામ સૂક્ષ્મતાને અનુભવતો નથી અને તે ભૂલ કરી શકે છે. તમે વિવિધ રીતે ભૂલો કરી શકો છો:

• વિવિધ જવાબદારીઓને મર્જ કરીને વસ્તુઓને ખૂબ મોટી બનાવો
• એક જ જવાબદારીને ઘણાં વિવિધ પ્રકારોમાં વિભાજીત કરીને રિફ્રેમિંગ
• જવાબદારીની સીમાઓને ખોટી રીતે વ્યાખ્યાયિત કરો

આ નિયમ યાદ રાખવું અગત્યનું છે: "મોટી ભૂલ કરવી વધુ સારું છે," અથવા "જો તમને ખાતરી ન હોય, તો તેને વિભાજિત કરશો નહીં." જો, ઉદાહરણ તરીકે, તમારા વર્ગમાં બે જવાબદારીઓ છે, તો તે હજી પણ સમજી શકાય તેવું છે અને ક્લાયંટ કોડમાં ન્યૂનતમ ફેરફારો સાથે બે ભાગમાં વિભાજિત કરી શકાય છે. સંદર્ભ ઘણી ફાઇલોમાં ફેલાયેલો હોવાને કારણે અને ક્લાયંટ કોડમાં જરૂરી નિર્ભરતાના અભાવને કારણે કાચના ટુકડાઓમાંથી ગ્લાસ એસેમ્બલ કરવું સામાન્ય રીતે વધુ મુશ્કેલ છે.

તેને એક દિવસ કહેવાનો સમય છે

SRP નો અવકાશ OOP અને SOLID પૂરતો મર્યાદિત નથી. તે પદ્ધતિઓ, કાર્યો, વર્ગો, મોડ્યુલો, માઇક્રોસેવાઓ અને સેવાઓને લાગુ પડે છે. તે “ફિગેક્સ-ફિગેક્સ-અને-પ્રોડ” અને “રોકેટ-સાયન્સ” વિકાસ બંનેને લાગુ પડે છે, જે વિશ્વને દરેક જગ્યાએ થોડું સારું બનાવે છે. જો તમે તેના વિશે વિચારો, તો આ લગભગ તમામ એન્જિનિયરિંગનો મૂળભૂત સિદ્ધાંત છે. મિકેનિકલ એન્જિનિયરિંગ, કંટ્રોલ સિસ્ટમ્સ અને ખરેખર તમામ જટિલ સિસ્ટમો ઘટકોમાંથી બનેલી છે, અને "અંડરફ્રેગમેન્ટેશન" ડિઝાઇનર્સને લવચીકતાથી વંચિત કરે છે, "ઓવરફ્રેગમેન્ટેશન" ડિઝાઇનર્સને કાર્યક્ષમતાથી વંચિત કરે છે, અને ખોટી સીમાઓ તેમને કારણ અને માનસિક શાંતિથી વંચિત કરે છે.

SRP પ્રકૃતિ દ્વારા શોધાયેલ નથી અને તે ચોક્કસ વિજ્ઞાનનો ભાગ નથી. તે આપણી જૈવિક અને મનોવૈજ્ઞાનિક મર્યાદાઓમાંથી બહાર નીકળી જાય છે. તે માત્ર એપ-મેન મગજનો ઉપયોગ કરીને જટિલ પ્રણાલીઓને નિયંત્રિત અને વિકસાવવાનો એક માર્ગ છે. તે અમને કહે છે કે સિસ્ટમ કેવી રીતે વિઘટિત કરવી. મૂળ ફોર્મ્યુલેશન માટે વાજબી માત્રામાં ટેલિપેથીની જરૂર હતી, પરંતુ હું આશા રાખું છું કે આ લેખ સ્મોકસ્ક્રીનમાંથી કેટલાકને સાફ કરશે.

સોર્સ: www.habr.com