තනි වගකීම් මූලධර්මය භාවිතා කරන විට, “වගකීමක්” යනු කුමක්ද?

“තනි වගකීම් මූලධර්මය” යන්නෙන් “එක් දෙයක් පමණක් කරයි” යන්නෙන් අදහස් නොවන බව පැහැදිලිය. ඒ සඳහා ක්‍රම තිබේ.

public Interface CustomerCRUD
{
    public void Create(Customer customer);
    public Customer Read(int CustomerID);
    public void Update(Customer customer);
    public void Delete(int CustomerID);
}

බොබ් මාටින් පවසන්නේ "පන්ති වෙනස් වීමට ඇත්තේ එක් හේතුවක් පමණක්" බවයි. නමුත් ඔබ SOLID සඳහා නව ක්‍රමලේඛකයෙක් නම් ඔබේ මනස එතීම දුෂ්කර ය.

මම තවත් ප්‍රශ්නයකට පිළිතුරක් ලිව්වෙමි , එහිදී වගකීම් රැකියා මාතෘකා හා සමාන යැයි මම යෝජනා කළ අතර, මගේ කාරණය නිදර්ශනය කිරීම සඳහා අවන්හල් රූපකයක් භාවිතා කරමින් විෂය වටා නැටුවා. එහෙත්, එය තවමත් යමෙකුට තම පන්තිවල වගකීම් නිර්වචනය කිරීමට භාවිතා කළ හැකි මූලධර්ම සමූහයක් ප්‍රකාශ නොකරයි.

ඉතින් ඔබ එය කරන්නේ කෙසේද? එක් එක් පන්තියට තිබිය යුතු වගකීම් ඔබ තීරණය කරන්නේ කෙසේද සහ SRP සන්දර්භය තුළ ඔබ වගකීමක් නිර්වචනය කරන්නේ කෙසේද?

මේ වටා ඔබේ හිස ඔතා ගත හැකි එක් ක්‍රමයක් නම් අනාගත ව්‍යාපෘතිවල විභව අවශ්‍යතා වෙනස්වීම් ගැන සිතීම සහ ඒවා සිදු කිරීම සඳහා ඔබ කළ යුත්තේ කුමක්දැයි ඔබගෙන්ම විමසන්න.

උදාහරණයක් වශයෙන්:

නව ව්‍යාපාර අවශ්‍යතා: කැලිෆෝනියාවේ පිහිටා ඇති පරිශීලකයින්ට විශේෂ වට්ටමක් ලැබේ.

"හොඳ" වෙනස සඳහා උදාහරණය: වට්ටම් ගණනය කරන පන්තියක කේතය වෙනස් කිරීමට මට අවශ්‍යය.

අයහපත් වෙනස්කම් සඳහා උදාහරණය: පරිශීලක පන්තියේ කේතය වෙනස් කිරීමට මට අවශ්‍ය වන අතර, එම වෙනස මඟින් වට්ටම් සමඟ කිසිදු සම්බන්ධයක් නැති පන්ති ඇතුළුව පරිශීලක පන්තිය භාවිතා කරන වෙනත් පංති කෙරෙහි ප්‍රබල බලපෑමක් ඇති කරනු ඇත, උදා: බඳවා ගැනීම, ගණන් බැලීම සහ කළමනාකරණය.

හෝ:

නව ක්‍රියාකාරී නොවන අවශ්‍යතාව: අපි SQL සේවාදායකය වෙනුවට ඔරකල් භාවිතා කිරීම ආරම්භ කරමු

හොඳ වෙනසකට උදාහරණය: DTO වල දත්ත දිගටම පවතින්නේ කෙසේද යන්න තීරණය කරන දත්ත ප්‍රවේශ ස්ථරයේ තනි පන්තියක් වෙනස් කිරීමට අවශ්‍යය.

නරක වෙනසක්: මගේ ව්‍යාපාර ස්ථර පන්ති සියල්ලම SQL සේවාදායක-විශේෂිත තර්කනය අඩංගු බැවින් ඒවා වෙනස් කිරීමට මට අවශ්‍යය.

අනාගත විභව වෙනස්කම් වල අඩිපාර අවම කිරීම, වෙනස්වන ප්‍රදේශයකට කේතයේ එක් ප්‍රදේශයකට කේත වෙනස් කිරීම සීමා කිරීම මෙහි අදහසයි.

අවම වශයෙන්, ඔබේ පංති තාර්කික අවශ්‍යතා භෞතික අවශ්‍යතා වලින් වෙන් කළ යුතුය. උදාහරණ විශාල සමූහයක් තුළ සොයාගත හැක System.IOනාමඅවකාශය: භෞතික ධාරා (උදා: ක විවිධ වර්ගයේ, අපි එහි සොයා ගත හැකි FileStream, MemoryStreamහෝ NetworkStream) සහ විවිධ පාඨකයන් හා ලේඛකයන් ( BinaryWriter, TextWriter), තාර්කික මට්ටමේ කටයුතු කරන. අවශ්ය වෙනුවට: ඔවුන් මේ ආකාරයට වෙන් කිරීම මගින් අපි ගැලපීම් පිපිරීමක් වලක්වා FileStreamTextWriter, FileStreamBinaryWriter, NetworkStreamTextWriter, NetworkStreamBinaryWriter, MemoryStreamTextWriter, සහ MemoryStreamBinaryWriterඔබ ලේඛකයා සහ ඇළ දක්වා කිව සහ ඔබ ඔබට අවශ්ය දේ පුළුවන්,. පසුව අපට XmlWriterමතකය, ගොනුව සහ ජාලය සඳහා වෙනමම ක්‍රියාත්මක කිරීමකින් තොරව එය එකතු කළ හැකිය .

ප්‍රායෝගිකව කිවහොත්, වගකීම් වෙනස් විය හැකි දේවල් මගින් බැඳී ඇත . මේ අනුව, අවාසනාවකට මෙන්, වගකීමක් ඇති දේ වෙත ළඟා වීමට විද්‍යාත්මක හෝ සූත්‍රමය ක්‍රමයක් නොමැත. එය විනිශ්චය කැඳවීමකි.

එය ඔබගේ අත්දැකීම් අනුව වෙනස් විය හැකි දේ ගැන ය.

අපි මූලධර්මයේ භාෂාව අතිශයෝක්තියෙන්, වචනානුසාරයෙන්, ජ්වලිතයෙන් කෝපයට පත් කිරීමට නැඹුරු වෙමු. පංති වෙනස් විය හැකි නිසා හෝ ගැටලු බිඳ දැමීමට අපට උපකාරී වන රේඛා ඔස්සේ අපි පන්ති බෙදීමට නැඹුරු වෙමු. (අවසාන හේතුව සහජයෙන්ම නරක නැත.) එහෙත්, SRP පවතින්නේ ස්වකීය අභිමතය පරිදි නොවේ; එය නඩත්තු කළ හැකි මෘදුකාංගයක් නිර්මාණය කිරීම සඳහා සේවයේ යෙදී සිටී .

එබැවින් නැවතත්, බෙදීම් බොහෝ දුරට වෙනස්වීම් මගින් මෙහෙයවනු නොලැබේ නම්, යග්නි වඩාත් අදාළ වන්නේ නම් ඒවා සැබවින්ම SRP ^{1 සඳහා} සේවයේ යෙදෙන්නේ නැත. දෙකම එකම අවසාන ඉලක්කයට සේවය කරයි. මේ දෙකම විනිශ්චය කාරණා වේ - පළපුරුදු විනිශ්චය.

බොබ් මාමා මේ ගැන ලියන විට, ඔහු යෝජනා කරන්නේ “වෙනස ඉල්ලා සිටින්නේ කවුද” යන්න අනුව “වගකීම” ගැන අප සිතන ලෙසයි. වෙනත් වචන වලින් කිවහොත්, බී පක්ෂය වෙනසක් ඉල්ලා සිටි නිසා පක්ෂ A හි රැකියා අහිමිවීම අපට අවශ්‍ය නැත.

