SOLID මූලධර්ම සහ කේත ව්‍යුහය

මෑත කාලීන රැකියා සම්මුඛ සාකච්ඡාවකදී, විවිධ මූලධර්මවල මූලික අරුත ලබා දීමට වඩා, SOLID පිළිබඳ ප්‍රශ්නයකට පිළිතුරු දීමට මට නොහැකි විය . එය ඇත්තෙන්ම මට දෝෂාරෝපණය කරයි. මම දින කිහිපයක් වටේ කැණීම් කර ඇති අතර තවමත් සතුටුදායක සාරාංශයක් ඉදිරිපත් කර නොමැත.

සම්මුඛ පරීක්ෂණ ප්‍රශ්නය වූයේ:

SOLID මූලධර්ම දැඩි ලෙස අනුගමනය කළ බව මා ඔබට පැවසූ .නෙට් ව්‍යාපෘතියක් දෙස බැලුවහොත්, ව්‍යාපෘතිය සහ කේත ව්‍යුහය අනුව ඔබ අපේක්ෂා කරන්නේ කුමක්ද?

මම ටිකක් එහාට මෙහාට ගියා, ඇත්තටම ප්‍රශ්නයට උත්තර දුන්නේ නැහැ, පසුව බෝම්බ හෙලුවා.

මට මෙම ප්‍රශ්නය වඩා හොඳින් හැසිරවිය හැක්කේ කෙසේද?

එස් = තනි වගකීම් මූලධර්මය

එබැවින් හොඳින් සංවිධානය වූ ෆෝල්ඩරයක් / ගොනු ව්‍යුහයක් සහ වස්තු ධූරාවලියක් දැකීමට මම බලාපොරොත්තු වෙමි. සෑම පන්තියකම / ක්‍රියාකාරීත්වයේ කොටසක් එහි ක්‍රියාකාරිත්වය ඉතා පැහැදිලිව පෙනෙන බව නම් කළ යුතු අතර, එම කාර්යය ඉටු කිරීම සඳහා එහි තර්කනය පමණක් තිබිය යුතුය.

කේත පේළි දහස් ගණනක් සහිත විශාල කළමනාකරු පන්ති ඔබ දුටුවේ නම්, එය තනි වගකීමක් අනුගමනය නොකරන බවට ලකුණකි.

O = විවෘත / සංවෘත මූලධර්මය

මෙය මූලික වශයෙන් අදහස වන්නේ දැනට පවතින ක්‍රියාකාරිත්වය වෙනස් කිරීම සඳහා අවම බලපෑමක් ඇති / අවශ්‍ය වන නව පන්ති හරහා නව ක්‍රියාකාරිත්වය එක් කළ යුතු බවයි.

ක්‍රියාකාරීත්වයේ කොටසක් සැබෑ ක්‍රියාවට නැංවීමෙන් වෙන් කිරීම සඳහා වස්තු උරුමය, උප-ටයිප් කිරීම, අතුරුමුහුණත් සහ වියුක්ත පංති විශාල ප්‍රමාණයක් භාවිතා කරනු ඇතැයි මම අපේක්ෂා කරමි. මුල්.

එල් = ලිස්කොව් ආදේශන මූලධර්මය

උප වර්ග ඔවුන්ගේ මව් වර්ගය ලෙස සැලකීමේ හැකියාව සමඟ මෙය සම්බන්ධ වේ. ඔබ නිසි උරුම වස්තු ධූරාවලියක් ක්‍රියාත්මක කරන්නේ නම් මෙය C # කොටුවෙන් පිටතට පැමිණේ.

කේතයන් පොදු වස්තූන් ඒවායේ මූලික වර්ගය ලෙස සලකන ආකාරය සහ උප වර්ගයන් ස්ථාපනය කිරීම හා වැඩ කිරීම වෙනුවට මූලික / වියුක්ත පංතිවල ඇමතුම් ක්‍රම දැකීමට මම බලාපොරොත්තු වෙමි.

I = අතුරුමුහුණත් වෙන් කිරීමේ මූලධර්මය

