ఒకే బాధ్యత సూత్రం. అనిపించేంత సింపుల్ కాదు

ఒకే బాధ్యత సూత్రం, ఒకే బాధ్యత సూత్రం అని కూడా పిలుస్తారు,
ఏకరీతి వేరియబిలిటీ యొక్క సూత్రం - అర్థం చేసుకోవడానికి చాలా జారే వ్యక్తి మరియు ప్రోగ్రామర్ ఇంటర్వ్యూలో అలాంటి నాడీ ప్రశ్న.

ఈ సూత్రంతో నా మొదటి తీవ్రమైన పరిచయం మొదటి సంవత్సరం ప్రారంభంలో జరిగింది, యువకులు మరియు పచ్చని వాటిని లార్వా నుండి విద్యార్థులను తయారు చేయడానికి అడవికి తీసుకెళ్లినప్పుడు - నిజమైన విద్యార్థులు.

అడవిలో, మేము ఒక్కొక్కటి 8-9 మంది వ్యక్తుల సమూహాలుగా విభజించాము మరియు పోటీని కలిగి ఉన్నాము - ఏ సమూహం వోడ్కా బాటిల్‌ను వేగంగా తాగుతుంది, సమూహం నుండి మొదటి వ్యక్తి వోడ్కాను ఒక గ్లాసులో పోస్తే, రెండవది తాగుతుంది, మరియు మూడవది చిరుతిండి. దాని ఆపరేషన్‌ను పూర్తి చేసిన యూనిట్ సమూహం యొక్క క్యూ చివరి వరకు కదులుతుంది.

క్యూ పరిమాణం మూడింటికి గుణకారంగా ఉన్న సందర్భం SRP యొక్క మంచి అమలు.

నిర్వచనం 1. ఒకే బాధ్యత.

సింగిల్ రెస్పాన్సిబిలిటీ ప్రిన్సిపల్ (SRP) యొక్క అధికారిక నిర్వచనం ప్రకారం, ప్రతి సంస్థకు దాని స్వంత బాధ్యత మరియు ఉనికికి కారణం ఉంటుంది మరియు దానికి ఒకే ఒక బాధ్యత ఉంటుంది.

"తాగుడు" అనే వస్తువును పరిగణించండి (టిప్లర్).
SRP సూత్రాన్ని అమలు చేయడానికి, మేము బాధ్యతలను మూడుగా విభజిస్తాము:

• ఒకరు పోస్తారు (PourOperation)
• ఒక పానీయాలు (డ్రింక్‌ఆపరేషన్)
• ఒకరికి అల్పాహారం ఉంది (TakeBiteOperation)

ప్రక్రియలో పాల్గొనే ప్రతి ఒక్కరూ ప్రక్రియ యొక్క ఒక భాగానికి బాధ్యత వహిస్తారు, అనగా ఒక అణు బాధ్యత - త్రాగడానికి, పోయడానికి లేదా చిరుతిండికి.

త్రాగే రంధ్రం, ఈ కార్యకలాపాలకు ఒక ముఖభాగం:

с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 లైన్ల భయంకరమైన పద్ధతుల్లో ముగుస్తుంది, రష్యా NATOలో చేరడానికి అవసరమైన దానికంటే ఎక్కువ if-స్టేట్‌మెంట్‌లతో.

నిర్వచనం 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)
        }
    }
}

నిశితమైన పాఠకుడు దానిని గమనిస్తాడు లాగ్ఆఫ్టర్, ముందు లాగిన్ చేయండి и లోపం వ్యక్తిగతంగా కూడా మార్చవచ్చు మరియు మునుపటి దశలతో సారూప్యత ద్వారా మూడు తరగతులను సృష్టిస్తుంది: 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 పంక్తుల సారూప్య కంటెంట్ కోసం GOD పద్ధతి కనిపించింది:

• 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