ඔබ මෘදුකාංග මොඩියුලයක් ලියන විට, වෙනස්කම් ඉල්ලා සිටින විට, එම වෙනස්වීම් ඇතිවිය හැක්කේ තනි පුද්ගලයකුගෙන් පමණක් නොව, පටු ලෙස අර්ථ දක්වා ඇති ව්‍යාපාර ශ්‍රිතයක් නියෝජනය කරන තනි තදින් සම්බන්ධ වූ පුද්ගලයින් කණ්ඩායමක් බව සහතික කිරීමට ඔබට අවශ්‍යය. ඔබේ මොඩියුලයන් සමස්තයක් ලෙස සංවිධානයේ සංකීර්ණතාවයන්ගෙන් හුදකලා කිරීමට ඔබට අවශ්‍ය වන අතර, එක් එක් මොඩියුලය එම ව්‍යාපාරයේ අවශ්‍යතාවයන්ට වගකිව යුතු (ප්‍රතිචාර දක්වන) ඔබේ පද්ධති සැලසුම් කරන්න. ( බොබ් මාමා - තනි වගකීම් මූලධර්මය )

හොඳ සහ පළපුරුදු සංවර්ධකයින්ට වෙනස්කම් සිදුවිය හැකි හැඟීමක් ඇත. කර්මාන්තය සහ සංවිධානය අනුව එම මානසික ලැයිස්තුව තරමක් වෙනස් වේ.

ඔබේ විශේෂිත ආයතනයේ, ඔබේ විශේෂිත ආයතනයේ වගකීමක් ඇති දේ අවසානයේ පළපුරුදු විනිශ්චය පිළිබඳ කාරණයකි . එය වෙනස් වීමට ඉඩ ඇති දේ ගැන ය. එක් අතකින්, මොඩියුලයේ අභ්‍යන්තර තර්කනය අයිති කාටද යන්න ගැන ය .

^{1. පැහැදිලිව කිවහොත්, එයින් අදහස් කරන්නේ ඔවුන් නරක බෙදීම් නොවන බවයි. ඒවා කේත කියවීමේ හැකියාව නාටකාකාර ලෙස වැඩි දියුණු කරන විශාල බෙදීම් විය හැකිය . එයින් කියවෙන්නේ ඔවුන් එස්ආර්පී විසින් මෙහෙයවනු නොලබන බවයි.}

මම අනුගමනය කරන්නේ "පන්ති වෙනස් වීමට ඇත්තේ එක් හේතුවක් පමණි" යන්නයි.

මට නම්, මෙයින් අදහස් කරන්නේ මගේ නිෂ්පාදන හිමිකරු විසින් ඉදිරිපත් කළ හැකි හාවුන් සහිත යෝජනා ක්‍රම ගැන සිතීමයි ("අපි ජංගම දුරකථනයට සහය දැක්විය යුතුයි!", "අපට වලාකුළට යා යුතුයි!", "අපි චීන භාෂාවට සහාය දැක්විය යුතුයි!"). හොඳ සැලසුම් මඟින් මෙම යෝජනා ක්‍රමවල බලපෑම කුඩා ප්‍රදේශවලට සීමා කරනු ඇති අතර ඒවා ඉටු කිරීමට සාපේක්ෂව පහසු වේ. නරක මෝස්තර යන්නෙන් අදහස් කරන්නේ බොහෝ කේත වෙත ගොස් අවදානම් සහගත වෙනස්කම් සිදු කිරීමයි.

එම පිස්සු යෝජනා ක්‍රමවල සම්භාවිතාව නිසියාකාරව තක්සේරු කිරීමට මා සොයාගත් එකම දෙය පළපුරුද්දයි - මන්දයත් එක් පහසු කිරීමක් තවත් දෙදෙනෙකු අමාරු කළ හැකි බැවිනි - සහ මෝස්තරයක යහපත්කම ඇගයීමයි. පළපුරුදු ක්‍රමලේඛකයින්ට කේතය වෙනස් කිරීම සඳහා කළ යුතු දේ, බූරුවාට දෂ්ට කිරීමට අවට ඇති දේ සහ දේවල් පහසු කරවන උපක්‍රම මොනවාදැයි සිතාගත හැකිය. පළපුරුදු ක්‍රමලේඛකයින්ට නිෂ්පාදන හිමිකරු පිස්සු දේවල් ඉල්ලා සිටින විට ඔවුන් කෙතරම් ඉස්කුරුප්පු කරනවාද යන්න පිළිබඳ හොඳ හැඟීමක් ඇත.

ප්රායෝගිකව, ඒකක පරීක්ෂණ මෙහි උපකාර වන බව මට පෙනී ගියේය. ඔබේ කේතය නම්යශීලී නම්, එය පරීක්ෂා කිරීම දුෂ්කර වනු ඇත. ඔබට විහිළු හෝ වෙනත් පරීක්ෂණ දත්ත එන්නත් කළ නොහැකි නම්, ඔබට බොහෝ විට එම SupportChineseකේතය එන්නත් කිරීමට නොහැකි වනු ඇත .

තවත් රළු මෙට්‍රික් එකක් වන්නේ විදුලි සෝපානයයි. සාම්ප්‍රදායික සෝපාන තණතීරු යනු "ඔබ ආයෝජකයෙකු සමඟ සෝපානයක සිටියේ නම්, ඔබට අදහසක් මත ඔහුව විකිණීමට හැකිද?". ආරම්භකයින්ට ඔවුන් කරන්නේ කුමක්ද යන්න පිළිබඳ සරල, කෙටි විස්තරයක් තිබිය යුතුය - ඔවුන්ගේ අවධානය කුමක්ද. ඒ හා සමානව, පන්ති (හා කාර්යයන්) ඔවුන් දේ සරල විස්තරයක් තිබිය යුතුය කරන්න . "මෙම පංතිය මඟින් ඔබට මෙම විශේෂිත අවස්ථා වලදී භාවිතා කළ හැකි ආකාරයේ ෆුබාර් කිහිපයක් ක්‍රියාත්මක කරයි". ඔබට වෙනත් සංවර්ධකයෙකුට පැවසිය හැකි දෙයක්: "මෙම පන්තිය පරිශීලකයින් නිර්මාණය කරයි". ඔබට වෙනත් සංවර්ධකයන් බව සන්නිවේදනය නොහැකි නම්, ඔබ කරන්නේ යන්නේ දෝෂ ලබා ගැනීමට.

කිසිවෙකු දන්නේ නැත. නැතහොත් අවම වශයෙන් අපට එක් අර්ථ දැක්වීමකට එකඟ විය නොහැක. එස්පීආර් (සහ වෙනත් SOLID මූලධර්ම) තරමක් මතභේදාත්මක වන්නේ එයයි.

මෘදුකාංග සංවර්ධකයෙකු සිය වෘත්තීය කාලය තුළ ඉගෙන ගත යුතු කුසලතා වලින් එකක් වන්නේ වගකීමක් හෝ නැති දෙයක් කුමක්දැයි සොයා ගැනීමට හැකිවීම යැයි මම තර්ක කරමි. ඔබ ලිවීමට හා සමාලෝචනය කිරීමට වැඩි කේතයක්, වැඩි අත්දැකීමක් ඔබට යමක් තනි හෝ බහු වගකීම්ද යන්න තීරණය කිරීමට සිදුවනු ඇත. නැතහොත් කේතයේ වෙනම කොටස් හරහා තනි වගකීමක් කැඩී ඇත්නම්.

