අපට පුද්ගලික විචල්‍යයන් අවශ්‍ය වන්නේ ඇයි?

පංති වලදී අපට පුද්ගලික විචල්‍යයන් අවශ්‍ය වන්නේ ඇයි?

මා කියවා ඇති ක්‍රමලේඛනය පිළිබඳ සෑම පොතක්ම පවසන්නේ මෙය පුද්ගලික විචල්‍යයක් බවයි, ඔබ එය නිර්වචනය කරන්නේ එලෙසයි.

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

1. පුද්ගලික විචල්‍යයන් වළක්වා ගැනීමට උදව් කරන්නේ කුමක්ද?

2. කිසියම් දේපලක් පෞද්ගලික විය යුතුද නැද්ද යන්න ඔබ තීරණය කරන්නේ කෙසේද? පෙරනිමියෙන් සෑම ක්ෂේත්‍රයක්ම පෞද්ගලික විය යුතු නම් පංතියක පොදු දත්ත සාමාජිකයන් සිටින්නේ ඇයි?

3. විචල්‍යයක් ප්‍රසිද්ධ කළ යුත්තේ කුමන තත්වයන් යටතේද?

එය එතරම් විශ්වාසනීය කාරණයක් නොව සංකීර්ණත්වය කළමනාකරණය කිරීමේ එකකි.

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

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

තවත් වාසියක් වන්නේ 'සම්බන්ධ කිරීම' යන සංකල්පයයි. වෙනත් පංතියක් විසින් භාවිතා කරනු ලබන mපන්තියක පොදු සාමාජිකයෙකු යැපීමක් හඳුන්වා දෙයි: ඔබ වෙනස් වන්නේ නම් , ඔබ තුළ ඇති භාවිතයන් ද පරීක්ෂා කළ යුතුය. ඊටත් වඩා භයානක දෙය නම්, පන්තියේ කිසිවක් භාවිතා කරන්නේ කොතැනදැයි ඔබට නොකියයි , එබැවින් නැවතත් ඔබට සම්පූර්ණ කේත පදනම හරහා සෙවිය යුතුය; එය ඔබ ලියන පුස්තකාලයක් නම්, පිටත කේතයක් ඇති බවට සහතික කර ගත යුතුයABmAmBAmඔබගේ වෙනස්වීම නිසා ඔබේ ව්‍යාපෘතිය කැඩී යන්නේ නැත. ප්‍රායෝගිකව, පුස්තකාල කොතරම් වේදනාකාරී වුවත්, ඒවායේ මුල් ක්‍රමයේ අත්සන සමඟ රැඳී සිටීමට නැඹුරු වන අතර, පසුව ප්‍රධාන අනුවාද යාවත්කාලීනයක් සමඟ බිඳෙන වෙනස්කම් වල කොටසක් හඳුන්වා දෙයි. පුද්ගලික සාමාජිකයන් සමඟ, ඊට වෙනස්ව, ඔබට එකවරම පරායත්තයන් බැහැර කළ හැකිය - ඔවුන්ට පිටතින් ප්‍රවේශ විය නොහැක, එබැවින් සියලු පරායත්තතා පන්තිය තුළ අඩංගු වේ.

මෙම සන්දර්භය තුළ, "වෙනත් ක්‍රමලේඛකයන්ට" ඔබේ අනාගතය සහ අතීතය ඇතුළත් වේ. ඔබේ විචල්ය Y සමඟ X මේ දේ නොකළ යුතු බව ඔබ දැන් දන්නා නමුත් ගනුදෙනුකරුවකුට යම් අංගයක් ක්ෂණිකව ක්‍රියාත්මක කිරීමට අවශ්‍ය වූ විට මාස තුනක් පාරට බැසීමට ඔබට සිදුවනු ඇත. අපැහැදිලි ආකාරවලින් Y.

එබැවින්, ඔබ දේවල් පුද්ගලික කළ යුත්තේ කවදාද යන්න ගැන: මම කියන්නේ පෙරනිමියෙන් සියල්ල පුද්ගලික කර ගන්න, ඉන්පසු ප්‍රසිද්ධියේ තිබිය යුතු කොටස් පමණක් හෙළි කරන්න. ඔබට වැඩි වැඩියෙන් පුද්ගලික කළ හැකි තරමට වඩා හොඳය.

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

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

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

