පුද්ගලික ක්ෂේත්‍ර ප්‍රමාණවත් නොවන්නේ ඇයි?

privateපන්ති ක්ෂේත්‍ර / ගුණාංග / ගුණාංගවල දෘශ්‍යතාව ප්‍රයෝජනවත්ද? OOP හි, ඉක්මනින් හෝ පසුව, ඔබ පන්තියක උප පංතියක් සෑදීමට යන අතර, එම අවස්ථාවේ දී, එය තේරුම් ගැනීම හොඳය සහ ක්‍රියාත්මක කිරීම සම්පූර්ණයෙන්ම වෙනස් කිරීමට හැකි වේ.

මම පංතියක් උප පංතියේ කරන විට කරන පළමු දෙය නම් privateක්‍රම කිහිපයක් වෙනස් කිරීමයි protected. කෙසේ වෙතත්, බාහිර ලෝකයෙන් තොරතුරු සැඟවීම වැදගත්ය - එබැවින් අපට අවශ්‍ය protectedවන්නේ පමණක් නොවේ public.

මගේ ප්‍රශ්නය නම්: හොඳ මෙවලමක් privateවෙනුවට වැදගත් භාවිත අවස්ථාවක් ගැන ඔබ දන්නවාද protected, නැතහොත් OOP භාෂා සඳහා " protected& public" විකල්ප දෙකක් ප්‍රමාණවත්ද?

ඔබ පවසන පරිදි, protectedතවමත් "ක්‍රියාත්මක කිරීම සම්පූර්ණයෙන්ම වෙනස් කිරීමට" ඔබට හැකියාව ඇත. එය පන්තිය තුළ කිසිවක් අව්‍යාජව ආරක්ෂා නොකරයි.

පංතිය තුළ ඇති දේවල් “අව්‍යාජව ආරක්ෂා කිරීම” ගැන අප සැලකිලිමත් වන්නේ ඇයි? වෙනත් ආකාරයකින් සේවාදායක කේතය කඩ නොකර ක්‍රියාත්මක කිරීමේ තොරතුරු වෙනස් කළ නොහැකි බැවිනි . වෙනත් ආකාරයකින් කිවහොත්, උප පංති ලියන පුද්ගලයින් ද මුල් පාදක පන්තිය ලියූ පුද්ගලයාට “බාහිර ලෝකය” වේ.

ප්‍රායෝගිකව, protectedසාමාජිකයන් මූලික වශයෙන් පංතියේ “උප පංති සඳහා පොදු API” වන අතර publicසාමාජිකයන් මෙන් ස්ථාවර හා පසුපසට අනුකූල විය යුතුය. සත්‍යය නිර්මාණය කිරීමේ හැකියාව අපට නොතිබුනේ නම්private සාමාජිකයන් , ක්‍රියාත්මක කිරීමේදී කිසිවක් වෙනස් කිරීම කිසි විටෙකත් ආරක්ෂිත නොවනු ඇත, මන්ද (අනිෂ්ට නොවන) ග්‍රාහක කේතය කෙසේ හෝ රඳා පැවතීමට ඇති හැකියාව ඔබට බැහැර කළ නොහැකි බැවිනි. එය.

අහම්බෙන්, "ඕඕපී හි, ඉක්මනින් හෝ පසුව, ඔබ පන්තියක උප පංතියක් සෑදීමට යන්නේ" තාක්‍ෂණිකව සත්‍යයක් වන අතර, ඔබේ තර්කය වඩාත් ඉක්මණින් උපකල්පනය කරන්නේ "ඉක්මනින් හෝ පසුව, ඔබ උප පංතියක් සෑදීමට යන්නේ" සෑම පන්තියක්ම “එය එසේ නොවේ.

OOP හි, ඉක්මනින් හෝ පසුව, ඔබ පන්තියක උප පංතියක් සෑදීමට යන්නේ ය