මෙය SRP වලට සමානය. මූලික වශයෙන්, ඔබ decoupled ඔබේ පද්ධතිය තබා ගැනීමට මුහුණත් හා අය සමග වැඩ ලෙස ක්රියාකාරීත්වය කුඩා අවධියේ පසුවේ නිර්වචනය (උදා: FileManagerගොනුව I / O සමඟ කටයුතු තනි responsibilty ඇති හැකි වුවත්, මෙය ක්රියාත්මක කළ හැකි IFileReaderසහ IFileWriterකියවීමේ සඳහා නිශ්චිත ක්රමය අර්ථ දැක්වීම් අඩංගු සහ ලිපිගොනු ලිවීම).

D = පරායත්ත ප්‍රතිලෝම මූලධර්මය.

නැවතත් මෙය සම්බන්ධ වන්නේ පද්ධතියක් විසන්ධි කිරීම සඳහා ය. සමහර විට ඔබ වැනි විසඳුම භාවිතා කෙරෙමින් .NET සත්කාර එන්නත් පුස්තකාල භාවිතය, පිළිබඳ විමසිල්ලෙන් විය කැමතියි Unityහෝ Ninjectහෝ එවැනි ServiceLocator පද්ධතිය AutoFacServiceLocator.

සෑම තැනකම පරායත්ත එන්නත් සමඟ කුඩා පන්ති සහ අතුරුමුහුණත්. බොහෝ විට විශාල ව්‍යාපෘතියක දී ඔබ එම කුඩා වස්තූන්ගේ ජීවිත කාලය ගොඩනඟා ගැනීමට සහ කළමනාකරණය කිරීමට උදව් කිරීමට IoC රාමුවක් භාවිතා කරනු ඇත. Https://stackoverflow.com/questions/21288/which-net-dependency-injection-frameworks-are-worth-looking-into බලන්න

SOLID මූලධර්ම දැඩි ලෙස අනුගමනය කරන විශාල .NET ව්‍යාපෘතියක් සෑම කෙනෙකු සමඟම වැඩ කිරීමට හොඳ කේත පදනමක් අදහස් නොකරන බව සලකන්න. සම්මුඛ පරීක්‍ෂකවරයා කවුරුන්ද යන්න මත පදනම්ව, ඔහු / ඇය ඔබට සොලිඩ් යන්නෙන් අදහස් කරන්නේ කුමක්ද යන්න තේරුම් ගෙන ඇති බව පෙන්වීමට සහ / හෝ ඔබ නිර්මාණ මූලධර්ම අනුගමනය කරන්නේ කෙසේදැයි විමසා බැලීමට අවශ්‍ය වන්නට ඇත.

SOLID වීමට නම්, ඔබ අනුගමනය කළ යුත්තේ:

S වගකීම් මූලධර්මය ඇතුලත් කරන්න, එබැවින් ඔබට එක් එක් දේ පමණක් කරන කුඩා පන්ති බොහොමයක් ඇත

සාමාන්ය .NET සාමාන්යයෙන් ද මම සහ පහත ඩී අවශ්ය වන පරායත්ත එන්නත් සමග ක්රියාත්මක වන පෑන-වසා මූලධර්මය, ...

එල් ඉස්කොව් ආදේශන මූලධර්මය බොහෝ විට එක් ලයිනර් සමඟ c # හි පැහැදිලි කිරීමට නොහැකි ය. වාසනාවකට එය ආමන්ත්‍රණය කරන වෙනත් ප්‍රශ්න තිබේ, උදා: /programming/4428725/can-you-explain-liskov-substitution-principle-with-a-good-c-sharp-example

මම වෙන් කිරීමේ මූලධර්මය විවෘත-සංවෘත මූලධර්මයට සමගාමීව ක්‍රියා කරමි . වචනානුසාරයෙන් අනුගමනය කරන්නේ නම් එයින් අදහස් කරන්නේ "විශාල" අතුරුමුහුණත් කිහිපයක් වෙනුවට ඉතා කුඩා අතුරුමුහුණත් විශාල සංඛ්‍යාවක් කැමති බවයි

