ഏക ഉത്തരവാദിത്ത തത്വം. തോന്നുന്നത്ര ലളിതമല്ല

ഏക ഉത്തരവാദിത്ത തത്വം, ഒറ്റ ഉത്തരവാദിത്തത്തിന്റെ തത്വം എന്നും അറിയപ്പെടുന്നു,
യൂണിഫോം വേരിയബിലിറ്റിയുടെ തത്വം - മനസ്സിലാക്കാൻ വളരെ വഴുവഴുപ്പുള്ള ഒരു വ്യക്തി, ഒരു പ്രോഗ്രാമർ അഭിമുഖത്തിൽ അത്തരമൊരു പരിഭ്രാന്തിയുള്ള ചോദ്യം.

ഈ തത്ത്വവുമായി എന്റെ ആദ്യത്തെ ഗുരുതരമായ പരിചയം നടന്നത് ആദ്യ വർഷത്തിന്റെ തുടക്കത്തിലാണ്, കുട്ടികളും പച്ചയും ഉള്ളവരെ ലാർവകളിൽ നിന്ന് വിദ്യാർത്ഥികളാക്കാൻ കാട്ടിലേക്ക് കൊണ്ടുപോയപ്പോൾ - യഥാർത്ഥ വിദ്യാർത്ഥികൾ.

കാട്ടിൽ, ഞങ്ങളെ 8-9 ആളുകളുടെ ഗ്രൂപ്പുകളായി തിരിച്ച് ഒരു മത്സരം നടത്തി - ഏത് ഗ്രൂപ്പാണ് ഏറ്റവും വേഗത്തിൽ ഒരു കുപ്പി വോഡ്ക കുടിക്കുന്നത്, ഗ്രൂപ്പിലെ ആദ്യത്തെയാൾ ഒരു ഗ്ലാസിലേക്ക് വോഡ്ക പകരും, രണ്ടാമൻ അത് കുടിക്കും, മൂന്നാമൻ ലഘുഭക്ഷണവും. അതിന്റെ പ്രവർത്തനം പൂർത്തിയാക്കിയ യൂണിറ്റ് ഗ്രൂപ്പിന്റെ ക്യൂവിന്റെ അവസാനത്തിലേക്ക് നീങ്ങുന്നു.

ക്യൂ സൈസ് മൂന്നിന്റെ ഗുണിതമായിരുന്ന കേസ് എസ്ആർപിയുടെ നല്ല പ്രയോഗമായിരുന്നു.

നിർവ്വചനം 1. ഏക ഉത്തരവാദിത്തം.

സിംഗിൾ റെസ്‌പോൺസിബിലിറ്റി പ്രിൻസിപ്പിൾ (എസ്‌ആർ‌പി) യുടെ ഔദ്യോഗിക നിർവ്വചനം ഓരോ സ്ഥാപനത്തിനും അതിന്റേതായ ഉത്തരവാദിത്തവും നിലനിൽപ്പിനുള്ള കാരണവും ഉണ്ടെന്നും അതിന് ഒരു ഉത്തരവാദിത്തമേ ഉള്ളൂ എന്നും പറയുന്നു.

"കുടിക്കാരൻ" എന്ന വസ്തു പരിഗണിക്കുക (ടിപ്ലർ).
SRP തത്വം നടപ്പിലാക്കാൻ, ഞങ്ങൾ ഉത്തരവാദിത്തങ്ങളെ മൂന്നായി വിഭജിക്കും:

• ഒന്ന് ഒഴിക്കുന്നു (പവർ ഓപ്പറേഷൻ)
• ഒരു പാനീയം (ഡ്രിങ്ക് ഓപ്പറേഷൻ)
• ഒരാൾക്ക് ലഘുഭക്ഷണമുണ്ട് (ടേക്ക്ബൈറ്റ് ഓപ്പറേഷൻ)