මේක වැරදියි. සෑම පන්තියක්ම උප පංතියට අයත් නොවන අතර සමහර සංඛ්‍යාත්මකව ටයිප් කරන ලද ඕඕපී භාෂාවන්ට එය වැළැක්වීම සඳහා විශේෂාංග ඇත, උදා: final(ජාවා සහ සී ++) හෝ sealed(සී #).

එය තේරුම් ගැනීම හොඳය සහ ක්‍රියාත්මක කිරීම සම්පූර්ණයෙන්ම වෙනස් කිරීමට හැකිවීම.

නැහැ, එය එසේ නොවේ. පංතියකට එහි පොදු අතුරුමුහුණත පැහැදිලිව නිර්වචනය කිරීමට සහ එහි උරුමයන් උරුම වී තිබුණත් ඒවා ආරක්ෂා කර ගැනීමට හැකිවීම හොඳ ය.

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

නැතහොත් ස්කොට් මේයර්ස්ගේ නියමයන්ට අනුව: පන්තියක පෞද්ගලික කොටස් සීමිත කේතයකින් බලපායි: පන්තියේ කේතයම.

පවතින සෑම කේතයක්ම පොදු කොටස් වලට බලපානු ඇති අතර, තවම ලිවිය යුතු සෑම කේතයක්ම අනන්ත ප්‍රමාණයේ කේතයකි.

ආරක්ෂිත කොටස් දැනට පවතින සෑම උප පංතියකටම බලපානු ඇති අතර, තවමත් ලියා නොමැති සෑම උප පංතියකටම එය අනන්ත කේතයකි.

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

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

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

වස්තු දිශානත වැඩසටහනක නිරවද්‍යතාවය පිළිබඳව විධිමත් ලෙස තර්ක කිරීමට උත්සාහ කරන විට, වස්තු ආක්‍රමණ සම්බන්ධ මොඩියුලර් ප්‍රවේශයක් භාවිතා කිරීම සාමාන්‍ය දෙයකි . මෙම ප්රවේශය තුළ

1. ක්‍රම ඔවුන් සමඟ පෙර හා පසු කොන්දේසි (කොන්ත්‍රාත්තු) සමඟ සම්බන්ධ වී ඇත.
2. වස්තූන් ඒවා සමඟ ආක්‍රමණ සම්බන්ධ වී ඇත.

වස්තුවක් පිළිබඳ මොඩියුලර් තර්කනය පහත පරිදි ඉදිරියට යයි (පළමුව අවම වශයෙන් ආසන්න වශයෙන්)

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

object Aඉහත ප්‍රවේශය භාවිතා කරමින් අපි සත්‍යාපනය කරන බව සිතන්න . හා දැන් තහවුරු කිරීමට කැමති method gවන object Bකැඳවුම් method fක object A. මොඩියුලර් තර්කනය මඟින් method gක්‍රියාත්මක කිරීම පිළිබඳව නැවත සලකා බැලීමකින් තොරව තර්ක කිරීමට අපට ඉඩ ලබා දේ method f. ඇමතුම් අඩවියේ වෙනස් නොවන object Aසහ පූර්ව කොන්දේසියක් අපට ස්ථාපිත කළ හැකි නම්, පශ්චාත් ඇමතුම ක්‍රමවේදය ඇමතුමේ හැසිරීමේ සාරාංශයක් ලෙස ගත හැකිය . එපමණක් නොව, ඇමතුම ආපසු ලැබීමෙන් පසු නිශ්චලතාවයේ වෙනස් නොවන බව අපි දැන ගන්නෙමු .method fmethod g,method fA

තර්කනයේ මෙම මොඩියුලරිටි බව නිසා විශාල වැඩසටහන් ගැන විධිමත් ලෙස සිතීමට අපට ඉඩ සලසයි. අපට එක් එක් ක්‍රම ගැන තනි තනිව තර්ක කළ හැකි අතර පසුව මෙම තර්කනයේ ප්‍රති results ල රචනා කර වැඩසටහනේ විශාල කොටස් පිළිබඳව තර්ක කළ හැකිය.

මෙම ක්‍රියාවලියේදී පුද්ගලික ක්ෂේත්‍ර ඉතා ප්‍රයෝජනවත් වේ. වස්තුවක විචල්‍යතාවය එම වස්තුවේ ක්‍රම ඇමතුම් දෙකක් අතර අඛණ්ඩව පවතින බව දැන ගැනීම සඳහා, අපි සාමාන්‍යයෙන් රඳා පවතින්නේ වස්තුව අතරමැදි කාල පරිච්ඡේදයේදී වෙනස් නොකිරීම මත ය.

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

ආරක්ෂිත ක්ෂේත්ර

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

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

මම විධිමත් තර්කනය ගැන කතා කළද, බොහෝ විට සිතන්නේ ක්‍රමලේඛකයින් ඔවුන්ගේ කේතයේ නිරවද්‍යතාවය පිළිබඳව අවිධිමත් ලෙස තර්ක කරන විට ඔවුන් සමහර විට සමාන ආකාරයේ තර්ක මත රඳා සිටින බවයි.

privateපංතියක විචල්‍යයන් බ්ලොක් එකක් තුළ ඇති ප්‍රකාශයක් ප්‍රකාශයකට වඩා හොඳය protectedයන එකම හේතුවට වඩා හොඳ ය ; එනම් මානව ක්‍රමලේඛකයින් දෝෂ සහිත වේ. breakswitchgoto label

protectedgotoප්‍රකාශයන් ස්පැගටි කේතය නිර්මාණය කිරීමට ඉඩ දෙන ආකාරයටම විචල්‍යයන් හිතාමතාම අපයෝජනයට (ක්‍රමලේඛක වැරදි) ණයට දෙයි.

protectedපන්ති විචල්‍යයන් භාවිතයෙන් වැඩ කරන දෝෂ රහිත කේතයක් ලිවිය හැකිද? ඔව් ඇත්ත වශයෙන්ම! භාවිතයෙන් දෝෂ රහිත කේත ලිවීමට හැකි සේම goto; නමුත් ක්ලික් කිරීම අනුව "ඔබට හැකි පමණින්, ඔබ එසේ කළ යුතු යැයි අදහස් නොකෙරේ!"

පංති, සහ ඇත්ත වශයෙන්ම OO ආදර්ශය, අසරණ දෝෂ සහිත මානව ක්‍රමලේඛකයින් වැරදි සිදු කිරීමෙන් ආරක්ෂා වීමට පවතී. මානව වැරදි වලින් ආරක්ෂා වීම පංතිය තුළ ගොඩනගා ඇති ආරක්ෂක පියවරයන් තරම් හොඳ ය. ඔබේ පන්තිය ක්‍රියාත්මක කිරීම protectedබලකොටුවක බිත්තිවල දැවැන්ත සිදුරක් පුපුරවා හැරීමට සමාන වේ.

මූලික පංති වලට ව්‍යුත්පන්න පංති පිළිබඳ දැනුමක් නැත. මූලික පංතියක් සම්බන්ධයෙන් ගත් කල, protectedඇත්ත වශයෙන්ම ඔබට වඩා වැඩි ආරක්ෂාවක් ලබා නොදේ public, මන්ද යත්, ව්‍යුත්පන්න පංතියක් publicපසුපස දොරක් මෙන් හැසිරෙන ගැටර් / සෙටර් එකක් සෑදීමෙන් වළක්වන කිසිවක් නැත .

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

මූලික පංතියකට කළ හැකි හොඳම දෙය නම් එය ක්‍රියාත්මක කිරීම හැකිතාක් සැඟවීම privateසහ ව්‍යුත්පන්න පංති වලින් වෙනස් වීම හෝ පන්තියෙන් පිටත වෙනත් දෙයක් වළක්වා ගැනීම සඳහා ප්‍රමාණවත් සීමාවන් පැනවීමයි.

අවසාන වශයෙන්, මානව දෝෂ අවම කිරීම සඳහා ඉහළ මට්ටමේ භාෂාවන් පවතී. මානව දෝෂ අවම කිරීම සඳහා හොඳ ක්‍රමලේඛන භාවිතයන් ( SOLID මූලධර්ම වැනි ) ද පවතී.

හොඳ ක්‍රමලේඛන භාවිතයන් නොසලකා හරින මෘදුකාංග සංවර්ධකයින්ට අසාර්ථක වීමේ වැඩි ඉඩක් ඇති අතර, බිඳී යා නොහැකි විසඳුම් ලබා දීමට වැඩි ඉඩක් ඇත. හොඳ පුරුදු අනුගමනය කරන අයට අසාර්ථක වීමේ අවදානම අඩු වන අතර වැඩ කළ හැකි නඩත්තු කළ හැකි විසඳුම් නිපදවීමට වැඩි ඉඩක් ඇත.

උරුම පංතිවලට කොන්ත්‍රාත්තු දෙකක් ඇත - එකක් වස්තු යොමු දරන්නන් හා ව්‍යුත්පන්න පන්ති සමඟ. මහජන සාමාජිකයන් විමර්ශන හිමියන් සමඟ ඇති ගිවිසුමට බැඳී සිටින අතර ආරක්ෂිත සාමාජිකයන් ව්‍යුත්පන්න පංති සමඟ ගිවිසුමට බැඳී සිටී.

සාමාජිකයන් සෑදීම protectedඑය වඩාත් බහුකාර්ය පදනම් පංතියක් බවට පත් කරයි, නමුත් බොහෝ විට පන්තියේ අනාගත අනුවාදයන් වෙනස් විය හැකි ක්‍රම සීමා කරයි. සාමාජිකයන් සෑදීම privateපන්තියේ කතුවරයාට පන්තියේ අභ්‍යන්තර කටයුතු වෙනස් කිරීමට වැඩි හැකියාවක් ලබා දෙයි, නමුත් එයින් ප්‍රයෝජනවත් ලෙස ලබා ගත හැකි පන්ති වර්ග සීමා කරයි.

උදාහරණයක් ලෙස List<T>.NET හි ආධාරක ගබඩාව පුද්ගලික කරයි; එය ආරක්‍ෂා කර ඇත්නම්, ව්‍යුත්පන්න කරන ලද වර්ගයන්ට වෙනත් ආකාරයකින් කළ නොහැකි ප්‍රයෝජනවත් දේ කළ හැකි නමුත්, අනාගත අනුවාදයන් List<T>සදහටම එහි මිලියන ගණනක් ඇති ලැයිස්තු සඳහා පවා එහි කැටිති මොනොලිතික් ආධාරක ගබඩාව භාවිතා කළ යුතුය. පසුබිම් ගබඩාව පුද්ගලික කිරීම අනාගත List<T>ව්‍යපෘතිවල ව්‍යුත්පන්න පංති කඩ නොකර වඩාත් කාර්යක්ෂම පසුබිම් ගබඩාවක් භාවිතා කිරීමට ඉඩ සලසයි .

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

එම උපකල්පනය ප්‍රතික්ෂේප කරනු ලැබුවහොත් සලකා බැලිය යුත්තේ අවස්ථා දෙකක් පමණි.

1. මුල් පංතියේ කතුවරයාට එය දීර් extended කළ හැක්කේ මන්ද යන්න පිළිබඳව ඉතා පැහැදිලි අදහස් තිබුණි (උදා: එය බේස්ෆූ එකක් වන අතර පාරට බැස ෆූ ක්‍රියාවට නැංවීම් කිහිපයක් සිදුවනු ඇත).

මෙම අවස්ථාවේ දී, කතුවරයා දන්නවා යමෙකු පන්තිය දීර් extend කරන බවත්, ඒ නිසා ආරක්ෂිත වන්නේ කුමක් ද සහ පෞද්ගලිකව කළ යුත්තේ කුමක් ද යන්න හරියටම දැන ගනු ඇති බවත්. උප පංතිය නිර්මාණය කරන පරිශීලකයාට විවිධ වර්ගයේ අතුරු මුහුණතක් සන්නිවේදනය කිරීම සඳහා ඔවුන් පුද්ගලික / ආරක්ෂිත වෙනස භාවිතා කරයි.

2. ළමා පංතියේ කතුවරයා යම් හැසිරීමක් මව් පංතියට අනවසරයෙන් ඇතුළු කිරීමට උත්සාහ කරයි.

මෙම නඩුව දුර්ලභ විය යුතුය (එය නීත්‍යානුකූල නොවන බව ඔබට තර්ක කළ හැකිය), සහ මුල් කේත පදනමේ මුල් පන්තිය වෙනස් කිරීමට පමණක් කැමති නොවේ. එය නරක නිර්මාණයේ රෝග ලක්‍ෂණයක් ද විය හැකිය. එවැනි අවස්ථාවන්හිදී මම හැසිරීමට අනවසරයෙන් ඇතුළුවන පුද්ගලයා මිතුරන් (සී / සී ++) වැනි වෙනත් හක්ක භාවිතා කිරීමට කැමැත්තෙමිsetAccessible(true) (ජාවා) .

මම හිතන්නේ එම උපකල්පනය ප්‍රතික්ෂේප කිරීම ආරක්ෂිතයි.

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

ප්‍රවේශ මට්ටම් තුනටම ඒවායේ භාවිත නඩුව ඇත, OOP ඒවා කිසිවක් නොමැති අසම්පූර්ණ වනු ඇත. සාමාන්යයෙන් ඔබ එසේ කරයි

• සියලුම විචල්යයන් / දත්ත සාමාජිකයන් පුද්ගලික කරන්න . ඔබගේ අභ්‍යන්තර දත්ත අවුල් කිරීමට පිටතින් කෙනෙකු ඔබට අවශ්‍ය නැත. ඔබේ පොදු හෝ ආරක්ෂිත අතුරුමුහුණතට සහායක ක්‍රියාකාරිත්වය සපයන ක්‍රම (සාමාජික විචල්‍යයන් කිහිපයක් මත පදනම්ව සිතන්න) - මෙය අභ්‍යන්තර භාවිතය සඳහා පමණක් වන අතර අනාගතයේදී එය වෙනස් කිරීමට / වැඩිදියුණු කිරීමට ඔබට අවශ්‍ය විය හැකිය.
• ඔබේ පන්තියේ පොදු අතුරු මුහුණත පොදු කරන්න . ඔබේ මුල් පන්තියේ පරිශීලකයින් සමඟ වැඩ කිරීමට බලාපොරොත්තු වන්නේ එයයි, ව්‍යුත්පන්න පංති මෙන් විය යුතු යැයි ඔබ සිතන්නේ කෙසේද. නිසි සංවර්‍ධනයක් සැපයීම සඳහා මේවා සාමාන්‍යයෙන් ක්‍රම පමණි (සහ උපකාරක පන්ති / ව්‍යුහයන්, එනුම්ස්, ටයිප් ඩෙෆ්, පරිශීලකයාට ඔබේ ක්‍රම සමඟ වැඩ කිරීමට අවශ්‍ය ඕනෑම දෙයක්), විචල්‍යයන් නොවේ.
• ඔබේ පන්තියේ ක්‍රියාකාරිත්වය දීර් extend කිරීමට / විශේෂීකරණය කිරීමට කැමති, නමුත් පොදු අතුරු මුහුණතේ කොටසක් නොවිය යුතු කෙනෙකුට ආරක්ෂිත ක්‍රමවේදයන් ප්‍රකාශ කරන්න - ඇත්ත වශයෙන්ම ඔබ සාමාන්‍යයෙන් පුද්ගලික සාමාජිකයන් වෙත ඔසවා තබයි අවශ්‍ය විටෙක ආරක්ෂා තබයි. සැකයක් ඇත්නම් ඔබ එය නොදන්නා තුරු
  1. ඔබේ පන්තියට උප පංති කළ හැකිය / විය හැකිය,
  2. උප පංතියේ භාවිත අවස්ථා කුමක් විය හැකිද යන්න පැහැදිලි අදහසක් ඇත.

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

වඩාත් සිත්ගන්නාසුලු ප්‍රශ්නයක් නම්, සමහර විට, පුද්ගලික හැර වෙනත් ඕනෑම ක්ෂේත්‍රයක් අවශ්‍ය වන්නේ මන්ද යන්නයි. උප පංතියකට සුපිරි පන්තියක දත්ත සමඟ අන්තර් ක්‍රියා කිරීමට අවශ්‍ය වූ විට, එසේ කිරීමෙන් සෘජුවම දෙදෙනා අතර සෘජු සම්බන්ධතාවයක් ඇති වන අතර, දෙක අතර අන්තර්ක්‍රියාකාරිත්වය සඳහා ක්‍රමවේදයන් භාවිතා කිරීම මඟින් වෙනස්වීම් සිදුකිරීමට හැකි වන පරිදි අවිනිශ්චිතතා මට්ටමකට ඉඩ ලබා දේ. සුපිරි පන්තිය වෙනත් ආකාරයකින් ඉතා අපහසු වනු ඇත.

භාෂා ගණනාවක් (උදා: රූබි සහ ස්මාල්ටෝක්) පොදු ක්ෂේත්‍ර සපයන්නේ නැති නිසා සංවර්ධකයින් ඔවුන්ගේ පන්ති ක්‍රියාත්මක කිරීමට සෘජුවම සම්බන්ධ වීමට ඉඩ නොදෙනු ඇත. නමුත් තවදුරටත් ඉදිරියට ගොස් පෞද්ගලික ක්ෂේත්‍ර පමණක් තිබිය යුත්තේ ඇයි? සාමාන්‍යත්වය නැතිවීමක් සිදු නොවනු ඇත (මන්ද යත්, සුපිරි පන්තියට සෑම විටම උප පංතිය සඳහා ආරක්ෂිත ප්‍රවේශයන් සැපයිය හැකි බැවිනි), නමුත් පන්තිවලට සෑම විටම අවම වශයෙන් කුඩා ප්‍රමාණයක් ඔවුන්ගේ උප පංති වලින් හුදකලා වීම සහතික කරයි. මෙය වඩාත් පොදු නිර්මාණයක් නොවන්නේ ඇයි?

මෙහි හොඳ පිළිතුරු ගොඩක්, නමුත් මම කෙසේ හෝ මගේ ශත දෙක තුළට විසි කරමි. :-)