D ependency ප්‍රතිලෝම මූලධර්මය ඉහළ මට්ටමේ පන්ති පහත් මට්ටමේ පන්ති මත රඳා නොපවතින අතර දෙකම වියුක්ත කිරීම් මත රඳා පවතී.

ඔවුන්ගේ දෛනික වැඩ කටයුතුවලදී SOLID භාවිතා කළ වෙළඳසැලක කේත පදනම තුළ මා දැකීමට බලාපොරොත්තු වන මූලික කරුණු කිහිපයක්:

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

• ඇඩැප්ටරය සහ සංයුක්ත රටා ගොඩක් - එක් අරමුණක් සඳහා වර්ධනය කරන ලද පරායත්තතාවයක ප්ලග් කිරීම තරමක් දුරට විධිමත් කිරීම සඳහා බොහෝ ඇඩැප්ටර රටා (වෙනත් අතුරුමුහුණතක ක්‍රියාකාරීත්වයට “හරහා” එක් අතුරු මුහුණතක් ක්‍රියාත්මක කරන පන්තියක්) භාවිතා කිරීම මම බලාපොරොත්තු වෙමි. එහි ක්‍රියාකාරීත්වය අවශ්‍ය විවිධ ස්ථාන. භාවිතා කිරීමට ගොනු නාමය නියම කිරීමේ මාධ්‍යයක් නිරාවරණය කිරීම සඳහා අතුරු මුහුණත යාවත්කාලීන කරන්නේ නම්, ගොනු ලොගර් සමඟ කොන්සෝල ලොගර් වෙනුවට ආදේශ කිරීම LSP / ISP / DIP උල්ලං will නය කරයි; ඒ වෙනුවට, ගොනු ලොගර් පන්තිය මඟින් අතිරේක සාමාජිකයන් හෙළි කරනු ඇති අතර, පසුව ඇඩැප්ටරයක් ​​මඟින් නව දේවල් සඟවා ගොනු ලොජරය කොන්සෝල ලොගර් ලෙස පෙනෙනු ඇත, එබැවින් මේ සියල්ල එකට ගසාගෙන යන වස්තුව පමණක් වෙනස දැන සිටිය යුතුය.

  ඒ හා සමානව, වස්තුවක් (ඕසීපී) වෙනස් නොකිරීමට පන්තියකට දැනට පවතින අතුරු මුහුණතක පරායත්තතාවයක් එක් කිරීමට අවශ්‍ය වූ විට, සුපුරුදු පිළිතුර වන්නේ සංයුක්ත / උපාය මාර්ග රටාවක් ක්‍රියාත්මක කිරීමයි (පන්තියක් පරායත්තතා අතුරු මුහුණත ක්‍රියාත්මක කිරීම සහ තවත් බොහෝ දේ පරිභෝජනය කිරීම එම අතුරුමුහුණත ක්‍රියාත්මක කිරීම, විවිධාකාර තර්කනයන් සමඟ පන්තියට එකක්, සමහරක් හෝ සියලු ක්‍රියාත්මක කිරීම් වෙත ඇමතුමක් ලබා දීමට ඉඩ දෙයි).