പ്രക്രിയയിൽ പങ്കെടുക്കുന്ന ഓരോരുത്തരും പ്രക്രിയയുടെ ഒരു ഘടകത്തിന് ഉത്തരവാദികളാണ്, അതായത്, ഒരു ആറ്റോമിക് ഉത്തരവാദിത്തമുണ്ട് - കുടിക്കുക, ഒഴിക്കുക അല്ലെങ്കിൽ ലഘുഭക്ഷണം ചെയ്യുക.

കുടിവെള്ള ദ്വാരം, ഈ പ്രവർത്തനങ്ങൾക്കുള്ള ഒരു മുൻഭാഗമാണ്:

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

എന്തുകൊണ്ട്?

മനുഷ്യനായ പ്രോഗ്രാമർ കുരങ്ങൻ-മനുഷ്യന് കോഡ് എഴുതുന്നു, കുരങ്ങൻ-മനുഷ്യൻ അശ്രദ്ധനും മണ്ടനും എപ്പോഴും തിരക്കിലാണ്. ഒരേസമയം 3-7 പദങ്ങൾ അയാൾക്ക് പിടിക്കാനും മനസ്സിലാക്കാനും കഴിയും.
ഒരു മദ്യപാനിയുടെ കാര്യത്തിൽ, ഈ മൂന്ന് നിബന്ധനകൾ ഉണ്ട്. എന്നിരുന്നാലും, ഒരു ഷീറ്റ് ഉപയോഗിച്ച് ഞങ്ങൾ കോഡ് എഴുതിയാൽ, അതിൽ കൈകളും കണ്ണടകളും വഴക്കുകളും രാഷ്ട്രീയത്തെക്കുറിച്ചുള്ള അനന്തമായ വാദങ്ങളും അടങ്ങിയിരിക്കും. ഇതെല്ലാം ഒരു രീതിയുടെ ശരീരത്തിൽ ആയിരിക്കും. നിങ്ങളുടെ പരിശീലനത്തിൽ അത്തരം കോഡ് നിങ്ങൾ കണ്ടിട്ടുണ്ടെന്ന് എനിക്ക് ഉറപ്പുണ്ട്. മനസ്സിനെ സംബന്ധിച്ചിടത്തോളം ഏറ്റവും മാനുഷികമായ പരീക്ഷണമല്ല.

മറുവശത്ത്, കുരങ്ങൻ മനുഷ്യൻ തന്റെ തലയിൽ യഥാർത്ഥ ലോകത്തിലെ വസ്തുക്കളെ അനുകരിക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്. അവന്റെ ഭാവനയിൽ, അയാൾക്ക് അവയെ ഒരുമിച്ച് തള്ളാനും അവയിൽ നിന്ന് പുതിയ വസ്തുക്കൾ കൂട്ടിച്ചേർക്കാനും അതേ രീതിയിൽ അവയെ വേർപെടുത്താനും കഴിയും. ഒരു പഴയ മോഡൽ കാർ സങ്കൽപ്പിക്കുക. നിങ്ങളുടെ ഭാവനയിൽ, നിങ്ങൾക്ക് വാതിൽ തുറക്കാനും ഡോർ ട്രിം അഴിക്കാനും വിൻഡോ ലിഫ്റ്റ് മെക്കാനിസങ്ങൾ കാണാനും കഴിയും, അതിനുള്ളിൽ ഗിയറുകളുണ്ടാകും. എന്നാൽ നിങ്ങൾക്ക് മെഷീന്റെ എല്ലാ ഘടകങ്ങളും ഒരേ സമയം ഒരു "ലിസ്റ്റിംഗിൽ" കാണാൻ കഴിയില്ല. കുറഞ്ഞത് "കുരങ്ങൻ മനുഷ്യന്" കഴിയില്ല.

