ஒற்றைப் பொறுப்புக் கொள்கை. அது போல் எளிமையானது அல்ல

ஒற்றை பொறுப்புக் கொள்கை, ஒற்றைப் பொறுப்பின் கொள்கை என்றும் அழைக்கப்படுகிறது,
aka சீரான மாறுபாட்டின் கொள்கை - புரிந்து கொள்ள மிகவும் வழுக்கும் பையன் மற்றும் ஒரு புரோகிராமர் நேர்காணலில் ஒரு பதட்டமான கேள்வி.

இந்த கொள்கையுடன் எனது முதல் தீவிர அறிமுகம் முதல் ஆண்டின் தொடக்கத்தில் நடந்தது, இளம் மற்றும் பசுமையானவர்களை லார்வாக்களிலிருந்து மாணவர்களை உருவாக்க காட்டிற்கு அழைத்துச் செல்லப்பட்டபோது - உண்மையான மாணவர்கள்.

காட்டில், நாங்கள் தலா 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 வரிகள் கொண்ட பயங்கரமான முறைகளில் முடிவடைகிறது, ரஷ்யா நேட்டோவில் சேருவதற்குத் தேவையானதை விட அதிகமான 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 க்கு "நசுக்கும்போது நசுக்குதல்" தேவைப்படுவது மட்டுமல்லாமல், அதை மிகைப்படுத்தக்கூடாது - "இணைந்த விஷயங்களை நசுக்க வேண்டாம்". ஒக்காமின் சவரனுக்கும் குரங்கு மனிதனுக்கும் நடக்கும் மாபெரும் போர் இது!

இப்போது குடிப்பவர் நன்றாக உணர வேண்டும். 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 வணிகச் செயல்பாடுகள் இருந்தன. கிட்டத்தட்ட அனைவருக்கும் கணக்கு பொருள் தேவைப்பட்டது. பாதி அழைப்புகளில் புள்ளி ஐடி மற்றும் கிளையன்ட் பெயர் தேவைப்பட்டது.

ஒரு மணிநேர மறுசீரமைப்புக்குப் பிறகு, உள்கட்டமைப்புக் குறியீடு மற்றும் கணக்குடன் பணிபுரியும் சில நுணுக்கங்களை தனி முறைகள்/வகுப்புகளாகப் பிரிக்க முடிந்தது. கடவுள் முறை அதை எளிதாக்கியது, ஆனால் 100 கோடுகள் மீதமுள்ளன, அது சிக்கலைத் தவிர்க்க விரும்பவில்லை.

இந்த "இலகுரக" முறையின் சாராம்சம் ஒரு வணிக வழிமுறை என்பது சில நாட்களுக்குப் பிறகுதான் தெரிந்தது. தொழில்நுட்ப விவரக்குறிப்புகளின் அசல் விளக்கம் மிகவும் சிக்கலானது. இந்த முறையை துண்டு துண்டாக உடைக்கும் முயற்சியே SRP ஐ மீறும், மாறாக அல்ல.

சம்பிரதாயம்.

எங்கள் குடிகாரனை விட்டுவிட வேண்டிய நேரம் இது. உங்கள் கண்ணீரை உலர்த்துங்கள் - நாங்கள் நிச்சயமாக ஒரு நாள் அதற்குத் திரும்புவோம். இப்போது இந்த கட்டுரையிலிருந்து அறிவை முறைப்படுத்துவோம்.

சம்பிரதாயம் 1. SRP இன் வரையறை

1. உறுப்புகளை பிரிக்கவும், அதனால் அவை ஒவ்வொன்றும் ஒரு விஷயத்திற்கு பொறுப்பாகும்.
2. பொறுப்பு என்பது "மாற்றத்திற்கான காரணம்" என்பதைக் குறிக்கிறது. அதாவது, வணிக தர்க்கத்தின் அடிப்படையில், ஒவ்வொரு உறுப்புக்கும் மாற்றத்திற்கான ஒரே ஒரு காரணம் மட்டுமே உள்ளது.
3. வணிக தர்க்கத்தில் சாத்தியமான மாற்றங்கள். உள்ளூர்மயமாக்கப்பட வேண்டும். ஒத்திசைவாக மாறும் கூறுகள் அருகில் இருக்க வேண்டும்.

சம்பிரதாயம் 2. தேவையான சுய பரிசோதனை அளவுகோல்கள்.