මෙහි මූලික පදය එන්කැප්සුලේෂන් ය . OOP හි ඔබේ වස්තූන් / පංති නිසි ලෙස සංයුක්ත කිරීම බලාත්මක කිරීම සඳහා පුද්ගලික විචල්‍යයන් භාවිතා කිරීමට ඔබට අවශ්‍යය.

වෙනත් ක්‍රමලේඛකයින් ඔබව ලබා ගැනීමට නොසිටින අතර, ඔවුන් ඔබේ කේතය සමඟ අන්තර් ක්‍රියා කරයි. ඔබ විචල්‍යයක් පුද්ගලිකව නොකරන්නේ නම්, ඔවුන් කිසිඳු හානියක් කිරීමට අකමැතිව එය ඔවුන්ගේම කේතයෙන් යොමු කරයි. කෙසේ වෙතත්, ඔබට නැවත ඔබේ පන්තියට ගොස් යමක් වෙනස් කිරීමට අවශ්‍ය නම්, කුමන විචල්‍යය සහ කොතැන භාවිතා කරන්නේද යන්න ඔබ තවදුරටත් නොදනී. සංවෘත කිරීමේ පරමාර්ථය වන්නේ පංතියේ බාහිර අතුරුමුහුණත පැහැදිලිව දැක්වීමයි, එවිට ඔබ දන්නවා (සාමාන්‍යයෙන්) මෙම ක්‍රම පමණක් අන් අයට භාවිතා කළ හැකි බව.

1. එබැවින් පුද්ගලික විචල්‍යයන් අනුරූප විචල්‍යය නිර්වචනය කරන පන්තියේ පමණක් පවතින බව සහතික කරයි. ඔබට එය වෙනස් කිරීමට අවශ්‍ය නම්, වෙනස පන්තියටම දේශීය වේ.

2. C ++ හෝ Java වැනි සාම්ප්‍රදායික භාෂා වලදී, ඔබ සාමාන්‍යයෙන් සෑම දෙයක්ම පුද්ගලික කරවන අතර ඒවාට ප්‍රවේශ විය හැක්කේ අනුරූප ලබා ගන්නන් සහ සැකසුම් කරුවන්ට පමණි. ඇත්ත වශයෙන්ම බොහෝ දේ තීරණය කිරීමට අවශ්‍ය නැත.

3. සමහර විට, f.ex. C ++ ව්‍යුහයක, ඔබට පන්තියක් අවශ්‍ය වන්නේ කරුණු කිහිපයක් එකට එකතු කිරීමේ ක්‍රමයක් ලෙස පමණි. උදාහරණයක් ලෙස, xසහ yගුණාංග පමණක් ඇති දෛශික පන්තියක් සලකා බලන්න . එවැනි අවස්ථාවන්හිදී, මෙම ගුණාංග පොදු ලෙස ප්‍රකාශ කිරීමෙන් ඔබට access ජුව ප්‍රවේශ වීමට ඉඩ දිය හැකිය. විශේෂයෙන්, පිටතින් ඇති යම් කේතයක් ඔබේ පන්තියේ වස්තුවක් නව අගයන් කෙලින්ම ලිවීමෙන් xහෝ වෙනස් කිරීමෙන් ඔබ ගණන් නොගත යුතුය y.

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

එම භාෂාවලින්, ඔබට ඒකාකාර ප්‍රවේශ මූලධර්මය යනුවෙන් යමක් ලැබෙනු ඇත , එහිදී යමෙක් හිතාමතාම ලබා ගන්නන් සහ සැකසුම් වැනි ක්‍රම වෙන්කර හඳුනා නොගනී, නමුත් විචල්‍ය / ශ්‍රිතයට access ජු ප්‍රවේශයක් සපයයි. එබැවින් වස්තූන් මත පදනම් වූ අවස්ථා වලදී පුද්ගලික ප්‍රකාශයන් බෙහෙවින් ජනප්‍රිය බව ඔබට පැවසිය හැකිය.

වෙනත් ක්ෂේත්‍ර ඇතුළත් කිරීම සඳහා ඔබේ දැනුම පුළුල් කිරීම මඟින් පවත්නා සංකල්ප නව ආකාරයකින් බැලීමට ඔබව පොළඹවන ආකාරයද මෙයින් පෙන්නුම් කෙරේ.