അതിനാൽ, ഹ്യൂമൻ പ്രോഗ്രാമർമാർ സങ്കീർണ്ണമായ സംവിധാനങ്ങളെ സങ്കീർണ്ണവും പ്രവർത്തനക്ഷമമല്ലാത്തതുമായ ഘടകങ്ങളായി വിഘടിപ്പിക്കുന്നു. എന്നിരുന്നാലും, ഇത് വ്യത്യസ്ത രീതികളിൽ വിഘടിപ്പിക്കാം: പല പഴയ കാറുകളിലും, എയർ ഡക്റ്റ് വാതിലിലേക്ക് പോകുന്നു, ആധുനിക കാറുകളിൽ, ലോക്ക് ഇലക്ട്രോണിക്സിലെ ഒരു പരാജയം എഞ്ചിൻ ആരംഭിക്കുന്നതിൽ നിന്ന് തടയുന്നു, ഇത് അറ്റകുറ്റപ്പണി സമയത്ത് ഒരു പ്രശ്നമാകും.

ഇപ്പോൾ, SRP എന്നത് എങ്ങനെ വിഘടിപ്പിക്കാം, അതായത്, വിഭജന രേഖ എവിടെ വരയ്ക്കണം എന്ന് വിശദീകരിക്കുന്ന ഒരു തത്വമാണ്.

"ഉത്തരവാദിത്തം" എന്ന വിഭജന തത്വമനുസരിച്ച്, അതായത്, ചില വസ്തുക്കളുടെ ചുമതലകൾ അനുസരിച്ച് വിഘടിപ്പിക്കേണ്ടത് ആവശ്യമാണെന്ന് അദ്ദേഹം പറയുന്നു.

നമുക്ക് മദ്യപാനത്തിലേക്കും വിഘടിപ്പിക്കുമ്പോൾ മനുഷ്യന് ലഭിക്കുന്ന ഗുണങ്ങളിലേക്കും മടങ്ങാം:

• എല്ലാ തലത്തിലും കോഡ് വളരെ വ്യക്തമായിരിക്കുന്നു
• ഒരേസമയം നിരവധി പ്രോഗ്രാമർമാർക്ക് കോഡ് എഴുതാം (ഓരോരുത്തരും ഒരു പ്രത്യേക ഘടകം എഴുതുന്നു)
• ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് ലളിതമാക്കിയിരിക്കുന്നു - ലളിതമായ മൂലകം, അത് പരിശോധിക്കുന്നത് എളുപ്പമാണ്
• കോഡിന്റെ ഘടന ദൃശ്യമാകുന്നു - നിങ്ങൾക്ക് മാറ്റിസ്ഥാപിക്കാം ഡ്രിങ്ക് ഓപ്പറേഷൻ ഒരു മദ്യപാനി മേശയ്ക്കടിയിൽ ദ്രാവകം ഒഴിക്കുന്ന ഒരു ഓപ്പറേഷനിലേക്ക്. അല്ലെങ്കിൽ നിങ്ങൾ വൈനും വെള്ളവും അല്ലെങ്കിൽ വോഡ്കയും ബിയറും കലർത്തുന്ന ഒരു ഓപ്പറേഷൻ ഉപയോഗിച്ച് പകരുന്ന പ്രവർത്തനം മാറ്റിസ്ഥാപിക്കുക. ബിസിനസ്സ് ആവശ്യകതകളെ ആശ്രയിച്ച്, രീതി കോഡ് സ്പർശിക്കാതെ തന്നെ നിങ്ങൾക്ക് എല്ലാം ചെയ്യാൻ കഴിയും ടിപ്ലർ.ആക്ട്.
• ഈ പ്രവർത്തനങ്ങളിൽ നിന്ന് നിങ്ങൾക്ക് ആഹ്ലാദം മടക്കാൻ കഴിയും (ഉപയോഗിക്കുന്നത് മാത്രം ടേക്ക്ബിറ്റ് ഓപ്പറേഷൻ), മദ്യം (ഉപയോഗിക്കുന്നത് മാത്രം ഡ്രിങ്ക് ഓപ്പറേഷൻ കുപ്പിയിൽ നിന്ന് നേരിട്ട്) കൂടാതെ മറ്റ് പല ബിസിനസ് ആവശ്യകതകളും നിറവേറ്റുക.