ගෝලීය දත්ත නරක යැයි එකම හේතුව නිසා පුද්ගලික හොඳයි.

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

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

සමහර විරුද්ධ මතයන් සඳහන් කිරීම වටී යැයි මම සිතමි.

න්‍යාය අනුව, වෙනත් පිළිතුරු වල සඳහන් සියලු හේතුන් සඳහා ප්‍රවේශ මට්ටම පාලනය කිරීම හොඳය.

ප්‍රායෝගිකව, බොහෝ විට කේත සමාලෝචනය කිරීමේදී, මම දකින්නේ (පුද්ගලික භාවිතා කිරීමට කැමති), පුද්ගලික -> ආරක්ෂිත සහ බොහෝ විට ආරක්ෂිත -> මහජනතාවගෙන් ප්‍රවේශ මට්ටම වෙනස් කිරීම. සෑම විටම පාහේ, පන්ති ගුණාංග වෙනස් කිරීම සඳහා සැකසුම් / ලබා ගන්නන් වෙනස් කිරීම ඇතුළත් වේ. මේවා මගේ කාලය (කේත සමාලෝචනය) සහ ඔවුන්ගේ (කේතය වෙනස් කිරීම) බොහෝ කාලයක් නාස්ති කර ඇත.

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

එය අභ්‍යන්තර කේතය සමඟ වූ අතර ඔබට අවශ්‍ය නම් එය සැමවිටම වෙනස් කළ හැකිය. කේතය වෙනස් කිරීම එතරම් පහසු නොවන විට තෙවන පාර්ශවීය කේත සමඟ තත්වය වඩාත් නරක ය.

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