• බොහෝ අතුරුමුහුණත් සහ ඒබීසී - ඩීඅයිපීයට අනිවාර්යයෙන්ම වියුක්ත කිරීම් අවශ්‍ය වන අතර අයිඑස්පී මේවා පටු පරාසයකින් යුතු ලෙස දිරිමත් කරයි. එමනිසා, අතුරුමුහුණත් සහ වියුක්ත පාදක පංති රීතිය වන අතර, ඔබේ කේත පදනමේ හවුල් පරායත්තතා ක්‍රියාකාරිත්වය ආවරණය කිරීම සඳහා ඔබට ඒවායින් බොහොමයක් අවශ්‍ය වේ. දැඩි SOLID මගින් සෑම දෙයක්ම එන්නත් කිරීම අවශ්‍ය වන අතර , ඔබ කොතැනක හෝ නිර්මාණය කළ යුතු බව පැහැදිලිය. එබැවින් GUI පෝරමයක් එක් දෙමාපිය පෝරමයක දරුවෙකු ලෙස පමණක් නිර්මාණය වී ඇත්නම්, එම දෙමව්පියන් සම්බන්ධයෙන් යම් ක්‍රියාමාර්ගයක් ගැනීමෙන් මට ළමා පෝරමය අලුත් කිරීමට කිසිදු හැකියාවක් නැත. කේතයෙන් කෙලින්ම මවුපියන් තුළ. මම සාමාන්‍යයෙන් එම කේතය එහි ක්‍රමවේදයක් බවට පත් කරමි, එබැවින් එකම ස්වරූපයේ ක්‍රියා දෙකක් කවදා හෝ කවුළුව විවෘත කර ඇත්නම්, මම එම ක්‍රමය අමතන්නෙමි.
• බොහෝ ව්‍යාපෘති - මේ සියල්ලේ කාරණය වන්නේ වෙනස් වීමේ විෂය පථය සීමා කිරීමයි. වෙනස් කිරීම සඳහා නැවත සකස් කිරීම අවශ්‍ය වේ (සාපේක්ෂව සුළු සුළු ව්‍යායාමයක්, නමුත් බොහෝ ප්‍රොසෙසරවල තවමත් වැදගත් වන අතර ජංගම පරිසරයකට යාවත්කාලීන කිරීම් යෙදවීම වැනි කලාප පළල-විවේචනාත්මක මෙහෙයුම්). ව්‍යාපෘතියක එක් ගොනුවක් නැවත ගොඩනඟා ගත යුතු නම්, සියලුම ලිපිගොනු එසේ කරයි. එයින් අදහස් වන්නේ ඔබ ඒවා ක්‍රියාත්මක කරන පුස්තකාලවලම අතුරු මුහුණත් තැබුවහොත් ඔබට එම කරුණ මඟ හැරී ඇති බවයි; ඔබ අතුරුමුහුණත ක්‍රියාත්මක කිරීම වෙනස් කළහොත් ඔබට සියලු භාවිතයන් නැවත සකස් කිරීමට සිදුවනු ඇත, මන්ද ඔබ අතුරු මුහුණතේ අර්ථ දැක්වීම නැවත සකස් කරන අතර, එහි ප්‍රති ing ලයක් ලෙස ද්විමය තුළ නව ස්ථානයකට යොමු කිරීමට භාවිතයන් අවශ්‍ය වේ. එබැවින්, අතුරු මුහුණත් භාවිතයෙන් වෙන්ව තබා ගැනීම සහ ක්‍රියාවට නැංවීම, සාමාන්‍ය භාවිතයේ ප්‍රදේශ අනුව ඒවා වෙන් කිරීම සාමාන්‍ය හොඳම භාවිතයකි.
• "කල්ලියේ හතර" පාරිභාෂිතය කෙරෙහි වැඩි අවධානයක් යොමු කර ඇත - 1994 පොතේ සැලසුම් රටා හදුනාගෙන ඇති මෝස්තර රටා මගින් SOLID නිර්මාණය කිරීමට උත්සාහ කරන දෂ්ට ප්‍රමාණයේ, මොඩියුලර් කේත නිර්මාණය අවධාරණය කරයි. නිදසුනක් ලෙස, පරායත්ත ප්‍රතිලෝම මූලධර්මය සහ විවෘත / සංවෘත මූලධර්මය එම පොතේ හඳුනාගත් බොහෝ රටාවන්ගේ හදවතේ පවතී. එනිසා, සොලිඩ් මූලධර්මවලට තදින් ඇලී සිටින වෙළඳසැලක් ද ගංගා ඔෆ් ෆෝර්ගේ පොතේ පාරිභාෂිතය වැලඳ ගනු ඇතැයි මම අපේක්ෂා කරමි. එමෙන්ම ඒවායේ ක්‍රියාකාරිත්වය අනුව පන්ති නම් කරන්න. "," A1Command "ආදිය.
• සාමාන්‍ය නිධියක් - පොදුවේ තේරුම් ගත් පරිදි අයිඑස්පී, ඩීඅයිපී සහ එස්ආර්පී වලට අනුකූලව, නිධිය SOLID සැලසුමෙහි සර්වසම්පූර්ණ ය, මන්ද යත්, නැවත ලබා ගැනීමේ / නොනැසී පවත්නා යාන්ත්‍රණය පිළිබඳ නිශ්චිත දැනුමක් අවශ්‍ය නොවී, සංක්ෂිප්තව දත්ත පන්ති වියුක්ත ආකාරයකින් විමසීමට ඉඩ සලසන බැවිනි. එය DAO රටාවට පටහැනිව මෙය සිදු කරන කේතය එක තැනක තබයි (නිදසුනක් ලෙස, ඔබට ඉන්වොයිස් දත්ත පංතියක් තිබුනේ නම්, ඔබට එම වර්ගයේ සජලීය වස්තූන් නිපදවන ඉන්වොයිස් ඩීඕඕ එකක් ද ඇත. කේත පදනමේ / යෝජනා ක්‍රමයේ ඇති සියලුම දත්ත වස්තු / වගු).
• IoC බහාලුමක් - මගේ යැපුම් එන්නත් වලින් වැඩි ප්‍රමාණයක් කිරීමට මම ඇත්ත වශයෙන්ම IoC රාමුවක් භාවිතා නොකරන බැවින් මෙය එක් කිරීමට මම පසුබට වෙමි. සෑම දෙයක්ම කන්ටේනරය තුළට විසි කිරීම, එය සොලවා ගැනීම සහ එන්නත් කරන ලද කර්මාන්තශාලා ක්‍රමයක් හරහා ඔබට අවශ්‍ය සිරස්-හයිඩ්‍රේටඩ් පරායත්තතාව වත් කිරීම වැනි දෙවියන්ගේ වස්තු විරෝධී රටාවක් බවට එය ඉක්මනින් පත්වේ. ව්‍යුහය සෑහෙන මොනොලිතික් එකක් වන බව ඔබ තේරුම් ගන්නා තුරු, සහ ලියාපදිංචි තොරතුරු සහිත ව්‍යාපෘතිය, “චතුර ලෙස” නම්, දැන් ඔබේ විසඳුමේ ඇති සියල්ල ගැන සියල්ල දැන සිටිය යුතුය. එය වෙනස් වීමට හේතු රාශියක් ඇත. එය චතුර ලෙස නොවන්නේ නම් (වින්‍යාස ගොනු භාවිතා කරමින් ප්‍රමාද වූ ලියාපදිංචි කිරීම්), එවිට ඔබේ වැඩසටහනේ ප්‍රධාන අංගයක් "මැජික් නූල්" මත රඳා පවතී, ඊට වඩා වෙනස් පණුවන් විය හැකිය.