(ഓ, ഇത് ഇതിനകം ഒരു 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- യുടെ മറ്റൊരു നിർവചനം കണ്ടെത്തുക - ഏക മാറ്റത്തിനുള്ള തത്വം.

എസ്‌സി‌പി പ്രസ്‌താവിക്കുന്നു "ഒരു മൊഡ്യൂളിന് മാറ്റാൻ ഒരേയൊരു കാരണമുണ്ട്". അതായത്, "ഉത്തരവാദിത്തമാണ് മാറ്റത്തിനുള്ള കാരണം."

(യഥാർത്ഥ നിർവചനം കൊണ്ടുവന്ന ആൺകുട്ടികൾ കുരങ്ങൻ മനുഷ്യന്റെ ടെലിപതിക് കഴിവുകളിൽ ആത്മവിശ്വാസമുള്ളവരാണെന്ന് തോന്നുന്നു)

ഇപ്പോൾ എല്ലാം ശരിയായി വരുന്നു. വെവ്വേറെ, നമുക്ക് ഒഴിക്കുന്നതും കുടിക്കുന്നതും ലഘുഭക്ഷണം കഴിക്കുന്നതുമായ നടപടിക്രമങ്ങൾ മാറ്റാൻ കഴിയും, എന്നാൽ മദ്യപാനിയിൽ തന്നെ പ്രവർത്തനങ്ങളുടെ ക്രമവും ഘടനയും മാറ്റാൻ മാത്രമേ കഴിയൂ, ഉദാഹരണത്തിന്, കുടിക്കുന്നതിനുമുമ്പ് ലഘുഭക്ഷണം നീക്കുകയോ ഒരു ടോസ്റ്റിന്റെ വായന ചേർക്കുകയോ ചെയ്യുക.

"ഫോർവേഡ് ആന്റ് ഓൺലി ഫോർവേഡ്" എന്ന സമീപനത്തിൽ, മാറ്റാൻ കഴിയുന്നതെല്ലാം മെത്തേഡിൽ മാത്രം മാറ്റപ്പെടുന്നു നിയമം. കുറച്ച് ലോജിക്ക് ഉള്ളപ്പോൾ ഇത് വായിക്കാവുന്നതും ഫലപ്രദവുമാണ്, പക്ഷേ പലപ്പോഴും ഇത് 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 യുടെ മൂന്നാമത്തെ നിർവചനത്തിന്റെ നിലനിൽപ്പിനെക്കുറിച്ച് പഠിക്കാതെ:

"ഏക ഉത്തരവാദിത്ത തത്വം അത് പ്രസ്താവിക്കുന്നു മാറ്റത്തിന് സമാനമായ കാര്യങ്ങൾ ഒരിടത്ത് സൂക്ഷിക്കണം". അഥവാ "എന്ത് മാറ്റങ്ങളാണ് ഒരുമിച്ച് ഒരിടത്ത് സൂക്ഷിക്കേണ്ടത്"

അതായത്, നമ്മൾ ഒരു പ്രവർത്തനത്തിന്റെ ലോഗിംഗ് മാറ്റുകയാണെങ്കിൽ, അത് ഒരിടത്ത് മാറ്റണം.

ഇത് വളരെ പ്രധാനപ്പെട്ട ഒരു കാര്യമാണ് - മുകളിൽ പറഞ്ഞിരിക്കുന്ന എസ്ആർപിയുടെ എല്ലാ വിശദീകരണങ്ങളും തരങ്ങൾ തകർക്കുമ്പോൾ അവയെ തകർക്കേണ്ടത് ആവശ്യമാണെന്ന് പറഞ്ഞതിനാൽ, അതായത്, അവർ ഒബ്ജക്റ്റിന്റെ വലുപ്പത്തിന് ഒരു “മുകളിൽ പരിധി” ഏർപ്പെടുത്തി, ഇപ്പോൾ ഞങ്ങൾ ഇതിനകം ഒരു "താഴ്ന്ന പരിധി" യെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്. മറ്റൊരു വാക്കിൽ, എസ്ആർപിക്ക് "ചതക്കുമ്പോൾ തകർക്കൽ" മാത്രമല്ല, അത് അമിതമാക്കേണ്ടതില്ല - "ഇന്റർലോക്ക് ചെയ്യുന്ന കാര്യങ്ങൾ തകർക്കരുത്". ഓക്കാമിന്റെ റേസറും കുരങ്ങനും തമ്മിലുള്ള മഹായുദ്ധമാണിത്!

ഇനി കുടിയന് സുഖം തോന്നണം. 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 ബിസിനസ്സ് പ്രവർത്തനങ്ങൾ കൂടി ഉണ്ടായിരുന്നു. മിക്കവാറും എല്ലാവർക്കും അക്കൗണ്ട് ഒബ്ജക്റ്റ് ആവശ്യമായിരുന്നു. പകുതി കോളുകളിലും പോയിന്റ് ഐഡിയും ക്ലയന്റ് നാമവും ആവശ്യമായിരുന്നു.

ഒരു മണിക്കൂർ റീഫാക്‌ടറിംഗിന് ശേഷം, ഇൻഫ്രാസ്ട്രക്ചർ കോഡും അക്കൗണ്ടുമായി പ്രവർത്തിക്കുന്നതിന്റെ ചില സൂക്ഷ്മതകളും പ്രത്യേക രീതികൾ/ക്ലാസുകളായി വേർതിരിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഗോഡ് മെത്തേഡ് ഇത് എളുപ്പമാക്കി, പക്ഷേ 100 വരി കോഡ് അവശേഷിക്കുന്നു, അത് അഴിച്ചുവെക്കാൻ താൽപ്പര്യമില്ല.

ഈ "കനംകുറഞ്ഞ" രീതിയുടെ സാരാംശം ഒരു ബിസിനസ്സ് അൽഗോരിതം ആണെന്ന് കുറച്ച് ദിവസങ്ങൾക്ക് ശേഷം മാത്രമാണ് വ്യക്തമായത്. സാങ്കേതിക സവിശേഷതകളുടെ യഥാർത്ഥ വിവരണം വളരെ സങ്കീർണ്ണമായിരുന്നു. ഈ രീതിയെ കഷണങ്ങളായി തകർക്കാനുള്ള ശ്രമമാണ് എസ്ആർപിയെ ലംഘിക്കുന്നത്, തിരിച്ചും അല്ല.

ഔപചാരികത.

നമ്മുടെ മദ്യപാനിയെ വെറുതെ വിടാനുള്ള സമയമാണിത്. നിങ്ങളുടെ കണ്ണുനീർ ഉണക്കുക - ഞങ്ങൾ തീർച്ചയായും ഒരു ദിവസം അതിലേക്ക് മടങ്ങും. ഇപ്പോൾ ഈ ലേഖനത്തിൽ നിന്നുള്ള അറിവ് ഔപചാരികമാക്കാം.

ഫോർമലിസം 1. എസ്ആർപിയുടെ നിർവ്വചനം

1. ഘടകങ്ങൾ വേർതിരിക്കുക, അങ്ങനെ അവ ഓരോന്നും ഒരു കാര്യത്തിന് ഉത്തരവാദികളാണ്.
2. ഉത്തരവാദിത്തം എന്നത് "മാറ്റത്തിനുള്ള കാരണം" ആണ്. അതായത്, ബിസിനസ്സ് യുക്തിയുടെ അടിസ്ഥാനത്തിൽ ഓരോ ഘടകത്തിനും മാറ്റത്തിന് ഒരു കാരണം മാത്രമേയുള്ളൂ.
3. ബിസിനസ് ലോജിക്കിൽ സാധ്യമായ മാറ്റങ്ങൾ. പ്രാദേശികവൽക്കരിക്കപ്പെടണം. സമകാലികമായി മാറുന്ന ഘടകങ്ങൾ സമീപത്തായിരിക്കണം.

ഔപചാരികത 2. ആവശ്യമായ സ്വയം പരിശോധന മാനദണ്ഡം.

SRP നിറവേറ്റുന്നതിനുള്ള മതിയായ മാനദണ്ഡങ്ങൾ ഞാൻ കണ്ടിട്ടില്ല. എന്നാൽ ആവശ്യമായ വ്യവസ്ഥകൾ ഉണ്ട്:

1) ഈ ക്ലാസ്/രീതി/മൊഡ്യൂൾ/സേവനം എന്താണ് ചെയ്യുന്നതെന്ന് സ്വയം ചോദിക്കുക. നിങ്ങൾ ഒരു ലളിതമായ നിർവചനത്തിൽ ഉത്തരം നൽകണം. ( നന്ദി ബ്രൈറ്റോറി )