ඉමෝ එය ගතික / ස්ථිතික ටයිප් කිරීමට බෙහෙවින් සමාන ය. න්‍යාය අනුව, ස්ථිතික ටයිප් කිරීම ඉතා හොඳයි. ප්රායෝගිකව, එය වලක්වනු ලබන්නේ 2% දෝෂ වැනි පමණි . ගතික ටයිප් කිරීමේ අසාධාරණ ective ලදායීතාවය .... පුද්ගලිකව භාවිතා කිරීම ඊට වඩා අඩු දෝෂයක් වළක්වයි.

SOLID මූලධර්ම හොඳයි යැයි මම සිතමි, පොදු, ආරක්ෂිත සහ පෞද්ගලික සමඟ පන්තියක් නිර්මාණය කිරීම ගැන ඔවුන් සැලකිලිමත් වනවාට වඩා ඔවුන් ගැන සැලකිලිමත් වනු ඇතැයි මම ප්‍රාර්ථනා කරමි.

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

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

ඒ හැර, ඔබේ උප පංතිවලට පවා යමක් පෞද්ගලිකව තබා ගැනීමට තවත් බොහෝ හේතු තිබේ. ඔවුන් කරන්නේ කුමක්ද යන්න නොදන්නා අයෙකු විසින් වෙනස් කරනු ලැබුවහොත් (බොහෝ විට ඔබේ කේතය භාවිතා කරන වෙනත් පුද්ගලයින් ගැන සිතමින්) පන්තියේ නිවැරදි ක්‍රියාකාරිත්වය අවුල් කළ හැකි ක්‍රියාත්මක කිරීමේ තොරතුරු සැඟවීම විය හැකිය.