පුද්ගලික විචල්‍යයන් මඟින් වස්තුවක හෝ ශ්‍රිතයේ විෂය පථයෙන් පිටත පසුකාලීන යොමු කිරීම් වෙනත් විචල්‍යයන්ට නොදැනුවත්ව බලපාන බව සහතික කරයි. විශාල ක්‍රමලේඛන ව්‍යාපෘති සඳහා, මෙය සිත්ගන්නාසුලු ගැටළු රාශියක් වළක්වා ගැනීමට උපකාරී වේ (ඒවා සාමාන්‍යයෙන් සම්පාදකයා විසින් අල්ලා නොගනී).

නිදසුනක් ලෙස, ජාවාස්ක්‍රිප්ට් වැනි මූලාකෘති භාෂාවන්ට පරිශීලකයින්ට සුදුසු යැයි පෙනෙන පරිදි විචල්‍යයන් මත කපරාරු කිරීමට ඉඩ දිය හැකිය:

function SomeObject() {
    this.a = 2; //Public (well, actually protected) variable

    this.showA = function() {
        alert(this.a);
    }
}

//Some lines down...

var obj = new SomeObject();
obj.a = 3;
obj.showA(); //Will alert 3. Uh oh!

එම විචල්‍යය පුද්ගලික නම්, එය පිටතින් වෙනස් කළ නොහැක:

function SomeObject() {
    var a = 2; //Private variable

    this.showA = function() {
        alert(a);
    }
}

//Some lines down...

var obj = new SomeObject();
obj.a = 3;
obj.showA(); //Will alert 2

සෑම විචල්‍යයක්ම පුද්ගලික විය යුතු නොවන අතර පුද්ගලික විචල්‍යයන් අධික ලෙස භාවිතා කිරීමෙන් ඇත්ත වශයෙන්ම කේතය වඩාත් කරදරකාරී විය හැකිය. වස්තුවක බරපතල බලපෑමක් නැති බව සුළු ක්ෂේත්ර අවශ්ය නැහැ get()සහ set()ක්රම.

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

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

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

පෞද්ගලිකත්වය නොමැති භාෂාවන් එවැනි නිර්මාණයක් කළ නොහැකි බව නොවේ. එවැනි දෙයක් ලිවීමට foo.getBar()පෙළඹවීම වෙනුවට, ලිවීමට පහසු නිසා, ලබා ගන්නෙකු අවශ්‍ය නොවන බව සිතීමට මිනිසුන් පෙළඹේ foo.bar, නමුත් පසුව ඔබ වැනි දීර් mon රාක්ෂයන් සමඟ අවසන් වූ විට එම තීරණය නැවත සලකා බලනු නොලැබේ obj.container[baz].foo.bar. කිසි විටෙක දැඩි භාෂාවකින් වැඩ නොකළ ක්‍රමලේඛකයන්ට එහි ඇති වැරැද්ද කුමක් දැයි නොපෙනේ.

පුද්ගලිකත්වය නොමැති භාෂාවලින් මිනිසුන් බොහෝ විට එය අනුකරණය කරන නාමකරණ ප්‍රමිතීන් අනුගමනය කරනු ඇත, එනම් සියලු "පුද්ගලික" සාමාජිකයින්ට අවධාරනය කිරීම. භාෂාව එය බලාත්මක නොකරන විට පවා එය ප්‍රයෝජනවත් සං signal ාවක්.

සෑම විචල්‍යයක්ම පොදු විය යුතු නම් මිස ඒවා පෞද්ගලික විය යුතුය (එය කිසි විටෙකත් නැති තරම්ය, ඔබ දේපල / ලබා ගන්නන් සහ සැකසුම් භාවිතා කළ යුතුය).

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

• පුද්ගලික විචල්‍යයන් වළක්වා ගැනීමට උදව් කරන්නේ කුමක්ද?