വിശദീകരണങ്ങൾ

എന്നിരുന്നാലും, ചിലപ്പോൾ ഒരു ലളിതമായ നിർവചനം കണ്ടെത്തുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്

2) ഒരു ബഗ് പരിഹരിക്കുന്നതോ പുതിയ ഫീച്ചർ ചേർക്കുന്നതോ കുറഞ്ഞ എണ്ണം ഫയലുകൾ/ക്ലാസുകളെ ബാധിക്കുന്നു. അനുയോജ്യമായി - ഒന്ന്.

വിശദീകരണങ്ങൾ

ഉത്തരവാദിത്തം (ഒരു ഫീച്ചർ അല്ലെങ്കിൽ ബഗ്) ഒരു ഫയലിൽ/ക്ലാസിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്നതിനാൽ, എവിടെയാണ് നോക്കേണ്ടതെന്നും എന്ത് എഡിറ്റ് ചെയ്യണമെന്നും നിങ്ങൾക്ക് കൃത്യമായി അറിയാം. ഉദാഹരണത്തിന്: ലോഗിംഗ് പ്രവർത്തനങ്ങളുടെ ഔട്ട്പുട്ട് മാറ്റുന്നതിനുള്ള സവിശേഷതയ്ക്ക് ലോഗർ മാത്രം മാറ്റേണ്ടതുണ്ട്. ബാക്കിയുള്ള കോഡുകളിലൂടെ പ്രവർത്തിപ്പിക്കേണ്ട ആവശ്യമില്ല.