SRP හි මූලික අරමුණ දැඩි පාලනයක් නොවන බව මම තර්ක කරමි. එය කේතයේ සහජීවනය ගැන සැලකිලිමත් විය යුතු බවත්, කුමන කේතය සංයුක්තද යන්න සහ නැති දේ තීරණය කිරීම සඳහා සෑම විටම යම් සවි effort ් effort ාණික උත්සාහයක් දැරීම අපට මතක් කර දීමයි.

"වගකීම" යන පදය රූපකයක් ලෙස ප්‍රයෝජනවත් යැයි මම සිතන්නේ මෘදුකාංගය කෙතරම් හොඳින් සංවිධානය වී ඇත්දැයි සොයා බැලීමට මෘදුකාංගය භාවිතා කිරීමට එය අපට අවසර දී ඇති බැවිනි. විශේෂයෙන්, මම මූලධර්ම දෙකක් කෙරෙහි අවධානය යොමු කරමි:

• වගකීම අධිකාරියට අනුකූල වේ.
• එකම දෙය සඳහා ආයතන දෙකක් වගකිව යුතු නොවේ.

මෙම මූලධර්ම දෙක අපට එකිනෙකාගෙන් play ත් වන නිසා වගකීම අර්ථවත් ලෙස ඉටු කිරීමට ඉඩ දෙයි. ඔබ වෙනුවෙන් යමක් කිරීමට කේත කැබැල්ලක් බලගන්වන්නේ නම්, එය කරන දෙයට වගකීමක් තිබිය යුතුය. මෙය පන්තියකට වර්ධනය විය යුතු වගකීම ඇති කරයි, එය "වෙනස් වීමට එක් හේතුවක්" පුළුල් හා පුළුල් පරාසයන් දක්වා පුළුල් කරයි. කෙසේ වෙතත්, ඔබ දේවල් පුළුල් කරන විට, ඔබ ස්වභාවිකවම එකම දේ සඳහා බහුවිධ ආයතන වගකිව යුතු තත්වයන් කරා දිව යයි. මෙය සැබෑ ජීවිතයේ වගකීම පිළිබඳ ගැටළු වලින් පිරී ඇති බැවින් නියත වශයෙන්ම එය කේතීකරණයේ ද ගැටළුවක් වේ. මෙහි ප්‍රති As ලයක් වශයෙන්, ඔබ වගකීම අනුපිටපත් නොකළ පාර්සල් වලට බෙදන බැවින් මෙම මූලධර්මය විෂය පථයන් පටු වීමට හේතු වේ.

මේ දෙකට අමතරව, තුන්වන මූලධර්මය සාධාරණ බව පෙනේ:

• වගකීම පැවරිය හැකිය

නැවුම් ලෙස සකස් කරන ලද වැඩසටහනක් සලකා බලන්න ... හිස් පෙත්තක්. මුලදී, ඔබට ඇත්තේ එක් ආයතනයක් පමණි, එය සමස්තයක් ලෙස වැඩසටහන වේ. එය සියල්ලටම වගකිව යුතුය. ස්වාභාවිකවම යම් අවස්ථාවක දී ඔබ කාර්යයන් හෝ පන්ති වෙත වගකීම පැවරීම ආරම්භ කරනු ඇත. මෙම අවස්ථාවෙහිදී, පළමු නීති දෙක ක්‍රියාත්මක වන අතර එම වගකීම සමතුලිත කිරීමට ඔබට බල කෙරේ. ඔවුන්ගේ කණ්ඩායමේ tivity ලදායිතාව සඳහා කළමනාකරුවෙකු වගකිව යුතු සේම, ඉහළ මට්ටමේ වැඩසටහන තවමත් සමස්ත ප්‍රතිදානය සඳහා වගකිව යුතු ය, නමුත් සෑම උප ආයතනයකටම වගකීම පවරා ඇති අතර, එම වගකීම ඉටු කිරීමේ බලය ඇත.

අමතර ප්‍රසාද දීමනාවක් ලෙස, මෙය SOLID විශේෂයෙන් කළ යුතු ඕනෑම ආයතනික මෘදුකාංග සංවර්ධනයකට අනුකූල වේ. පෘථිවියේ සෑම සමාගමකටම වගකීම පවරන්නේ කෙසේද යන්න පිළිබඳ යම් සංකල්පයක් ඇති අතර ඔවුන් සියල්ලෝම එයට එකඟ නොවෙති. ඔබේ සමාගමේ නියෝජිතයින් සිහිපත් වන අයුරින් ඔබ ඔබේ මෘදුකාංගය තුළ වගකීම පවරා දෙන්නේ නම්, අනාගත සංවර්ධකයින්ට මෙම සමාගමේ ඔබ කටයුතු කරන ආකාරය සමඟ වේගවත් වීමට පහසු වනු ඇත.

දී මෙම සමුළුව යේල් සරසවියේ, අංකල් බොබ් මෙම ලබා දෙන විසුළු උදාහරණයක්:

Employeeවෙනස් වීමට හේතු තුනක්, වෙනස් කිරීමේ අවශ්‍යතා ප්‍රභව තුනක් ඇති බව ඔහු පවසයි. මෙම හාස්‍යජනක හා දිවෙන් කම්මුලට , නමුත් නිදර්ශන කෙසේ වෙතත්, පැහැදිලි කිරීම:

• නම් CalcPay()ක්රමය දෝෂයක් ඇති අතර එක්සත් ජනපදයේ $ ක සමාගම මිලියන ගණනක් පාඩු, සම්බන්ධව CFO ඔබ වෙඩි ඇත .

• ReportHours()ක්‍රමයේ දෝෂයක් ඇති අතර සමාගමට ඇමරිකානු ඩොලර් මිලියන ගණනක් වැය වුවහොත් , COO ඔබට වෙඩි තබයි .

• WriteEmmployee() ක්‍රමයට දෝෂයක් තිබේ නම් එය දත්ත විශාල ප්‍රමාණයක් මකා දැමීමට හේතු වන අතර සමාගමට ඇමරිකානු ඩොලර් මිලියන ගණනක් වැය වේ නම්, CTO ඔබට වෙඩි තබයි .

ඒ නිසා හැකි වූ එකම පන්තිය තුළ වියදම් අධික දෝෂ සඳහා ඔබ වෙඩි විවිධ සී මට්ටමේ execs තුනක් සහිත පන්ති බොහෝ වගකීම් ඇත බවයි.

එස්ආර්පී උල්ලං violation නය කිරීම විසඳන මෙම විසඳුම ඔහු ලබා දෙයි, නමුත් තවමත් වීඩියෝවේ පෙන්වා නැති ඩීඅයිපී උල්ලං violation නය කිරීම විසඳිය යුතුය.

"වෙනස් වීමට හේතු" වලට වඩා දේවල් බෙදීමේ වඩා හොඳ ක්‍රමයක් නම්, ක්‍රියාවන් දෙකක් (හෝ වැඩි ගණනක්) සිදු කිරීමට අවශ්‍ය කේතයට වෙනම වස්තු යොමු කිරීමක් අවශ්‍ය විය යුතු යැයි සිතීම අර්ථවත් දැයි සිතීමෙන් ආරම්භ කිරීමයි. එක් එක් ක්‍රියාව සඳහා, සහ එක් ක්‍රියාවක් කළ හැකි නමුත් අනෙක් ක්‍රියාවෙන් කළ නොහැකි පොදු වස්තුවක් තිබීම ප්‍රයෝජනවත් ද යන්න.