පුද්ගලික ක්‍රම / විචල්‍යයන් සාමාන්‍යයෙන් උප පංතියකින් සඟවනු ඇත. එය හොඳ දෙයක් විය හැකිය.

පුද්ගලික ක්‍රමයකට පරාමිතීන් පිළිබඳ උපකල්පන කළ හැකි අතර ඇමතුම්කරුට සනීපාරක්ෂාව පරීක්ෂා කිරීම කළ හැකිය.

ආරක්ෂිත ක්‍රමයක් මඟින් යෙදවුම් සනීපාරක්ෂාව පරීක්ෂා කළ යුතුය .

“පුද්ගලික” යන්නෙන් අදහස් කරන්නේ: පංතිය හැර වෙන කිසිවෙකු විසින් වෙනස් කිරීමට හෝ ප්‍රවේශ වීමට අදහස් නොකෙරේ. උප පංති මගින් වෙනස් කිරීමට හෝ ප්‍රවේශ වීමට අදහස් නොකෙරේ. උප පංති? කුමන උප පංති? ඔබ මෙය උප වර්ගීකරණය නොකළ යුතුය!

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

මෙහි පැහැදිලි වෙනසක් ඇත. මම යමක් පෞද්ගලිකව කළහොත්, ඔබ ඔබේ අපිරිසිදු ඇඟිලි එයින් keep ත් කර තැබිය යුතුය. ඔබ උප පංතියක් වුවද.