മുമ്പത്തേതിന് സമാനമായി ഒരു പുതിയ യുഐ നിയന്ത്രണം ചേർക്കുന്നതാണ് മറ്റൊരു ഉദാഹരണം. 10 വ്യത്യസ്ത എന്റിറ്റികളും 15 വ്യത്യസ്ത കൺവെർട്ടറുകളും ചേർക്കാൻ ഇത് നിങ്ങളെ പ്രേരിപ്പിക്കുകയാണെങ്കിൽ, നിങ്ങൾ അത് അമിതമായി ചെയ്യുന്നതായി തോന്നുന്നു.

3) നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ വ്യത്യസ്ത സവിശേഷതകളിൽ നിരവധി ഡവലപ്പർമാർ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, ഒരു ലയന വൈരുദ്ധ്യത്തിനുള്ള സാധ്യത, അതായത്, ഒരേ ഫയൽ/ക്ലാസ് ഒരേ സമയം നിരവധി ഡവലപ്പർമാർ മാറ്റാനുള്ള സാധ്യത വളരെ കുറവാണ്.

വിശദീകരണങ്ങൾ

“മേശയുടെ അടിയിൽ വോഡ്ക ഒഴിക്കുക” എന്ന ഒരു പുതിയ പ്രവർത്തനം ചേർക്കുമ്പോൾ, നിങ്ങൾ ലോഗറിനെയും മദ്യപാനത്തിന്റെയും ഒഴിക്കുന്നതിന്റെയും പ്രവർത്തനത്തെ ബാധിക്കണമെങ്കിൽ, ഉത്തരവാദിത്തങ്ങൾ വളഞ്ഞതായി വിഭജിക്കപ്പെട്ടതായി തോന്നുന്നു. തീർച്ചയായും, ഇത് എല്ലായ്പ്പോഴും സാധ്യമല്ല, എന്നാൽ ഈ കണക്ക് കുറയ്ക്കാൻ ശ്രമിക്കണം.