එය අතුරු මුහුණත යනු කුමක්ද සහ ඇත්ත වශයෙන්ම මූලික ක්‍රියාකාරිත්වය කුමක්ද යන්න පැහැදිලි කිරීම ය. පොදු ක්‍රම / ගුණාංග යනු ඔබේ කේත භාවිතා කරන වෙනත් කේතයන් වේ. මම කිසි විටෙකත් එකම ව්‍යාපෘතියක 100+ කණ්ඩායම්වල වැඩ කර නැත, නමුත් මා විසින් ලියන ලද දේවල් භාවිතා කරන වෙනත් සංවර්ධකයින් 20 ක් දක්වා 3-5 ක කණ්ඩායම් පිළිබඳ මගේ අත්දැකීම් අනුව, අනෙක් කරුණු මෝඩකමක් ලෙස පෙනේ.

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

• නිශ්චිත දේපල සමූහයක් පෞද්ගලික විය යුතුද නැද්ද යන්න ඔබ තීරණය කරන්නේ කෙසේද? පෙරනිමියෙන් සෑම ක්ෂේත්‍රයක්ම පෞද්ගලික විය යුතු නම් පංතියක පොදු දත්ත සාමාජිකයන් සිටින්නේ ඇයි?

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

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

• විචල්‍යයක් ප්‍රසිද්ධ කළ යුත්තේ කුමන තත්වයන් යටතේද?

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

SO පිළිබඳ අදාළ ප්‍රශ්නයකට මගේ මෙම ලිපිය බලන්න .

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

ස්වයං ලේඛන කේතයේ නිසි සාමාජික විෂය පථය ප්‍රධාන වේ.