මම පංතියක් උප පංතියේ කරන විට කරන පළමු දෙය නම් පුද්ගලික ක්‍රම රාශියක් ආරක්‍ෂාව සඳහා වෙනස් කිරීමයි

privateඑදිරිව protected ක්‍රම පිළිබඳ සමහර තර්ක :

privateක්‍රම නැවත භාවිතා කිරීම වළක්වයි. උප පංතියකට පුද්ගලික ක්‍රමයේදී කේතය භාවිතා කළ නොහැකි අතර එය නැවත ක්‍රියාත්මක කිරීමට සිදුවිය හැකිය - නැතහොත් පුද්ගලික ක්‍රමය මත මුලින් රඳා පවතින ක්‍රමය (ය) නැවත ක්‍රියාත්මක කරන්න.

අනෙක් අතට, වන ඕනෑම ක්රමයක් නොවන private අර්ථයෙන්, "බාහිර ලෝකයට" කිරීමට පන්තිය විසින් සපයන ලද API ලෙස දැකිය හැක තෙවන පාර්ශවීය උප වර්ගිකරණයන් වෙන කෙනෙක් ඔහුගේ පිළිතුර යෝජනා ලෙස, ඉතා "පිටත ලෝකය" ලෙස සලකනු ලබයි දැනටමත්.