4) ബിസിനസ്സ് ലോജിക് (ഒരു ഡവലപ്പറിൽ നിന്നോ മാനേജരിൽ നിന്നോ) വ്യക്തമാക്കുന്ന ഒരു ചോദ്യം ചോദിക്കുമ്പോൾ, നിങ്ങൾ കർശനമായി ഒരു ക്ലാസ്/ഫയലിൽ പോയി അവിടെ നിന്ന് മാത്രമേ വിവരങ്ങൾ സ്വീകരിക്കൂ.

വിശദീകരണങ്ങൾ

ഫീച്ചറുകളും നിയമങ്ങളും അൽഗരിതങ്ങളും ഒതുക്കമുള്ളവയാണ്, ഓരോന്നും ഒരിടത്ത്, കോഡ് സ്‌പെയ്‌സിലുടനീളം ഫ്ലാഗുകൾ ഉപയോഗിച്ച് ചിതറിക്കിടക്കുന്നില്ല.

5) നാമകരണം വ്യക്തമാണ്.

വിശദീകരണങ്ങൾ

ഞങ്ങളുടെ ക്ലാസ് അല്ലെങ്കിൽ രീതി ഒരു കാര്യത്തിന് ഉത്തരവാദിയാണ്, ഉത്തരവാദിത്തം അതിന്റെ പേരിൽ പ്രതിഫലിക്കുന്നു

AllManagersManagerService - മിക്കവാറും ഒരു ദൈവ ക്ലാസ്
പ്രാദേശിക പേയ്‌മെന്റ് - ഒരുപക്ഷേ ഇല്ല

ഔപചാരികത 3. ഓക്കാം-ഫസ്റ്റ് ഡെവലപ്‌മെന്റ് മെത്തഡോളജി.

രൂപകൽപ്പനയുടെ തുടക്കത്തിൽ, കുരങ്ങൻ മനുഷ്യന് അറിയില്ല, പ്രശ്നം പരിഹരിക്കപ്പെടുന്നതിന്റെ എല്ലാ സൂക്ഷ്മതകളും അനുഭവപ്പെടുന്നില്ല, മാത്രമല്ല ഒരു തെറ്റ് വരുത്താനും കഴിയും. നിങ്ങൾക്ക് വ്യത്യസ്ത രീതികളിൽ തെറ്റുകൾ വരുത്താം:

• വ്യത്യസ്ത ഉത്തരവാദിത്തങ്ങൾ ലയിപ്പിച്ചുകൊണ്ട് ഒബ്‌ജക്‌റ്റുകൾ വളരെ വലുതാക്കുക
• ഒരൊറ്റ ഉത്തരവാദിത്തത്തെ പല തരങ്ങളായി വിഭജിച്ച് പുനർനിർമ്മിക്കുക
• ഉത്തരവാദിത്തത്തിന്റെ അതിരുകൾ തെറ്റായി നിർവചിക്കുക

നിയമം ഓർത്തിരിക്കേണ്ടത് പ്രധാനമാണ്: "ഒരു വലിയ തെറ്റ് ചെയ്യുന്നതാണ് നല്ലത്" അല്ലെങ്കിൽ "നിങ്ങൾക്ക് ഉറപ്പില്ലെങ്കിൽ, അത് വിഭജിക്കരുത്." ഉദാഹരണത്തിന്, നിങ്ങളുടെ ക്ലാസിൽ രണ്ട് ഉത്തരവാദിത്തങ്ങൾ അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, അത് ഇപ്പോഴും മനസ്സിലാക്കാവുന്നതേയുള്ളൂ, കൂടാതെ ക്ലയന്റ് കോഡിലെ ഏറ്റവും ചെറിയ മാറ്റങ്ങളോടെ രണ്ടായി വിഭജിക്കാം. പല ഫയലുകളിലും സന്ദർഭം വ്യാപിച്ചിരിക്കുന്നതിനാലും ക്ലയന്റ് കോഡിൽ ആവശ്യമായ ഡിപൻഡൻസികളുടെ അഭാവവും കാരണം ഗ്ലാസ് കഷ്ണങ്ങളിൽ നിന്ന് ഒരു ഗ്ലാസ് കൂട്ടിച്ചേർക്കുന്നത് സാധാരണയായി കൂടുതൽ ബുദ്ധിമുട്ടാണ്.