මම සැබෑ උදාහරණයක් භාවිතා කරමින් වෙනස් දෘෂ්ටිකෝණයකින් සංසරණය වීමේ වටිනාකම ගැන කතා කරන්නෙමි. මීට කලකට පෙර (80 දශකයේ මුල් භාගයේ) රේඩියෝ ෂැක් වර්ණ පරිගණකය සඳහා ඩන්ජියොන්ස් ඔෆ් ඩග්ගොරත් නමින් ක්‍රීඩාවක් ලියා ඇත. මීට වසර කිහිපයකට පෙර, රිචඩ් හුනර්ලච් එය කඩදාසි එකලස් කිරීමේ ලැයිස්තුවෙන් සී / සී ++ ( http://mspencer.net/daggorath/dodpcp.html ) වෙත ගෙන ගියේය. ටික කලකට පසු, මම කේතය ලබාගෙන වඩා හොඳ සංවර්‍ධනයක් ලබා දීම සඳහා එය නැවත සාධක කිරීමට පටන් ගතිමි ( http://dbp-consulting.com/stuff/ ).

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

කේතය විහිළුවට ලක්වීමට පටන් ගත් විට, හඳුනා නොගත් දෝෂ පහව ගියේය. කේතය උසස් තත්ත්වයේ බවට පත් විය. සෑම කාර්යයක්ම කේතයේ එක් ස්ථානයක වගකීම බවට පත් වූ අතර එය නිවැරදිව ලබා ගැනීමට ඇත්තේ එක් ස්ථානයක් පමණි. (මම කේතය හරහා තවත් සමත් වූ සෑම අවස්ථාවකම මම තව බොහෝ දේ සොයා ගතිමි.)

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

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

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

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

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

OOP සංකල්පයට උරුමය එහි එක් අංගයක් ඇත (ජාවා හෝ සී ++). එබැවින් අපි උරුම කර ගැනීමට යන්නේ නම් (එයින් අදහස් කරන්නේ අපි උරුම වූ පන්තියේ විචල්‍යයන්ට ප්‍රවේශ වීමට යන බවයි), එම විචල්‍යයන්ට බලපෑම් කිරීමේ හැකියාව ඇත. එබැවින් විචල්යයන් වෙනස් කළ හැකිද නැද්ද යන්න අප විසින් තීරණය කළ යුතුය.

මෙම අරමුණු සඳහා පමණක්, අපි OOP හි ප්‍රවේශ විකරණකාරක භාවිතා කරමු. නවීකරණ වලින් එකක් පුද්ගලික වන අතර එයින් අදහස් කරන්නේ එයට ප්‍රවේශ විය හැක්කේ එම පන්තියට පමණි. වෙනත් ඕනෑම පන්තියකට එම විචල්‍යයන්ට බලපෑම් කළ නොහැක.

අප දන්නා පරිදි, ආරක්ෂිත යන්නෙන් අදහස් කරන්නේ එය උරුම වීමට යන පන්තියට ප්‍රවේශ විය හැකි බවයි.

OOP හි නවීකරණ සංකල්පයක් පවතින්නේ ඇයි, මෙම හේතු නිසා (ඕනෑම පන්තියකට OOP සංකල්පය භාවිතා කර වෙනත් පන්ති විචල්‍යයන්ට ප්‍රවේශ විය හැකිය). නවීකරණ සංකල්පයක් නොමැති නම්, එයින් අදහස් වන්නේ පන්ති උරුම කර ගැනීමේදී හෝ වෙනත් OOP සංකල්ප භාවිතා කිරීමේදී එය දුෂ්කර වනු ඇති බවයි.

වෙනත් අය පවසන පරිදි, වස්තුව නොගැලපෙන තත්වයකට ගෙන යාම සහ වැරදි සහ අනපේක්ෂිත ව්‍යතිරේකයන් සොයා ගැනීමට අපහසු වීම නිසා පුද්ගලික විචල්‍යයන් හොඳය.

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

විස්තාරිත උප පංතියකට ආරක්ෂිත ක්ෂේත්‍ර වෙත පූර්ණ ප්‍රවේශයක් ලැබෙනු ඇති අතර එමඟින් එම ක්ෂේත්‍ර පොදු වූවාක් මෙන් වස්තුව බිඳෙන සුළු වනු ඇත, නමුත් එම අස්ථාවරත්වය එය ස්වයං විස්තාරණය කරන පන්තියට පමණක් සීමා වේ (එවැනි ක්ෂේත්‍ර ඊටත් වඩා නිරාවරණය නොවන්නේ නම්).

එබැවින්, පොදු ක්ෂේත්‍ර හොඳ යැයි සැලකීම දුෂ්කර වන අතර, අද වන විට ඒවා භාවිතා කිරීමට ඇති එකම හේතුව වින්‍යාස පරාමිතිය ලෙස භාවිතා කරන පන්ති සඳහා ය (බොහෝ ක්ෂේත්‍ර හා තර්කනයක් නොමැති ඉතා සරල පංතියකි, එවිට පන්තිය පරාමිතියක් ලෙස පමණක් සම්මත වේ යම් ක්‍රමයක්).

නමුත් අනෙක් අතට, පුද්ගලික ක්ෂේත්‍ර මඟින් ඔබේ කේතයේ නම්‍යතාවය වෙනත් පරිශීලකයින්ට අඩු කරයි.

නම්‍යශීලිත්වය එදිරිව කරදර, වාසි සහ අවාසි:

ආරක්ෂිත ක්ෂේත්‍ර සහිත වැනිලා පන්තියේ ඔබේ කේතය මඟින් ක්ෂණිකව ඇති වස්තූන් ආරක්ෂිත වන අතර එය ඔබේ එකම වගකීම වේ.

අනෙක් අතට, ඔබේ කේතය භාවිතා කරන්නන් විසින් ක්ෂණිකව ආරක්‍ෂිත ක්ෂේත්‍ර සමඟ ඔබේ පන්තිය විස්තාරණය කරන වස්තූන් ඔවුන්ගේ වගකීම මිස ඔබේ නොවේ.

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

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

එබැවින්, පුද්ගලික, ආරක්ෂිත සහ පොදු අතර හොඳ සමබරතාවයක් ඇත්ත වශයෙන්ම වැදගත් වේ.

දැන්, පුද්ගලික සහ ආරක්‍ෂිත අතර තීරණය කිරීම සැබෑ ගැටළුවයි.

ආරක්ෂිතව භාවිතා කළ යුත්තේ කවදාද?

ක්ෂේත්‍රයක් ඉතා නම්‍යශීලී විය හැකි බව ඔබ තේරුම් ගන්නා සෑම අවස්ථාවකම එය ආරක්ෂිත ලෙස කේතනය කළ යුතුය. එම නම්යතාවය නම්: ශුන්‍ය බවට පත්වීමේ සිට (ශුන්‍යය සැමවිටම පරික්‍ෂා කර වලංගු රාජ්‍යයක් ලෙස ව්‍යතිරේකයන් විසි නොකරන ලෙස පිළිගැනීම), ඔබේ පන්තියේ හිටපු අය භාවිතා කිරීමට පෙර බාධක තිබීම. > = 0, <100 යනාදිය, සහ අධික ලෙස / යටින් ගලා යන අගයන් සඳහා ස්වයංක්‍රීයව සවි කර ඇති අතර, බොහෝ විට අනතුරු ඇඟවීමේ පණිවිඩයක් විසි කරයි.

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

imo dtdammers නිවැරදි නොවන අතර ඇත්ත වශයෙන්ම නොමඟ යවන සුළුය.

ක්‍රියාත්මක කිරීමේ තොරතුරු සැඟවීමට පුද්ගලික විචල්‍යයන් පවතී. ඔබේ පන්තිය ලකුණු ගබඩා Aකිරීම සඳහා භාවිතා කරයි array. හෙට ඔබ භාවිතා කිරීමට ඔබට අවශ්ය විය හැක treeහෝ priority queueඒ වෙනුවට. ඔබගේ පංතියේ අවශ්‍යතාවය ඇති සියලුම පරිශීලකයින්ට ලකුණු සහ නම් ඇතුළත් addScore()කිරීමට ක්‍රමයක් වන අතර ඉහළම 10 දෙනා කවුරුන්දැයි සොයා ගැනීමට මාර්ගයකි getTop(n).

ඔවුන්ට යටින් පවතින දත්ත ව්‍යුහයට ප්‍රවේශ වීමට අවශ්‍ය නැත. නියමයිද? හොඳයි, සමහර අවවාද තිබේ.

කෙසේ වෙතත් ඔබ බොහෝ රාජ්‍යයන් ගබඩා නොකළ යුතුය, බොහෝ ඒවා අවශ්‍ය නොවේ. නිශ්චිත පන්තියකට “වෙන් කොට” තිබියදීත් ගබඩා කිරීමේ තත්වය ඔබේ කේතය සංකීර්ණ කරයි. ඒ ගැන සිතන්න, එම පුද්ගලික විචල්‍යය බොහෝ විට වෙනස් වී ඇත්තේ වෙනත් වස්තුවක් එම පන්තියේ ක්‍රමයක් ලෙස හැඳින්වෙන බැවිනි. එම ක්‍රමය හැඳින්වූයේ කවදාද සහ කොතැනද යන්න සහ න්‍යායාත්මකව ඕනෑම තැනක පොදු ක්‍රමය හැඳින්විය හැකි බව ඔබ තවමත් සොයාගත යුතුය.

ඔබට කළ හැකි හොඳම දෙය නම් ඔබේ වැඩසටහනේ අඩංගු රාජ්‍ය ප්‍රමාණය සීමා කිරීම සහ හැකි සෑම විටම පිරිසිදු කාර්යයන් භාවිතා කිරීමයි.

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

ඔබ මුලින්ම වස්තු නැඹුරු වැඩසටහන්කරණය පිළිබඳ සංකල්පය තේරුම් ගත යුතුය. එය වියුක්ත කිරීම, සංවෘත කිරීම යනාදිය ඇත.

සාරාංශය - ක්‍රියාත්මක කිරීම පිළිබඳ යටින් විස්තර දැන ගැනීමකින් තොරව ඔබට තර්කනය පිළිබඳ අදහස ලැබෙනු ඇත.

Encapsulation - වස්තුවෙහි යටි ඉරි ක්‍රියාත්මක කිරීම ඔබට නොපෙනේ. වස්තුවේ පොදු අතුරුමුහුණත දැකිය හැක්කේ ඔබට පමණි.

දැන් C #, Java, C ++ වැනි වස්තු නැඹුරු වැඩසටහනක් සමඟ නිශ්චිත ක්‍රියාත්මක කිරීමේදී ඔබට මෙම සංකල්ප ක්‍රියාත්මක කළ හැකිය.

පෞද්ගලික - බාහිර ලෝකයෙන් සැඟවිය යුතු ක්‍රියාත්මක කිරීම. එවිට ඔබට එය වෙනස් කළ හැකි අතර ඔබේ පන්තියේ පරිශීලකයාට එය බලපාන්නේ නැත.

public - ඔබේ වස්තුව භාවිතා කළ හැකි අතුරු මුහුණත මෙයයි.