ඒක නරක දෙයක්ද? - මම හිතන්නේ නැහැ.

ඇත්ත වශයෙන්ම, (ව්‍යාජ) පොදු API එකක් මුල් ක්‍රමලේඛකය අගුළු දමා එම අතුරුමුහුණත් නැවත ප්‍රතිස්ථාපනය කිරීමට බාධා කරයි. නමුත් අනෙක් පැත්තෙන් බැලූ විට, ක්‍රමලේඛකයෙකු තමාගේ පොදු ක්‍රියාත්මක කිරීමේ තොරතුරු තරම් පිරිසිදු හා ස්ථාවර ආකාරයකින් තමාගේම “ක්‍රියාත්මක කිරීමේ තොරතුරු” නිර්මාණය නොකළ යුත්තේ ඇයි? privateඔහුගේ "පුද්ගලික" කේතය සැකසීම ගැන ඔහුට කම්මැලි විය හැකි වන පරිදි ඔහු භාවිතා කළ යුතුද ? කිසිවෙකු නොදකින නිසා ඔහුට පසුව එය පිරිසිදු කළ හැකි යැයි සිතනවාද? - නොමැත.

ක්‍රමලේඛකයා තම “පුද්ගලික” කේතය ගැන මඳක් සිතා බැලිය යුතු අතර, එය හැකි තාක් දුරට නැවත භාවිතා කිරීමට ඉඩ සලසන හෝ ප්‍රවර්ධනය කරන අයුරින් එය සැකසීමට. එවිට පුද්ගලික නොවන කොටස් අනාගතයේ දී යම් බියක් තරම් බරක් නොවනු ඇත.

මා දකින බොහෝ (රාමු) කේතයන් නොගැලපෙන ලෙස භාවිතා කරයි private: protected, පුද්ගලික ක්‍රමයකට පැවරීමට වඩා වැඩි යමක් කරන අවසාන නොවන ක්‍රම බහුලව දක්නට ලැබේ. protected, පුද්ගලික ක්ෂේත්‍රයන්ට සෘජුවම ප්‍රවේශ වීමෙන් පමණක් කොන්ත්‍රාත්තුව ඉටු කළ හැකි අවසාන නොවන ක්‍රම.

මෙම ක්‍රමෝපායන් තර්කානුකූලව අභිබවා / වැඩි දියුණු කළ නොහැක, තාක්‍ෂණිකව එය (සම්පාදක) පැහැදිලි කිරීමට කිසිවක් නැත.

විස්තීරණතාව සහ උරුමය අවශ්‍යද? ඔබේ ක්‍රම සකස් නොකරන්න private.

ඔබේ පන්තියේ යම් හැසිරීමක් වෙනස් කිරීමට අවශ්‍ය නැද්ද? ඔබේ ක්‍රම සාදන්න final.

ඔබේ ක්‍රමය නිශ්චිත, මනාව නිර්වචනය කළ සන්දර්භයකට පිටින් කැඳවිය නොහැකිද? ඔබේ ක්‍රමවේදය සකසන්න privateසහ / හෝ වෙනත් protectedඑතීමේ ක්‍රමයක් හරහා නැවත භාවිතා කිරීම සඳහා අවශ්‍ය මනාව නිර්වචනය කළ සන්දර්භය ඔබට ලබා ගත හැකි ආකාරය ගැන සිතා බලන්න .

ඒ නිසා මම privateඅරපිරිමැස්මෙන් භාවිතා කරන්නැයි යෝජනා කරමි . හා පටලවා නොගත කිරීමට privateසමග final. - ක්‍රමවේදයක් ක්‍රියාත්මක කිරීම පන්තියේ සාමාන්‍ය කොන්ත්‍රාත්තුවට අත්‍යවශ්‍ය වන අතර එය ප්‍රතිස්ථාපනය / ඉක්මවා නොයැවිය යුතු නම්, එය සාදන්න final!

ක්ෂේත්‍ර සඳහා, privateඇත්තෙන්ම නරක නැත. ක්ෂේත්රයේ (ව) ලෙස දීර්ඝ ලෙස සාධාරණ (බව, සුදුසු ක්රම මගින් "භාවිතා" කළ හැකි නොවේ getXX() හෝ setXX()!).

ආරක්ෂිත වෙනුවට පුද්ගලික භාවිතා කිරීම හොඳ මෙවලමක් වන වැදගත් භාවිත අවස්ථාවක් ගැන ඔබ දන්නවාද, නැතහොත් OOP භාෂා සඳහා “ආරක්ෂිත සහ පොදු” විකල්ප දෙකක් ප්‍රමාණවත් වේද?