ප්‍රශ්න දෙකටම පිළිතුරු ඔව් නම්, එයින් ඇඟවෙන්නේ ක්‍රියාවන් වෙනම පන්ති විසින් කළ යුතු බවයි. ප්‍රශ්න දෙකටම පිළිතුරු නැත නම්, එයින් ඇඟවෙන්නේ පොදු දෘෂ්ටි කෝණයකින් එක් පන්තියක් තිබිය යුතු බවයි; ඒ සඳහා වන කේතය අනවශ්‍ය නම්, එය අභ්‍යන්තරව පුද්ගලික පංතිවලට බෙදිය හැකිය. පළමු ප්රශ්නයට පිළිතුරු නැත නම්, නමුත් දෙවන ඔව්, එක් එක් පියවර සඳහා වෙනම පන්ති තිබිය යුතු ප්ලස් අන් අවස්ථා සඳහා යොමු ඇතුළත් වන සංයුක්ත පන්ති.

යමෙකුට මුදල් ලේඛනයේ යතුරු පෑඩය, බීපර්, සංඛ්‍යා කියවීම, රිසිට්පත් මුද්‍රණ යන්ත්‍රය සහ මුදල් ලාච්චුව සඳහා වෙනම පන්ති තිබේ නම් සහ සම්පූර්ණ මුදල් ලේඛනයක් සඳහා සංයුක්ත පංතියක් නොමැති නම්, ගනුදෙනුවක් සැකසීමට නියමිත කේතය අහම්බෙන් ආයාචනා කිරීම අවසන් විය හැකිය. එක් යන්ත්‍රයක යතුරු පෑඩයකින් ආදානය ලබා ගන්නා, දෙවන යන්ත්‍රයේ බීපර් එකෙන් ශබ්දය නිපදවන, තුන්වන යන්ත්‍රයේ සංදර්ශකයෙහි සංඛ්‍යා පෙන්වන, සිව්වන යන්ත්‍රයේ මුද්‍රණ යන්ත්‍රයේ රිසිට්පතක් මුද්‍රණය කරන, සහ පස්වන යන්ත්‍රයේ මුදල් ලාච්චුවක් මතු කරන ආකාරය. එම සෑම උප ශ්‍රිතයක්ම වෙනම පන්තියක් විසින් හසුරුවනු ලැබිය හැකි නමුත් ඒවාට සම්බන්ධ වන සංයුක්ත පන්තියක් ද තිබිය යුතුය. සංයුක්ත පන්තිය හැකි තරම් තර්කනය සං constitu ටක පංති වෙත පැවරිය යුතුය,

එක් එක් පන්තියේ “වගකීම” එක්කෝ යම් තාත්වික තර්කනයක් ඇතුළත් කිරීම හෝ එසේ නොමැති වෙනත් පන්ති සඳහා පොදු ඇමුණුම් ලක්ෂ්‍යයක් සැපයීම යැයි කෙනෙකුට පැවසිය හැකිය, නමුත් වැදගත් වන්නේ සේවාදායක කේතය පන්තියක් දෙස බැලිය යුතු ආකාරය පිළිබඳව පළමුව සහ ප්‍රධාන වශයෙන් අවධානය යොමු කිරීමයි. ග්‍රාහක කේතයට යමක් තනි වස්තුවක් ලෙස දැකීම අර්ථවත් නම්, ග්‍රාහක කේතය එය තනි වස්තුවක් ලෙස දැකිය යුතුය.

SRP නිවැරදි කර ගැනීමට අපහසුය. එය බොහෝ දුරට ඔබගේ කේතයට 'රැකියා' පැවරීම සහ සෑම කොටසකටම පැහැදිලි වගකීම් ඇති බවට වග බලා ගැනීම ය. සැබෑ ජීවිතයේ දී මෙන්, සමහර අවස්ථාවල මිනිසුන් අතර වැඩ බෙදීම තරමක් ස්වාභාවික විය හැකි නමුත් වෙනත් අවස්ථාවල දී එය සැබවින්ම උපක්‍රමශීලී විය හැකිය, විශේෂයෙන් ඔබ ඔවුන් (හෝ වැඩ) නොදන්නේ නම්.

පළමුවෙන් ක්‍රියාත්මක වන සරල කේතයක් ලිවීමට මම ඔබට නිතරම නිර්දේශ කරමි , පසුව ටිකක් ප්‍රතික්‍රියා කරන්න: ටික කලකට පසු කේත පොකුරු ස්වභාවිකව සිදුවන ආකාරය බැලීමට ඔබ නැඹුරු වනු ඇත. කේතය (හෝ පුද්ගලයින්) සහ කළ යුතු වැඩ දැන ගැනීමට පෙර වගකීම් බල කිරීම වැරැද්දක් යැයි මම සිතමි.

ඔබ දකින එක් දෙයක් නම් මොඩියුලය ඕනෑවට වඩා වැඩ කිරීමට පටන් ගන්නා විට එය නිදොස් කිරීම / නඩත්තු කිරීම අසීරු වීමයි. ප්‍රතික්‍රියාකාරකයට මොහොත මෙයයි; මූලික කාර්යය කුමක් විය යුතුද සහ වෙනත් මොඩියුලයකට ලබා දිය හැකි කාර්යයන් මොනවාද? උදාහරණයක් ලෙස, එය ආරක්ෂක චෙක්පත් සහ අනෙක් කාර්යයන් හැසිරවිය යුතුද, නැතහොත් ඔබ මුලින් වෙනත් තැනක ආරක්ෂක පරීක්ෂාවන් කළ යුතුද, නැතහොත් මෙය කේතය වඩාත් සංකීර්ණ කරයිද?

ඕනෑවට වඩා වක්‍රාකාරයන් භාවිතා කරන්න, එය නැවත අවුල් ජාලයක් බවට පත්වේ ... වෙනත් මූලධර්ම සම්බන්ධයෙන් ගත් කල, මෙය KISS, YAGNI වැනි වෙනත් අය සමඟ ගැටෙනු ඇත. සියල්ල සමතුලිත වේ.

“තනි වගකීම් මූලධර්මය” සමහර විට ව්‍යාකූල නමකි. "වෙනස් කිරීමට එක් හේතුවක් පමණක්" මූලධර්මය පිළිබඳ වඩා හොඳ විස්තරයක් වන නමුත් වරදවා වටහා ගැනීම තවමත් පහසුය. අපි කතා කරන්නේ වස්තූන් ධාවන වේලාවේ තත්වය වෙනස් වීමට හේතුව කුමක්දැයි කීම ගැන නොවේ. අනාගතයේදී සංවර්ධකයින්ට කේතය වෙනස් කිරීමට සිදුවිය හැකි දේ ගැන අපි සලකා බලමු.

අප දෝෂයක් නිවැරදි නොකරන්නේ නම්, වෙනස සිදුවන්නේ නව හෝ වෙනස් වූ ව්‍යාපාරික අවශ්‍යතාවයක් නිසා ය. ඔබට කේතයෙන් පිටත සිතා බැලිය යුතු අතර, අවශ්‍යතා ස්වාධීනව වෙනස් වීමට හේතු විය හැකි බාහිර සාධක මොනවාදැයි සිතා බලන්න . කියන්න:

• දේශපාලන තීරණයක් නිසා බදු අනුපාත වෙනස් වේ.
• සියලුම නිෂ්පාදනවල නම් වෙනස් කිරීමට අලෙවිකරණය තීරණය කරයි
• ප්‍රවේශ විය හැකි පරිදි UI නැවත සැලසුම් කළ යුතුය
• දත්ත සමුදාය ජනාකීර්ණ බැවින් ඔබට ප්‍රශස්තිකරණ කිහිපයක් කළ යුතුය
• ඔබට ජංගම යෙදුමකට ඉඩ දිය යුතුය
• සහ යනාදි...

විවිධ පංති වලට බලපාන ස්වාධීන සාධක ඔබට අවශ්‍යය. උදා: බදු අනුපාත නිෂ්පාදන නාම වලින් ස්වාධීනව වෙනස් වන බැවින්, වෙනස්කම් එකම පන්තිවලට බලපාන්නේ නැත. එසේ නොමැතිනම් ඔබ බදු වෙනස් කිරීමේ හඳුන්වාදීමේ අවදානම නිෂ්පාදන නාමකරණයේ දෝෂයක් වන අතර එය මොඩියුලර් පද්ධතියක් සමඟ මග හැරීමට ඔබට අවශ්‍ය දැඩි බැඳීමකි.