எஸ்ஆர்பியை நிறைவேற்றுவதற்கான போதுமான அளவுகோல்களை நான் காணவில்லை. ஆனால் தேவையான நிபந்தனைகள் உள்ளன:

1) இந்த வகுப்பு/முறை/தொகுதி/சேவை என்ன செய்கிறது என்பதை நீங்களே கேட்டுக்கொள்ளுங்கள். நீங்கள் ஒரு எளிய வரையறையுடன் பதிலளிக்க வேண்டும். ( நன்றி பிரைடோரி )

விளக்கங்கள்

இருப்பினும், சில நேரங்களில் ஒரு எளிய வரையறையை கண்டுபிடிப்பது மிகவும் கடினம்

2) பிழையைச் சரிசெய்வது அல்லது புதிய அம்சத்தைச் சேர்ப்பது குறைந்தபட்ச எண்ணிக்கையிலான கோப்புகள்/வகுப்புகளைப் பாதிக்கிறது. வெறுமனே - ஒன்று.

விளக்கங்கள்

பொறுப்பு (அம்சங்கள் அல்லது பிழைக்கானது) ஒரு கோப்பு/வகுப்பில் இணைக்கப்பட்டிருப்பதால், எங்கு பார்க்க வேண்டும், எதைத் திருத்த வேண்டும் என்பது உங்களுக்குத் தெரியும். எடுத்துக்காட்டாக: பதிவு செய்யும் செயல்பாடுகளின் வெளியீட்டை மாற்றும் அம்சத்திற்கு லாகரை மட்டும் மாற்ற வேண்டும். மீதமுள்ள குறியீட்டை இயக்க வேண்டிய அவசியமில்லை.

மற்றொரு எடுத்துக்காட்டு, முந்தையதைப் போலவே புதிய UI கட்டுப்பாட்டைச் சேர்ப்பது. இது 10 வெவ்வேறு நிறுவனங்களையும் 15 வெவ்வேறு மாற்றிகளையும் சேர்க்க உங்களை கட்டாயப்படுத்தினால், நீங்கள் அதை மிகைப்படுத்துவது போல் தெரிகிறது.

3) உங்கள் திட்டத்தின் வெவ்வேறு அம்சங்களில் பல டெவலப்பர்கள் பணிபுரிந்தால், ஒன்றிணைப்பு மோதலின் சாத்தியக்கூறு, அதாவது ஒரே கோப்பு/வகுப்பு ஒரே நேரத்தில் பல டெவலப்பர்களால் மாற்றப்படும் வாய்ப்பு மிகக் குறைவு.

விளக்கங்கள்

“மேசையின் கீழ் ஓட்காவை ஊற்றவும்” என்ற புதிய செயல்பாட்டைச் சேர்க்கும்போது, ​​​​நீங்கள் லாகர், குடிப்பழக்கம் மற்றும் ஊற்றுதல் ஆகியவற்றைப் பாதிக்க வேண்டும் என்றால், பொறுப்புகள் வக்கிரமாகப் பிரிக்கப்பட்டதாகத் தெரிகிறது. நிச்சயமாக, இது எப்போதும் சாத்தியமில்லை, ஆனால் இந்த எண்ணிக்கையை குறைக்க முயற்சிக்க வேண்டும்.

4) வணிக தர்க்கம் (டெவலப்பர் அல்லது மேலாளரிடமிருந்து) பற்றிய தெளிவுபடுத்தும் கேள்வியைக் கேட்டால், நீங்கள் கண்டிப்பாக ஒரு வகுப்பு/கோப்புக்குள் சென்று அங்கிருந்து மட்டுமே தகவலைப் பெறுவீர்கள்.

விளக்கங்கள்

அம்சங்கள், விதிகள் அல்லது வழிமுறைகள் சுருக்கமாக எழுதப்பட்டவை, ஒவ்வொன்றும் ஒரே இடத்தில், மற்றும் குறியீடு இடம் முழுவதும் கொடிகளுடன் சிதறடிக்கப்படவில்லை.

5) பெயர் தெளிவாக உள்ளது.

விளக்கங்கள்

எங்கள் வகுப்பு அல்லது முறை ஒரு விஷயத்திற்கு பொறுப்பாகும், மேலும் பொறுப்பு அதன் பெயரில் பிரதிபலிக்கிறது

AllManagersManagerService - பெரும்பாலும் கடவுள் வகுப்பு
உள்ளூர் கட்டணம் - ஒருவேளை இல்லை