පුද්ගලික : ඔබට කිසියම් උප පංතියකට ඇමතීමට හෝ අභිබවා යාමට ප්‍රයෝජනවත් නොවන දෙයක් ඇති විට.

ආරක්ෂිතයි : ඔබට උප පංතියට විශේෂිත වූ ක්‍රියාත්මක කිරීමක් / නියතයක් ඇති විට.

උදාහරණයක්:

public abstract Class MercedesBenz() extends Car {
  //Might be useful for subclasses to know about their customers
  protected Customer customer; 

  /* Each specific model has its own horn. 
     Therefore: protected, so that each subclass might implement it as they wish
  */
  protected abstract void honk();

  /* Taken from the car class. */
  @Override
  public void getTechSupport(){
     showMercedesBenzHQContactDetails(customer);
     automaticallyNotifyLocalDealer(customer);
  }

  /* 
     This isn't specific for any subclass.
     It is also not useful to call this from inside a subclass,
     because local dealers only want to be notified when a 
     customer wants tech support. 
   */
  private void automaticallyNotifyLocalDealer(){
    ...
  }
}

මේ කාරණය තේරුම් ගැනීම මට අපහසු විය, එබැවින් මගේ අත්දැකීම් වලින් කොටසක් බෙදා ගැනීමට මම කැමතියි:

• මොකක්ද මේ ආරක්ෂිත ක්ෂේත්රයද? එය ක්ෂේත්‍රයකට වඩා වැඩි දෙයක් නොවේ, එය පන්තියෙන් පිටත ප්‍රවේශ විය නොහැක, එනම් ප්‍රසිද්ධියේ මේ වගේ : $classInstance->field. එය "මේ එයයි" යන උපක්‍රමය. ඔබේ පංතියේ ළමයින්ට එයට පූර්ණ ප්‍රවේශයක් ලැබෙනු ඇත , මන්ද එය ඔවුන්ගේ නියම අභ්‍යන්තර කොටසයි.
• පුද්ගලික ක්ෂේත්‍රය යනු කුමක්ද? එය ඔබේම පන්තියට සහ මෙම පන්තිය ඔබ විසින්ම ක්‍රියාත්මක කිරීමට “ සැබෑ පුද්ගලික ” ය . Medicine ෂධ බෝතලයක් මෙන් "ළමයින්ට ළඟා නොවී සිටින්න". ඔබේ පන්තියේ ව්‍යුත්පන්නයන් මගින් එය ආපසු හැරවිය නොහැකි බවට ඔබට සහතිකයක් ඇත, ඔබේ ක්‍රම - කැඳවූ විට - ඔබ ප්‍රකාශ කළ දේ හරියටම ඇත

යාවත්කාලීන කිරීම: මා විසින් විසඳන ලද සැබෑ කර්තව්‍යයක ප්‍රායෝගික උදාහරණයකි. මෙන්න එයයි: ඔබට USB හෝ LPT වැනි ටෝකනයක් තිබේ (එය මගේ කාරණයයි), ඔබට මිඩ්ල්වෙයාර් එකක් තිබේ. ටෝකනය ඔබෙන් පින්කෝඩ් එකක් ඉල්ලයි, එය නිවැරදි නම් විවෘත වන අතර ඔබට සංකේතාත්මක කොටස සහ යතුර ගණනාවක් තේරුම් ගැනීමට යැවිය හැකිය. යතුරු ටෝකන තුළ ගබඩා කර ඇත, ඔබට ඒවා කියවිය නොහැක, ඒවා පමණක් භාවිතා කරන්න. එහි සිටි තාවකාලික සංකේත ප්රධාන විසින් අත්සන් තබන ලද සැසිය සඳහා යතුරු, නමුත් මිඩ්ල්වෙයාර් ම ගබඩා කර. තාවකාලික යතුර රියදුරු මට්ටමින් පැවතීම සඳහා පිටත කොතැනක හෝ කාන්දු නොවිය යුතුය. මෙම තාවකාලික යතුර සහ දෘඩාංග සම්බන්ධතා ආශ්‍රිත දත්ත ගබඩා කිරීම සඳහා මම පුද්ගලික ක්ෂේත්‍රයක් භාවිතා කළෙමි . එබැවින් කිසිදු ව්‍යුත්පන්නයකට පොදු අතුරු මුහුණතක් පමණක් නොව සමහරක් ද භාවිතා කිරීමට නොහැකි විය ආරක්ෂිතදමම කාර්යයක් සඳහා සාදන ලද “හුරුබුහුටි” සබ්ට්‍රවුටින්, නමුත් යතුරු සහ එච්ඩබ්ලිව් අන්තර්ක්‍රියා සමඟ ශක්තිමත් කොටුවක් විවෘත කිරීමට නොහැකි විය. තේරුමක් තිබේද?