සොලිඩ් හි 'ඕ' "උදව්වක් සහ දුර්වල ලෙස වටහාගෙන ඇති" ආකාරය පිළිබඳ ජෝන් ස්කීට්ගේ සාකච්ඡාව සමඟ ඔවුන් අවධානය වෙනතකට යොමු කර ඇලිස්ටෙයාර් කොක්බර්න්ගේ "ආරක්ෂිත විචලනය" සහ ජොෂ් බ්ලොච්ගේ "උරුමය සඳහා වූ සැලසුම හෝ එය තහනම් කිරීම" ගැන කතා කරන්න.

ස්කීට්ගේ ලිපියේ කෙටි සාරාංශය (මුල් බ්ලොග් සටහන කියවීමෙන් තොරව ඔහුගේ නම අතහැර දැමීමට මම නිර්දේශ නොකරමි!):

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

OP ඇසුවේ, "මම මෙම ප්‍රශ්නය වඩා හොඳින් හසුරුවන්නේ කෙසේද?" සම්මුඛ පරීක්ෂණයක් පවත්වන ජ්‍යෙෂ් engine ඉංජිනේරුවෙකු ලෙස, වෙඩි උණ්ඩ ලකුණු ලැයිස්තුවක් ඉවත දැමිය හැකි කෙනෙකුට වඩා විවිධ කේත සැලසුම් ශෛලීන්හි වාසි සහ අවාසි ගැන බුද්ධිමත්ව කථා කළ හැකි අපේක්ෂකයෙකු කෙරෙහි මම අතිශයින් උනන්දු වෙමි.

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