එබැවින් වෙනස් විය හැකි දේ කෙරෙහි පමණක් අවධානය යොමු නොකරන්න - අනාගතයේ දී ඕනෑම දෙයක් සිතාගත හැකි ලෙස වෙනස් විය හැකිය. ස්වාධීනව වෙනස් විය හැකි දේ කෙරෙහි අවධානය යොමු කරන්න . වෙනස්වීම් සාමාන්‍යයෙන් විවිධ නළුවන් නිසා සිදුවුවහොත් ඒවා ස්වාධීන වේ.

රැකියා මාතෘකා සමඟ ඔබේ ආදර්ශය නිවැරදි මාවතේ ඇත, නමුත් ඔබ එය වඩාත් වචනාර්ථයෙන් ගත යුතුය! අලෙවිකරණය කේතයේ වෙනස්කම් ඇති කළ හැකි නම් සහ මූල්‍යය වෙනත් වෙනස්කම් වලට හේතු විය හැකි නම්, මෙම වෙනස්වීම් එකම කේතයට බලපාන්නේ නැත, මන්ද මේවා වචනාර්ථයෙන් වෙනස් රැකියා මාතෘකා වන අතර එම නිසා වෙනස්කම් ස්වාධීනව සිදුවනු ඇත.

මෙම පදය නිර්මාණය කළ බොබ් මාමා උපුටා දැක්වීමට :

ඔබ මෘදුකාංග මොඩියුලයක් ලියන විට, වෙනස්කම් ඉල්ලා සිටින විට, එම වෙනස්කම් ඇතිවිය හැක්කේ තනි පුද්ගලයකුගෙන් පමණක් නොව, පටු ලෙස අර්ථ දක්වා ඇති ව්‍යාපාර ශ්‍රිතයක් නියෝජනය කරන තනි තදින් සම්බන්ධ වූ පුද්ගලයින් පිරිසකින් පමණක් බව සහතික කර ගැනීමට ඔබට අවශ්‍යය. ඔබේ මොඩියුලයන් සමස්තයක් ලෙස සංවිධානයේ සංකීර්ණතාවයන්ගෙන් හුදකලා කිරීමට ඔබට අවශ්‍ය වන අතර, එක් එක් මොඩියුලය එම ව්‍යාපාරයේ අවශ්‍යතාවයන්ට වගකිව යුතු (ප්‍රතිචාර දක්වන) ඔබේ පද්ධති සැලසුම් කරන්න.

එබැවින් සාරාංශගත කිරීම: “වගකීමක්” යනු තනි ව්‍යාපාර කාර්යයක් ඉටු කිරීමයි. එක් නළුවෙකුට වඩා ඔබට පන්තියක් වෙනස් කිරීමට සිදුවිය හැකි නම්, පංතිය බොහෝ විට මෙම මූලධර්මය කඩ කරයි.

SOLID ක්‍රමලේඛන මූලධර්ම පැහැදිලි කරන සහ මෙම මූලධර්ම අනුගමනය නොකරන හා අනුගමනය නොකරන කේත සඳහා උදාහරණ සපයන හොඳ ලිපියක් වන්නේ https://scotch.io/bar-talk/solid-the-first-five-principles-of-object-oriented- නිර්මාණය .

එස්ආර්පී සම්බන්ධ උදාහරණයේ දී ඔහු හැඩතල පන්ති කිහිපයක් (රවුම සහ හතරැස්) සහ විවිධ හැඩයන්හි මුළු ප්‍රදේශය ගණනය කිරීම සඳහා නිර්මාණය කරන ලද පන්තියකට උදාහරණයක් සපයයි.

ඔහුගේ පළමු උදාහරණයේ දී ඔහු ප්‍රදේශය ගණනය කිරීමේ පන්තිය නිර්මාණය කරන අතර එය ඔහුගේ ප්‍රතිදානය HTML ලෙස නැවත ලබා දෙයි. පසුව ඔහු තීරණය කරන්නේ ඔහුට එය JSON ලෙස පෙන්වීමට අවශ්‍ය බවත් ඔහුගේ ප්‍රදේශය ගණනය කිරීමේ පන්තිය වෙනස් කළ යුතු බවත්ය.

මෙම උදාහරණයේ ඇති ගැටළුව නම්, ඔහුගේ ප්‍රදේශය ගණනය කිරීමේ පන්තිය හැඩතල ප්‍රමාණය ගණනය කිරීමට සහ එම ප්‍රදේශය ප්‍රදර්ශනය කිරීමට වගකිව යුතු බවයි. ඉන්පසු ඔහු ප්‍රදේශ පෙන්වීම සඳහා විශේෂයෙන් නිර්මාණය කර ඇති වෙනත් පන්තියක් භාවිතා කරමින් මෙය කිරීමට වඩා හොඳ ක්‍රමයක් අනුගමනය කරයි.

මෙය සරල උදාහරණයකි (සහ කේත ස්නිපෙට් ඇති බැවින් ලිපිය කියවීම වඩාත් පහසුවෙන් තේරුම් ගත හැකිය) නමුත් SRP හි මූලික අදහස පෙන්නුම් කරයි.

පළමුවෙන්ම, ඔබට ඇති දෙය ඇත්ත වශයෙන්ම වෙනම ගැටළු දෙකකි : ඔබේ පන්තිවලට ඇතුළත් කළ යුතු ක්‍රම පිළිබඳ ගැටළුව සහ අතුරු මුහුණත් පිපිරීමේ ගැටළුව.

අතුරුමුහුණත්

ඔබට මෙම අතුරු මුහුණත ඇත:

public Interface CustomerCRUD
{
  public void Create(Customer customer);
  public Customer Read(int CustomerID);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

අනුමාන කළ හැකි, ඔබට CustomerCRUDඅතුරු මුහුණතට අනුකූල වන පන්ති කිහිපයක් තිබේ (වෙනත් ආකාරයකින් අතුරු මුහුණතක් අනවශ්‍යය), සහ do_crud(customer: CustomerCRUD)අනුකූල වන වස්තුවක යම් ක්‍රියාකාරිත්වයක් ගනී. නමුත් ඔබ දැනටමත් SRP බිඳ දමා ඇත: ඔබ මෙම සුවිශේෂී මෙහෙයුම් හතර එකට බැඳ තබා ඇත.

පසුකාලීනව ඔබ දත්ත සමුදායන් මත ක්‍රියාත්මක වනු ඇතැයි කියමු. දත්ත සමුදා දර්ශනයකට ඇත්තේ ඒ සඳහා ඇති Readක්‍රමය පමණි . නමුත් ඔබට do_query_stuff(customer: ???)පූර්ණ ක්‍රියාකාරී වගු හෝ දර්ශන මත විනිවිද පෙනෙන ලෙස ක්‍රියා කරන ශ්‍රිතයක් ලිවීමට අවශ්‍යය ; එය භාවිතා කරන්නේ Readක්‍රමය පමණි .

එබැවින් අතුරු මුහුණතක් සාදන්න

පොදු අතුරුමුහුණත පාරිභෝගික රීඩර් {පොදු පාරිභෝගික කියවීම (customerID: int)}

සහ ඔබේ CustomerCrudඅතුරු මුහුණත පහත පරිදි සාධකය කරන්න :

public interface CustomerCRUD extends CustomerReader
{
  public void Create(Customer customer);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

නමුත් පෙනීමේ අවසානයක් නැත. අපට නිර්මාණය කළ හැකි නමුත් යාවත්කාලීන කළ නොහැකි වස්තූන් තිබිය හැකිය. මෙම හාවා කුහරය ඉතා ගැඹුරුය. තනි වගකීම් මූලධර්මය පිළිපැදිය හැකි එකම ක්‍රමය නම්, ඔබේ සියලු අතුරුමුහුණත් හරියටම එක් ක්‍රමයක් අඩංගු කිරීමයි. Go ඇත්ත වශයෙන්ම මෙම ක්‍රමවේදය අනුගමනය කරන්නේ මා දුටු දෙයින් වන අතර, අතුරු මුහුණත් වලින් බහුතරයක් තනි ශ්‍රිතයක් අඩංගු වේ; ඔබට කාර්යයන් දෙකක් අඩංගු අතුරු මුහුණතක් නියම කිරීමට අවශ්‍ය නම්, ඔබ අමුතු ලෙස මේ දෙක ඒකාබද්ධ කරන නව අතුරු මුහුණතක් නිර්මාණය කළ යුතුය. ඔබට ඉක්මනින් අතුරු මුහුණත් වල ඒකාබද්ධ පිපිරීමක් ලැබෙනු ඇත.

මෙම අවුලෙන් මිදීමට ඇති මාර්ගය නම් අතුරුමුහුණත් වෙනුවට ව්‍යුහාත්මක උප වර්ගීකරණය (උදා: OCaml හි ක්‍රියාත්මක කිරීම) (ඒවා නාමික උප ප්‍රභේදයකි). අපි අතුරුමුහුණත් නිර්වචනය නොකරමු; ඒ වෙනුවට, අපට හුදෙක් ශ්‍රිතයක් ලිවිය හැකිය

let do_customer_stuff customer = customer.read ... customer.update ...

එය අප කැමති ඕනෑම ක්‍රමයක් අමතයි. මෙම ක්‍රම ක්‍රියාත්මක කරන ඕනෑම වස්තුවක අපට ගමන් කළ හැකි බව තීරණය කිරීම සඳහා OCaml වර්ගයේ අනුමානයන් භාවිතා කරනු ඇත. මෙම උදාහරණයේ දී, එය customerවර්ගය ඇති බව තීරණය කරනු ඇත <read: int -> unit, update: int -> unit, ...>.

පංතිවල

මෙය අතුරු මුහුණතේ අවුල විසඳයි ; නමුත් අපි තවමත් විවිධ ක්‍රම අඩංගු පන්ති ක්‍රියාත්මක කළ යුතුයි. උදාහරණයක් ලෙස, අපි වෙනස් පංති දෙකක් නිර්මාණය කළ යුතු, CustomerReaderහා CustomerWriter? වගු කියවන ආකාරය වෙනස් කිරීමට අපට අවශ්‍ය නම් (උදා: දත්ත ලබා ගැනීමට පෙර අපි දැන් අපගේ ප්‍රතිචාර නැවත රතු පාටින් තැන්පත් කරමු), නමුත් දැන් ඒවා ලියා ඇති ආකාරය? ඔබ මෙම තර්කානුකූල දාමය එහි තාර්කික නිගමනයට අනුගමනය කරන්නේ නම් , ඔබ නොවැලැක්විය හැකි ලෙස ක්‍රියාකාරී වැඩසටහන්කරණයට යොමු කරයි :)

මගේ මතකයේ හැටියට, මගේ මතකයට එන SRP එකකට ආසන්නතම දෙය භාවිත ප්‍රවාහයකි. ඔබට කිසියම් පන්තියක් සඳහා පැහැදිලි භාවිත ප්‍රවාහයක් නොමැති නම්, එය බොහෝ විට ඔබේ පන්තියට නිර්මාණ සුවඳක් ඇත.

භාවිත ප්‍රවාහයක් යනු අපේක්ෂිත (මෙලෙස පරීක්ෂා කළ හැකි) ප්‍රති .ලයක් ලබා දෙන, ලබා දුන් ක්‍රම ඇමතුම් අනුප්‍රාප්තියකි. ඔබ මූලික වශයෙන් IMHO ලබා ගත් භාවිත අවස්ථා සමඟ පන්තියක් නිර්වචනය කරයි, සියලු වැඩසටහන් ක්‍රමවේදය ක්‍රියාත්මක කිරීමේදී අතුරු මුහුණත් කෙරෙහි අවධානය යොමු කරන්නේ එබැවිනි.

බහු අවශ්‍යතා වෙනස්වීම් සාක්ෂාත් කර ගැනීම සඳහා, ඔබේ සංරචකය වෙනස් කිරීම අවශ්‍ය නොවේ .

බැලූ බැල්මට SOLID ගැන ඔබ මුලින් ඇසූ විට එය වාසනාවකි.

SRP සහ YAGNI එකිනෙකාට පරස්පර විය හැකි බව පවසන බොහෝ අදහස් මම දකිමි , නමුත් TDD (GOOS, ලන්ඩන් පාසල) විසින් ක්‍රියාත්මක කරන ලද YAGN සේවාදායකයාගේ දෘෂ්ටිකෝණයෙන් මගේ සංරචක ගැන සිතීමට හා සැලසුම් කිරීමට මට ඉගැන්නුවා. මම මගේ අතුරුමුහුණත් සැලසුම් කිරීම ආරම්භ කළේ ඕනෑම සේවාදායකයෙකුට එය කිරීමට අවශ්‍ය අවම දේ අනුවය, එය කළ යුත්තේ අල්ප වශයෙනි . එම ව්‍යායාමය TDD පිළිබඳ කිසිදු දැනුමක් නොමැතිව කළ හැකිය.

බොබ් මාමා විසින් විස්තර කරන ලද තාක්‍ෂණයට මම කැමතියි (කනගාටුවට කරුණක් නම් මට කොහෙන්දැයි මතක නැත).

ඔබෙන්ම මෙසේ අසන්න, මෙම පන්තිය කරන්නේ කුමක්ද?

ඔබගේ පිළිතුර එක්කෝ අඩංගු කළ ඒ හෝ නැතහොත්

එසේ නම්, පිළිතුරේ එම කොටස උපුටා ගන්න, එය තමන්ගේම වගකීමකි

මෙම තාක්ෂණය නිරපේක්ෂ වන අතර, එස්විඩ්ජන් පැවසූ පරිදි, SRP යනු විනිශ්චය කැඳවීමකි, නමුත් අළුත් දෙයක් ඉගෙන ගන්නා විට, නිරපේක්ෂත්වය හොඳම වේ, සෑම විටම යමක් කිරීම පහසුය . ඔබ වෙන් නොවීමට හේතුව වග බලා ගන්න; උගත් තක්සේරුවක් මිස ඔබ එය කරන්නේ කෙසේදැයි නොදන්නා නිසා නොවේ. මෙය කලාව වන අතර එය අත්දැකීම් අවශ්‍ය වේ.

මම පිළිතුරු ගොඩක් ගැන කතා කරන විට decoupling තර්කය සඳහා කිරීමට පෙනේ හිතන්නේ SRP .

SRP වේ නොහැකි වෙනසක් ඇති පරායත්ත ප්රස්තාරය පහළ ප්රචාරය කරන්නේ නැහැ තහවුරු කර ගන්න.

න්යායාත්මකව තොරව SRP , ඔබට ඕනෑම dependecies නැහැ ...

එක් වෙනසක් යෙදුමේ බොහෝ ස්ථානවල වෙනසක් ඇති නොකළ යුතුය, නමුත් ඒ සඳහා අපට වෙනත් මූලධර්ම තිබේ. කෙසේ වෙතත්, SRP විවෘත සංවෘත මූලධර්මය වැඩි දියුණු කරයි . මෙම මූලධර්මය වියුක්ත කිරීම පිළිබඳ වැඩි යමක් වේ, කෙසේ වෙතත්, කුඩා වියුක්ත කිරීම් නැවත සකස් කිරීම පහසුය .

එබැවින් සමස්තයක් ලෙස SOLID උගන්වන විට, අවශ්‍යතා වෙනස් වන විට අඩු කේතයක් වෙනස් කිරීමට SRP මඟින් ඉඩ ලබා දෙන බව ඉගැන්වීමට ප්‍රවේශම් වන්න , ඇත්ත වශයෙන්ම එය අඩු නව කේතයක් ලිවීමට ඉඩ දෙයි .

ඊට පැහැදිලි පිළිතුරක් නැත. ප්‍රශ්නය පටු වුවත් පැහැදිලි කිරීම් එසේ නොවේ.

මට නම් එය ඔබට අවශ්‍ය නම් ඔකාම්ස් රේසර් වැනි ය. එය මගේ වර්තමාන කේතය මැනීමට උත්සාහ කරන පරමාදර්ශයකි. සරල හා සරල වචන වලින් එය ඇණ ගැසීම දුෂ්කර ය. තවත් රූපකයක් වනුයේ »එක් මාතෘකාවක්« වියුක්තය, එනම් ග්‍රහණය කර ගැනීමට අපහසු, »තනි වගකීමක් as ය. තුන්වන විස්තරය වනුයේ one එක් මට්ටමක වියුක්ත කිරීමක් සමඟ කටයුතු කිරීමයි «.

ප්‍රායෝගිකව එයින් අදහස් කරන්නේ කුමක්ද?

මෑතකදී මම කේතකරණ ශෛලියක් භාවිතා කරන අතර එය බොහෝ දුරට අදියර දෙකකින් සමන්විත වේ:

පළමු අදියර නිර්මාණාත්මක අවුල් ජාලයක් ලෙස වඩාත් හොඳින් විස්තර කෙරේ. මෙම අදියරේදී සිතුවිලි ගලා යන බැවින් මම කේතය ලියා තබමි - එනම් අමු සහ කැත.

අදියර II යනු සම්පූර්ණ ප්‍රතිවිරුද්ධයයි. එය හරියට සුළි කුණාටුවකින් පසු පිරිසිදු කිරීම වැනිය. මෙය වැඩිපුරම වැඩ කිරීම හා හික්මවීම අවශ්‍ය වේ. ඉන්පසු මම කේතය දෙස බලන්නේ නිර්මාණකරුවෙකුගේ දෘෂ්ටිකෝණයෙනි.

මම දැන් වැඩිපුරම වැඩ කරන්නේ පයිතන් වල වන අතර එමඟින් මට පසුව වස්තු සහ පන්ති ගැන සිතීමට ඉඩ සලසයි. පළමු අදියර I - මම කාර්යයන් පමණක් ලියන අතර ඒවා විවිධ මොඩියුලවල අහඹු ලෙස ව්‍යාප්ත කරමි. දී දෙවන අදියර , මම යන්නේ දේවල් තියෙනවද පසු, මම විසඳුමක් වන කොටසක් සමග ගනුදෙනු ෙම ලය දේ දෙස සමීපව බැලීමට ඇති. මොඩියුල හරහා ගමන් කරන අතරම, මාතෘකා මට මතුවෙයි. සමහර කාර්යයන් තේමාත්මකව සම්බන්ධ වේ. මේ අය පන්ති සඳහා හොඳ අයදුම්කරුවන් . හා පසු මම පංති වලට කාර්යයන් හැරී - කට ආසන්න එබුම සමග සිදු කිරීම සහ එක් වන selfපිඹුරා දී පරාමිතිය ලැයිස්තුවට;) - මම භාවිතා SRPවෙනත් මොඩියුලයන් සහ පංතිවලට ක්රියාකාරිත්වය සිදු ඉවත් කිරීමට Occam ගේ Razor යන වගේ.