சம்பிரதாயம் 3. ஒக்காம்-முதல் வளர்ச்சி முறை.

வடிவமைப்பின் தொடக்கத்தில், குரங்கு மனிதனுக்குத் தெரியாது, பிரச்சனையின் அனைத்து நுணுக்கங்களும் தீர்க்கப்படுவதை உணரவில்லை, மேலும் தவறு செய்யலாம். நீங்கள் வெவ்வேறு வழிகளில் தவறு செய்யலாம்:

• வெவ்வேறு பொறுப்புகளை ஒன்றிணைப்பதன் மூலம் பொருட்களை மிகப் பெரியதாக ஆக்குங்கள்
• ஒரு பொறுப்பை பல வகைகளாகப் பிரிப்பதன் மூலம் மறுவடிவமைத்தல்
• பொறுப்பின் எல்லைகளை தவறாக வரையறுக்கவும்

விதியை நினைவில் கொள்வது முக்கியம்: "ஒரு பெரிய தவறு செய்வது நல்லது," அல்லது "உங்களுக்கு உறுதியாக தெரியவில்லை என்றால், அதை பிரிக்க வேண்டாம்." எடுத்துக்காட்டாக, உங்கள் வகுப்பில் இரண்டு பொறுப்புகள் இருந்தால், அது இன்னும் புரிந்துகொள்ளக்கூடியது மற்றும் கிளையன்ட் குறியீட்டில் குறைந்தபட்ச மாற்றங்களுடன் இரண்டாகப் பிரிக்கப்படலாம். பல கோப்புகளில் சூழல் பரவியிருப்பதாலும், கிளையன்ட் குறியீட்டில் தேவையான சார்புகள் இல்லாததாலும், கண்ணாடித் துண்டுகளிலிருந்து ஒரு கண்ணாடியை அசெம்பிள் செய்வது பொதுவாக மிகவும் கடினம்.

ஒரு நாள் என்று அழைக்க வேண்டிய நேரம் இது

SRP இன் நோக்கம் OOP மற்றும் SOLID க்கு மட்டும் அல்ல. இது முறைகள், செயல்பாடுகள், வகுப்புகள், தொகுதிகள், மைக்ரோ சர்வீஸ்கள் மற்றும் சேவைகளுக்குப் பொருந்தும். இது "figax-figax-and-prod" மற்றும் "rocket-science" ஆகிய இரண்டிற்கும் பொருந்தும், இது உலகத்தை எல்லா இடங்களிலும் கொஞ்சம் சிறப்பாக மாற்றுகிறது. நீங்கள் இதைப் பற்றி சிந்தித்தால், இது எல்லா பொறியியலின் அடிப்படைக் கொள்கையாகும். மெக்கானிக்கல் இன்ஜினியரிங், கட்டுப்பாட்டு அமைப்புகள் மற்றும் உண்மையில் அனைத்து சிக்கலான அமைப்புகளும் கூறுகளிலிருந்து கட்டமைக்கப்படுகின்றன, மேலும் "குறைவானது" வடிவமைப்பாளர்களின் நெகிழ்வுத்தன்மையை இழக்கிறது, "ஓவர் ஃபிராக்மென்டேஷன்" வடிவமைப்பாளர்களின் செயல்திறனை இழக்கிறது, மேலும் தவறான எல்லைகள் அவர்களின் காரணத்தையும் மன அமைதியையும் இழக்கின்றன.

SRP இயற்கையால் கண்டுபிடிக்கப்படவில்லை மற்றும் சரியான அறிவியலின் ஒரு பகுதியாக இல்லை. இது நமது உயிரியல் மற்றும் உளவியல் வரம்புகளிலிருந்து வெளியேறுகிறது.குரங்கு-மனிதன் மூளையைப் பயன்படுத்தி சிக்கலான அமைப்புகளைக் கட்டுப்படுத்தவும் மேம்படுத்தவும் இது ஒரு வழியாகும். ஒரு அமைப்பை எவ்வாறு சிதைப்பது என்று அவர் கூறுகிறார். அசல் உருவாக்கத்திற்கு நியாயமான அளவு டெலிபதி தேவைப்பட்டது, ஆனால் இந்த கட்டுரை சில புகை திரைகளை அழிக்கும் என்று நம்புகிறேன்.

ஆதாரம்: www.habr.com