විවිධ කාල පරාසයන් සමඟ මෙයට පිළිතුරු දිය හැකි ක්‍රම ගණනාවක් තිබේ. කෙසේ වෙතත්, මෙය "SOLID යන්නෙහි තේරුම ඔබ දන්නවාද?" එබැවින් මෙම ප්‍රශ්නයට පිළිතුරු සැපයීම බොහෝ විට ලකුණු වලට පහර දී එය ව්‍යාපෘතියක් ලෙස පැහැදිලි කිරීමට හේතු වේ.

එබැවින්, පහත සඳහන් දෑ දැකීමට ඔබ අපේක්ෂා කරයි:

• පංති වලට තනි වගකීමක් ඇත (උදා: ගනුදෙනුකරුවන් සඳහා දත්ත ප්‍රවේශ පන්තියක් පාරිභෝගික දත්ත ගබඩාවෙන් පමණක් පාරිභෝගික දත්ත ලබා ගනී).
• පවත්නා හැසිරීම් වලට බලපෑම් නොකර පන්ති පහසුවෙන් විස්තාරණය වේ. අතිරේක ක්‍රියාකාරිත්වය එක් කිරීම සඳහා මට ගුණාංග හෝ වෙනත් ක්‍රම වෙනස් කිරීමට අවශ්‍ය නැත.
• ව්‍යුත්පන්න පංති පදනම් පංති වෙනුවට ආදේශ කළ හැකි අතර එම මූලික පංති භාවිතා කරන කාර්යයන් හැසිරවීම සඳහා මූලික පන්තිය වඩාත් නිශ්චිත වර්ගයට ලිවිය යුතු නොවේ.
• අතුරුමුහුණත් කුඩා වන අතර තේරුම් ගැනීමට පහසුය. පංතියක් අතුරු මුහුණතක් භාවිතා කරන්නේ නම්, කර්තව්‍යයක් ඉටු කිරීම සඳහා ක්‍රම කිහිපයක් මත යැපීම අවශ්‍ය නොවේ.
• කේතය ප්‍රමාණවත් තරම් වියුක්ත කර ඇති අතර ඉහළ මට්ටමේ ක්‍රියාත්මක කිරීම නිශ්චිත පහත් මට්ටමේ ක්‍රියාත්මක කිරීම මත සංයුක්තව රඳා නොපවතී. ඉහළ මට්ටමේ කේතයට බලපෑමක් නොකර පහත් මට්ටමේ ක්‍රියාත්මක කිරීම මාරු කිරීමට මට හැකි විය යුතුය. උදාහරණයක් ලෙස, මගේ ඉතිරි යෙදුමට බලපෑමක් නොකර වෙබ් සේවා පදනම් කරගත් එකක් සඳහා මගේ SQL දත්ත ප්‍රවේශ ස්තරය මාරු කළ හැකිය.

මෙය විශිෂ්ට සම්මුඛ පරීක්ෂණ ප්‍රශ්නයක් යැයි මා සිතුවත් මෙය විශිෂ්ට ප්‍රශ්නයකි.

SOLID මූලධර්ම මගින් පංති සහ අතුරුමුහුණත් සහ ඒවා එකිනෙකට සම්බන්ධ වන ආකාරය පාලනය කරයි.

මෙම ප්‍රශ්නය සැබවින්ම ලිපිගොනු සමඟ වැඩි සම්බන්ධයක් ඇති අතර අනිවාර්යයෙන්ම පන්ති නොවේ.

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

රොබට් මාටින් මෙම මාතෘකාව C ++ විෂය ක්ෂේත්‍රය තුළ සාකච්ඡා කරන්නේ වෛෂයික දිශානත C ++ යෙදුම් බූච් ක්‍රමය භාවිතා කරමින් (සහජීවනය , වසා දැමීම සහ නැවත භාවිතා කිරීමේ හැකියාව පිළිබඳ අංශ බලන්න) සහ පිරිසිදු කේතයෙනි .