වර්තමාන උදාහරණයක් වන්නේ අනෙක් දවසේ කුඩා අපනයන ක්‍රියාකාරිත්වය ලිවීමයි .

අවශ්යතාව ඇති විය CSV , Excel සහ ඒකාබද්ධ excel තහඩු සඳහා තැපැල් දී.

සරල ක්‍රියාකාරිත්වය එක් එක් දර්ශන තුනකින් (= ශ්‍රිත) සිදු කරන ලදී. සෑම ශ්‍රිතයක්ම පෙරහන් තීරණය කිරීම සඳහා පොදු ක්‍රමයක් සහ දත්ත ලබා ගැනීම සඳහා දෙවන ක්‍රමයක් භාවිතා කළේය. ඉන්පසු සෑම කාර්යයකදීම අපනයනය සකස් කිරීම සිදු වූ අතර එය සේවාදායකයාගෙන් ප්‍රතිචාරයක් ලෙස ලබා දෙන ලදි.

වියුක්ත කිරීමේ මට්ටම් ඕනෑවට වඩා මිශ්‍ර විය:

I) පැමිණෙන / පිටතට යන ඉල්ලීම / ප්‍රතිචාර සමඟ කටයුතු කිරීම

II) පෙරහන් තීරණය කිරීම

III) දත්ත ලබා ගැනීම

IV) දත්ත පරිවර්තනය

පහසුම පියවර වූයේ exporterපළමු පියවරේදී II-IV ස්ථර සමඟ කටයුතු කිරීම සඳහා එක් සාරාංශයක් ( ) භාවිතා කිරීමයි .

ඉතිරිව ඇත්තේ ඉල්ලීම් / ප්‍රතිචාර සමඟ කටයුතු කරන මාතෘකාව පමණි . සාරාංශයේ එකම මට්ටමේ ඉල්ලීම් පරාමිතීන් උකහා ගැනීම හරි ය. එබැවින් මට මෙම මතය සඳහා එක් "වගකීමක්" තිබුණි.

දෙවනුව, අපනයනකරු බිඳ දැමීමට මට සිදු විය, එය අප දුටු පරිදි අවම වශයෙන් තවත් වියුක්ත ස්ථර තුනකින් සමන්විත විය.

පෙරහන් නිර්ණායක නිර්ණය කිරීම සහ සත්‍ය ලෙස නැවත ලබා ගැනීම එකම මට්ටමේ වියුක්ත මට්ටමක පවතී (දත්තවල නිවැරදි අනු කාණ්ඩය ලබා ගැනීම සඳහා පෙරහන් අවශ්‍ය වේ). මෙම මට්ටම් දත්ත ප්‍රවේශ ස්ථරයකට දමා ඇත.

මීලඟ පියවරේදී මම සත්‍ය අපනයන යාන්ත්‍රණයන් වෙන් කළෙමි: තාවකාලික ගොනුවකට ලිවීම අවශ්‍ය වූ විට, මම එය "වගකීම්" දෙකකට බෙදුවෙමි: එකක් දත්ත තැටියට සත්‍ය ලෙස ලිවීම සඳහා සහ තවත් කොටසක් සත්‍ය ආකෘතිය සමඟ කටයුතු කිරීම.

පංති සහ මොඩියුල සැකසීමේදී, දේවල් පැහැදිලි වූයේ, කොතැනටද යන්න. පංතිය ඕනෑවට වඩා කරයිද යන්න සැමවිටම ගුප්ත ප්‍රශ්නයයි .

එක් එක් පන්තියට තිබිය යුතු වගකීම් ඔබ තීරණය කරන්නේ කෙසේද සහ SRP සන්දර්භය තුළ ඔබ වගකීමක් නිර්වචනය කරන්නේ කෙසේද?

අනුගමනය කිරීමට වට්ටෝරුවක් ලබා දීම දුෂ්කර ය. ඇත්ත වශයෙන්ම මට ගුප්ත »පුනරාවර්තනයේ එක් මට්ටමක් පුනරාවර්තනය කළ හැකිය - එය උපකාරී වේ නම් රීතිය.