ഒരു ദിവസം വിളിക്കാൻ സമയമായി

SRP-യുടെ വ്യാപ്തി OOP, SOLID എന്നിവയിൽ മാത്രം ഒതുങ്ങുന്നില്ല. രീതികൾ, പ്രവർത്തനങ്ങൾ, ക്ലാസുകൾ, മൊഡ്യൂളുകൾ, മൈക്രോ സർവീസുകൾ, സേവനങ്ങൾ എന്നിവയ്ക്ക് ഇത് ബാധകമാണ്. "figax-figax-and-prod", "rocket-science" വികസനം എന്നിവയ്ക്ക് ഇത് ബാധകമാണ്, ലോകത്തെ എല്ലായിടത്തും അൽപ്പം മെച്ചപ്പെട്ടതാക്കുന്നു. നിങ്ങൾ അതിനെക്കുറിച്ച് ചിന്തിക്കുകയാണെങ്കിൽ, ഇത് മിക്കവാറും എല്ലാ എഞ്ചിനീയറിംഗുകളുടെയും അടിസ്ഥാന തത്വമാണ്. മെക്കാനിക്കൽ എഞ്ചിനീയറിംഗ്, നിയന്ത്രണ സംവിധാനങ്ങൾ, എല്ലാ സങ്കീർണ്ണ സംവിധാനങ്ങളും ഘടകങ്ങളിൽ നിന്നാണ് നിർമ്മിച്ചിരിക്കുന്നത്, കൂടാതെ "അണ്ടർ ഫ്രാഗ്മെന്റേഷൻ" ഡിസൈനർമാർക്ക് വഴക്കം നഷ്ടപ്പെടുത്തുന്നു, "ഓവർ ഫ്രാഗ്മെന്റേഷൻ" ഡിസൈനർമാരുടെ കാര്യക്ഷമത നഷ്ടപ്പെടുത്തുന്നു, തെറ്റായ അതിരുകൾ അവർക്ക് യുക്തിയും മനസ്സമാധാനവും നഷ്ടപ്പെടുത്തുന്നു.

SRP പ്രകൃതിയാൽ കണ്ടുപിടിച്ചതല്ല, കൃത്യമായ ശാസ്ത്രത്തിന്റെ ഭാഗമല്ല. ഇത് നമ്മുടെ ജീവശാസ്ത്രപരവും മാനസികവുമായ പരിമിതികളിൽ നിന്ന് പുറത്തുകടക്കുന്നു.കുരങ്ങൻ-മനുഷ്യന്റെ തലച്ചോറ് ഉപയോഗിച്ച് സങ്കീർണ്ണമായ സംവിധാനങ്ങളെ നിയന്ത്രിക്കാനും വികസിപ്പിക്കാനുമുള്ള ഒരു മാർഗമാണിത്. ഒരു സിസ്റ്റം എങ്ങനെ വിഘടിപ്പിക്കാമെന്ന് അദ്ദേഹം നമ്മോട് പറയുന്നു. യഥാർത്ഥ രൂപീകരണത്തിന് ന്യായമായ തുക ടെലിപതി ആവശ്യമായിരുന്നു, എന്നാൽ ഈ ലേഖനം ചില പുകമറകൾ മായ്‌ക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

അവലംബം: www.habr.com