බොහෝ දුරට මට එය එක්තරා ආකාරයක “කලාත්මක බුද්ධියක්” වන අතර එය වර්තමාන සැලසුමට මග පාදයි. චිත්‍ර ශිල්පියෙකු මැටි කැටයම් කිරීම හෝ පින්තාරු කිරීම වැනි මා ආදර්ශ කේතය.

මාව කේතීකරණ බොබ් රොස් ලෙස සිතන්න ;)

SRP අනුගමනය කරන කේත ලිවීමට මා උත්සාහ කරන්නේ කුමක්ද:

• ඔබට විසඳීමට අවශ්‍ය විශේෂිත ගැටළුවක් තෝරන්න;
• එය විසඳන කේතය ලියන්න, සියල්ල එක් ක්‍රමයකින් ලියන්න (උදා: ප්‍රධාන);
• කේතය ප්‍රවේශමෙන් විශ්ලේෂණය කර, ව්‍යාපාරය මත පදනම්ව, සිදු කරනු ලබන සියලුම මෙහෙයුම් වලදී දැකිය හැකි වගකීම් නිර්වචනය කිරීමට උත්සාහ කරන්න (මෙය ව්‍යාපාර / ව්‍යාපෘති / පාරිභෝගිකයා මත රඳා පවතින විෂයානුබද්ධ කොටසයි);
• කරුණාකර, සියලු ක්‍රියාකාරීත්වය දැනටමත් ක්‍රියාත්මක කර ඇති බව සලකන්න; මීළඟට ඇත්තේ කේතය සංවිධානය කිරීම පමණි (මෙම ප්‍රවේශයේදී මෙතැන් සිට අමතර අංගයක් හෝ යාන්ත්‍රණයක් ක්‍රියාත්මක නොවේ);
• පෙර පියවරයන්හි ඔබ අර්ථ දක්වා ඇති වගකීම් මත පදනම්ව (ව්‍යාපාරය සහ "වෙනස් කිරීමට එක් හේතුවක්" යන අදහස මත පදනම්ව), එක් එක් සඳහා වෙනම පන්තියක් හෝ ක්‍රමයක් උපුටා ගන්න;
• මෙම ප්‍රවේශය සැලකිලිමත් වන්නේ එස්පීආර් ගැන පමණක් බව කරුණාවෙන් සලකන්න; අනෙක් මූලධර්ම ද පිළිපැදීමට උත්සාහ කරන අමතර පියවර මෙහි තිබිය යුතුය.

උදාහරණයක්:

ගැටලුව: පරිශීලකයාගෙන් අංක දෙකක් ලබා ගන්න, ඒවායේ එකතුව ගණනය කර ප්‍රති result ලය පරිශීලකයාට ලබා දෙන්න:

//first step: solve the problem right away
static void Main(string[] args)
{
    Console.WriteLine("Number 1: ");
    int firstNumber = Convert.ToInt32(Console.ReadLine());

    Console.WriteLine("Number 2: ");
    int secondNumber = Convert.ToInt32(Console.ReadLine());

    int result = firstNumber + secondNumber;

    Console.WriteLine("Hi there! The result is: {0}", result);

    Console.ReadLine();
}

ඊළඟට, ඉටු කළ යුතු කාර්යයන් මත පදනම්ව වගකීම් නිර්වචනය කිරීමට උත්සාහ කරන්න. මෙයින්, සුදුසු පන්ති උපුටා ගන්න:

//Responsible for getting two integers from the user
class Input {
    public int FirstNumber { get; set; }
    public int SecondNumber { get; set; }
    public void Read() {
        Console.WriteLine("Number 1: ");
        FirstNumber = Convert.ToInt32(Console.ReadLine());

        Console.WriteLine("Number 2: ");
        SecondNumber = Convert.ToInt32(Console.ReadLine());
    }
}

//Responsible for calculating the sum of two integers
class SumOperation {
    public int Result { get; set; }
    public void Calculate(int a, int b) {
        Result = a + b;
    }
}

//Responsible for the output of some value to the user
class Output {
    public void Write(int result) {
        Console.WriteLine("Hello! The result is: {0}", result);
    }
}

එවිට, ප්‍රතිනිර්මාණය කරන ලද වැඩසටහන බවට පත්වන්නේ:

//Program: responsible for main execution.
//Gets two numbers from user and output their sum.
static void Main(string[] args)
{
    var input = new Input();
    input.Read();

    var operation = new SumOperation();
    operation.Calculate(input.FirstNumber, input.SecondNumber);

    var output = new Output();
    output.Write(operation.Result);

    Console.ReadLine();
}

සටහන: මෙම ඉතා සරල උදාහරණය සැලකිල්ලට ගන්නේ SRP මූලධර්මය පමණි. අනෙක් මූලධර්ම භාවිතය (උදා: "එල්" - කේතය කොන්ක්‍රීට් වලට වඩා වියුක්ත කිරීම් මත රඳා පැවතිය යුතුය) කේතයට වැඩි ප්‍රතිලාභ ලබා දෙන අතර ව්‍යාපාර වෙනස්කම් සඳහා එය වඩාත් නඩත්තු කළ හැකිය.

රොබට් සී මාර්ටින් පොත පිරිසිදු ගෘහ නිර්මාණ ශිල්පය: ඒ ෙපොෙළොන්නරුව මාර්ගෝපදේශනයක් මෘදුකාංග සඳහා ව්යුහය හා නිර්මාණ සැප්තැම්බර් 10 2017 ප්රකාශයට පත්, රොබට් 62 වන පිටුවේ ඇති පහත සඳහන් මෙසේ ලියයි:

S තිහාසිකව, SRP මේ ආකාරයෙන් විස්තර කර ඇත:

මොඩියුලයකට එකක් තිබිය යුතු අතර වෙනස් වීමට එක් හේතුවක් පමණක් තිබිය යුතුය

පරිශීලකයින් සහ පාර්ශවකරුවන් තෘප්තිමත් කිරීම සඳහා මෘදුකාංග පද්ධති වෙනස් කරනු ලැබේ; එම භාවිතා කරන්නන් හා පාර්ශ්වකරුවන් වන ඇති "වෙනස් කිරීමට හේතුවක්." මූලධර්මය ගැන කතා කරන බව. ඇත්ත වශයෙන්ම, අපට මෙය කීමට මූලධර්මය නැවත ලිවිය හැකිය:

මොඩියුලයක් එක් අයෙකුට වගකිව යුතු අතර, එක් අයෙකු, පරිශීලකයා හෝ පාර්ශවකරුවෙකු පමණි

අවාසනාවට, "පරිශීලකයා" සහ "පාර්ශවකරු" යන වචනය ඇත්ත වශයෙන්ම මෙහි භාවිතා කිරීමට සුදුසුම වචනය නොවේ. පද්ධතිය එකම ආකාරයකින් වෙනස් කිරීමට අවශ්‍ය පරිශීලකයින් හෝ පාර්ශ්වකරුවන් එකකට වඩා සිටිය හැකිය. ඒ වෙනුවට අපි සැබවින්ම යොමු කරන්නේ කණ්ඩායමක් වෙතය - එම වෙනස අවශ්‍ය පුද්ගලයින් එකක් හෝ වැඩි ගණනක්. අපි එම කණ්ඩායම නළුවෙකු ලෙස හඳුන්වන්නෙමු .

මේ අනුව SRP හි අවසාන අනුවාදය:

මොඩියුලයක් එක් අයෙකුට වගකිව යුතු අතර එක් නළුවෙකුට පමණි.

එබැවින් මෙය කේතය ගැන නොවේ. එස්ආර්පී යනු අවශ්‍යතා සහ ව්‍යාපාර අවශ්‍යතා ගලායාම පාලනය කිරීම සඳහා වන අතර එය පැමිණිය හැක්කේ එක් ආත්මයකින් පමණි.