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

පළමු අධ්‍යයන වාරයේ දී ජාවා සහ යූඑම්එල් හරහා සංයුක්තකරණය, දත්ත සැඟවීම, මොඩියුලරිටි, උරුමය වැනි OOP සංකල්ප අපට හඳුන්වා දෙන ලදී. (ජාවා මගේ පළමු ක්‍රමලේඛන භාෂාවයි)

මම එය තේරුම් ගන්නා ආකාරය, OOP යනු මෘදුකාංග සංකීර්ණත්වය කළමනාකරණය කිරීමේ ක්‍රමයකි. නමුත් එහි මූලධර්ම අළුත් හෝ අද්විතීය නොවේ, ඒවා අර්ථයෙන් සියලු ඉංජිනේරු ක්ෂේත්‍රයන්ට විශ්වීය ය.

නිදසුනක් ලෙස මෝටර් රථයක් යනු ඉතා සංකීර්ණ ව්‍යුහයක් වන අතර එය මනාව නිර්වචනය කරන ලද හැසිරීම් සහ අතුරුමුහුණත් සහිත මොඩියුලර් සහ සංවෘත සං components ටකවල ධූරාවලියක් මගින් සංකීර්ණත්වය කළමනාකරණය කරයි.

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

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

ඇත්තෙන්ම අඩු න්‍යායික පිළිතුරකින් උත්සාහ කිරීමට මට ඉඩ දෙන්න :)

ඔබ සැබවින්ම අසන්නේ : OO කේතය සැලසුම් කිරීම හා ලිවීම සඳහා කාර්ය පටිපාටික භාෂාවන් භාවිතා කළ හැකි විට Ob ජුවම භාෂාවට Object Orientation (OO) සඳහා සහය ඇතුළත් කරන්නේ ඇයි?

පිළිතුර නම්: ප්‍රභව කේතයේ OO ප්‍රකාශ වන ආකාරය පිළිබඳ ප්‍රමිතියක් තිබීම නිසා එකම සාරාංශයක් සඳහා විවිධ ක්‍රියාත්මක කිරීම් 22 ක් සමඟ ඔබ අවසන් නොවේ.

උදාහරණයක් ලෙස, පරිශීලක අතුරුමුහුණත් පද්ධතියක භාවිතා කළ හැකි a MagicButtonසහ a නිර්මාණය කරමි යැයි කියමු MagicSlider. මැජික් බොත්තම සමඟ භාවිතා කළ හැකි ක්‍රම, මැජික් ස්ලයිඩරය සමඟ පමණක් භාවිතා කළ හැකි ක්‍රම සහ දෙකම භාවිතා කළ හැකි ක්‍රම කාණ්ඩගත කිරීමට මට ක්‍රමයක් අවශ්‍යය. මෙම වස්තූන් මැජික් ගුයි වස්තු දෙකම නිසා සමහර ක්‍රම බෙදා ගනී.

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

ඔව්, ප්‍රමාද යැවීම - OO භාෂාවලින් අතථ්‍ය ක්‍රම - ක්‍රියා පටිපාටික භාෂාවලින් ක්‍රියාත්මක කළ හැකි නමුත් එය ක්‍රියාත්මක කිරීමට විවිධ ක්‍රම තිබේ. කේතය ලිව්වේ කවුරුන්ද යන්න මත පදනම්ව ඔබ එකම වැඩසටහන තුළ OO හි විවිධ ක්‍රියාත්මක කිරීම් සමඟ අවසන් වනු ඇත.

දුර්වල නඩත්තු සංවර්ධකයා ගැන සිතන්න. මුල් කේතය ලිව්වේ කවුරුන්ද යන්න මත පදනම්ව මෙම පුද්ගලයා විවිධ වස්තු සාරාංශ සහ අථත්‍ය ක්‍රම ඇමතීමට විවිධ ක්‍රම කළමනාකරණය කළ යුතුය.

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

පළමු අධ්‍යයන වාරයේ දී ජාවා සහ යූඑම්එල් හරහා සංයුක්තකරණය, දත්ත සැඟවීම, මොඩියුලරිටි, උරුමය වැනි OOP සංකල්ප අපට හඳුන්වා දෙන ලදී. (ජාවා මගේ පළමු ක්‍රමලේඛන භාෂාවයි)

ඒ කිසිවක් OOP සංකල්ප නොවේ. ඒවා සියල්ලම OO ට පිටතින් පවතින අතර OO වලින් ස්වාධීන වන අතර බොහෝ ඒවා OO ට පෙර සොයා ගන්නා ලදී.

ඒ නිසා, ඔබ හිතන්නේ නම් ඒ OO ඇත්තේ ඒ නිසයි, එසේ නම් ඔබේ නිගමනය හරි: ඔබ, කාර්ය පටිපාටික භාෂා එම සියල්ල කළ හැකියි ඔවුන් OO සමග ගෑවිලාවත් නැත නිසා .

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

අතර දත්ත වියුක්තීකරණය OO වැදගත් වේ, එය වැඩිපුර කෑම ප්රතිඵලයක් එය නිර්වචනය ලක්ෂණය වඩා OO (පණිවිඩ) ප්රාථමික විශේෂාංගය. එසේම, විවිධ වර්ගයේ දත්ත සාරාංශ ඇති බව මතක තබා ගැනීම ඉතා වැදගත් වේ . අද භාවිතයේ පවතින වඩාත් සුලභ දත්ත සාරාංශ දෙක (අපි අනෙක් සංයෝජන දෙකට වඩා තවමත් භාවිතා කරන “සාරාංශයක් නැත” යන්න නොසලකා හැරියහොත්) වියුක්ත දත්ත වර්ග සහ වස්තු වේ. එබැවින්, "තොරතුරු සැඟවීම", "එන්කැප්සුලේෂන්" සහ "දත්ත සාරාංශය" යනුවෙන් පැවසීමෙන් ඔබ OO ගැන කිසිවක් පවසා නැත, මන්ද OO යනු දත්ත සාරාංශයේ එක් ආකාරයක් පමණක් වන අතර මේ දෙක ඇත්ත වශයෙන්ම මූලික වශයෙන් වෙනස් ය:

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

මෙයින් අදහස් කරන්නේ, ජාවාහි, පන්ති වස්තු-නැඹුරු නොවන බවයි. එකම පන්තියේ අවස්ථා දෙකකට එකිනෙකාගේ නිරූපණයට සහ පුද්ගලික ක්‍රියාත්මක කිරීමට ප්‍රවේශ විය හැකිය . එමනිසා, පංතිවල අවස්ථා වස්තු නොවේ, ඒවා ඇත්ත වශයෙන්ම ADT අවස්ථා වේ. ජාවා interfaceහි, කෙසේ වෙතත්, නැහැ වස්තුව-අභිමුඛ දත්ත වියුක්තීකරණය ලබා දෙයි. එබැවින්, වෙනත් වචන වලින් කිවහොත්: ජාවාහි ඇති වස්තූන් වන්නේ අතුරුමුහුණත් සඳහා පමණි.

මූලික වශයෙන්, වර්ග සඳහා, ඔබට භාවිතා කළ හැක්කේ අතුරු මුහුණත් පමණි. මෙයින් අදහස් කරන්නේ පරාමිති ක්‍රම සහ ඉදිකිරීම්කරුවන්, ආපසු පැමිණීමේ ක්‍රම, නිදර්ශන ක්ෂේත්‍ර, ස්ථිතික ක්ෂේත්‍ර සහ දේශීය ක්ෂේත්‍ර, instanceofක්‍රියාකරුට හෝ වාත්තු ක්‍රියාකරුට තර්කය සහ සාමාන්‍ය වර්ගයේ ඉදිකිරීම්කරුවෙකු සඳහා වන තර්ක සෑම විටම අතුරුමුහුණත් විය යුතුය. පංතියක් භාවිතා කළ හැක්කේ newක්‍රියාකරුට පසුව පමණි .

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

ඔබ විස්තර කරන්නේ OO ය.

OO ගැන සිතීමට එය හොඳ ක්‍රමයකි. ඇත්ත වශයෙන්ම, ඕඕ හි මුල් නව නිපැයුම් කරුවන්ගේ මතකයේ තිබුනේ එයයි. (ඇලන් කේ තවත් එක් පියවරක් ඉදිරියට ගියේය: ජාලය හරහා එකිනෙකාට පණිවිඩ යවන කුඩා පරිගණක විශාල ප්‍රමාණයක් ඔහු දුටුවේය.) ඔබ “වැඩසටහන” ලෙස හඳුන්වන දේ සාමාන්‍යයෙන් “වස්තුවක්” ලෙස හඳුන්වන අතර “ඇමතුම” වෙනුවට අපි සාමාන්‍යයෙන් කියන්නේ “පණිවිඩයක් යවන්න ".

වස්තු දිශානතිය යනු පණිවුඩකරණය (aka ගතික යැවීම ) ය. "Object Oriented" යන පදය ස්මාල්ටෝක් හි ප්‍රධාන නිර්මාණකරු ආචාර්ය ඇලන් කේ විසින් නිර්මාණය කරන ලද අතර ඔහු එය අර්ථ දක්වන්නේ මෙසේ ය :

මට ඕඕපී යන්නෙන් අදහස් කරන්නේ පණිවුඩ යැවීම, දේශීයව රඳවා තබා ගැනීම සහ රාජ්‍ය ක්‍රියාදාමය ආරක්ෂා කිරීම සහ සැඟවීම සහ සියල්ල ප්‍රමාද වී බැඳීම පමණි.

අපි එය බිඳ දමමු:

• පණිවිඩ යැවීම ("ස්මාල්ටෝක්" ගැන ඔබ නොදන්නේ නම් "අතථ්‍ය ක්‍රම යැවීම")
• රාජ්ය ක්රියාවලිය විය යුතුය
  • දේශීයව රඳවා තබා ඇත
  • ආරක්ෂිතයි
  • සැඟවී ඇත
• සෑම දෙයක්ම අතිශයින් ප්‍රමාද කිරීම

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

ඔහු පසුව පැහැදිලි කළේ “ විශාල අදහස“ පණිවිඩ යැවීම ”වන අතර “ පණිවුඩ -නැඹුරු ”වෙනුවට“ වස්තු-නැඹුරු ”ලෙස හැඳින්වීම ගැන කනගාටු වන බැවිනි. ) සහ සැබවින්ම වැදගත් දෙයින් ract ත්වීම (පණිවිඩ යැවීම):

ස්මාල්ටෝක් යනු එහි වාක්‍ය ඛණ්ඩය හෝ පන්ති පුස්තකාලය පමණක් නොවන බවත්, එය පන්ති ගැනවත් නොවන බවත් සැමට මතක් කර දීමට මම අන්තිම OOPSLA හිදී යම් වේදනාවක් ගත් බව මෘදු මතක් කිරීමක් පමණි. බොහෝ කලකට පෙර මෙම මාතෘකාව සඳහා "වස්තූන්" යන යෙදුම යෙදීම ගැන මට කණගාටුයි, මන්ද බොහෝ දෙනෙකුට අඩු අදහස කෙරෙහි අවධානය යොමු කිරීමට එය හේතු වේ.

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

(ඇත්ත වශයෙන්ම, අද බොහෝ දෙනා වස්තූන් කෙරෙහි නොව පන්ති කෙරෙහි අවධානය යොමු කරති, එය ඊටත් වඩා වැරදිය.)

OO සඳහා පණිවුඩකරණය මූලික වේ, එය රූපකයක් මෙන්ම යාන්ත්‍රණයක් ද වේ.

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

“පණිවිඩ යැවීම” සඳහා වඩාත් “නවීන” යෙදුමක් වන්නේ “ගතික ක්‍රම යැවීම” හෝ “අතථ්‍ය ක්‍රම ඇමතුම” යන්නයි, නමුත් එය රූපකය නැති වී යාන්ත්‍රණය කෙරෙහි අවධානය යොමු කරයි.

එබැවින්, ඇලන් කේගේ අර්ථ දැක්වීම දෙස බැලීමට ක්‍රම දෙකක් තිබේ: ඔබ එය තනිවම සිටගෙන සිටින්නේ නම්, පණිවුඩ යැවීම මූලික වශයෙන් ප්‍රමාද වූ ක්‍රියා පටිපාටිය ඇමතුමක් බවත් ප්‍රමාද බන්ධනය සංකේතවත් කිරීමක් අදහස් කරන බවත් ඔබට නිරීක්ෂණය කළ හැකිය, එබැවින් අපට # 1 සහ # 2 සැබවින්ම අතිරික්ත වන අතර OO යනු ප්‍රමාද බන්ධනයකි.

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

විලියම් ආර්. කුක් විසින් නැවත සලකා බැලූ දත්ත අවබෝධ කර ගැනීමේදී ද, “වස්තුව” සහ “වස්තු දිශානතිය” පිළිබඳ සරල, නවීන නිර්වචන සඳහා වූ ඔහුගේ යෝජනාව ද ඒ හා සමාන කරුණු ඉදිරිපත් කර ඇත .

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

ස්මාල්ටෝක් -72 හි කිසිදු වස්තුවක්වත් නොතිබුණි! විග්‍රහ කර, නැවත ලිවීමට හා නැවත හරවා යැවූ පණිවිඩ ප්‍රවාහයන් පමණක් තිබුණි . මුලින්ම පැමිණි ක්‍රම (පණිවුඩ ප්‍රවාහ විග්‍රහ කිරීමට සහ නැවත හරවා යැවීමට සම්මත ක්‍රම), පසුව පැමිණියේ වස්තූන් (සමහර පෞද්ගලික රාජ්‍යයන් බෙදාගන්නා ක්‍රම සමූහ කිරීම). උරුමය බොහෝ කලකට පසුව පැමිණි අතර පන්ති හඳුන්වා දෙනු ලැබුවේ උරුමයට සහාය දැක්වීමේ මාර්ගයක් වශයෙනි. කේගේ පර්යේෂණ කණ්ඩායම දැනටමත් මූලාකෘති ගැන දැන සිටියේ නම්, ඔවුන් කිසි විටෙකත් පන්ති හඳුන්වා නොදෙනු ඇත.

වර්ග සහ ක්‍රමලේඛන භාෂාවල බෙන්ජමින් පියර්ස් තර්ක කරන්නේ වස්තු-දිශානතියේ නිර්වචනය වන්නේ විවෘත පුනරාවර්තනය බවයි.

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

ඔබට පෙනෙන පරිදි, "ඕඕ" යන යෙදුම නිර්මාණය කළ පුද්ගලයාට වස්තූන් පිළිබඳ තරමක් පාරභෞතික දෘෂ්ටියක් ඇත, කුක් තරමක් ප්‍රායෝගික දෘෂ්ටියක් ඇති අතර පියර්ස් ඉතා දැඩි ගණිතමය දෘෂ්ටියක් ඇත. නමුත් වැදගත් දෙය නම්: දාර්ශනිකයා, ප්‍රායෝගිකවාදියා සහ න්‍යායාචාර්යවරයා සියල්ලෝම එකඟ වෙති! පණිවිඩ යැවීම OO හි එක් කුළුණකි. කාලය.

මෙහි උරුමය ගැන සඳහනක් නොමැති බව සලකන්න! OO සඳහා උරුමය අත්‍යවශ්‍ය නොවේ. පොදුවේ ගත් කල, බොහෝ OO භාෂාවන්ට නැවත ක්‍රියාත්මක කිරීමේ ක්‍රමයක් ඇති නමුත් එය අනිවාර්යයෙන්ම උරුමයක් විය යුතු නොවේ. උදාහරණයක් ලෙස එය යම් ආකාරයක නියෝජිත කණ්ඩායමක් විය හැකිය. ඇත්ත වශයෙන්ම, ඕර්ලන්ඩෝ ගිවිසුම මගින් උරුමය සඳහා විකල්පයක් ලෙස නියෝජිත පිරිස සාකච්ඡා කරන අතර වස්තු-නැඹුරුවන භාෂාවල සැලසුම් අවකාශය තුළ විවිධ නියෝජිත ස්ථාන සහ උරුමය විවිධ සැලසුම් ලක්ෂ්‍යයන්ට මඟ පෙන්වන්නේ කෙසේද. (ඇත්ත වශයෙන්ම ජාවා වැනි උරුමයට අනුබල දෙන භාෂාවල පවා මිනිසුන්ට එය වළක්වා ගැනීමට උගන්වනු ලබන අතර එය OO සඳහා අවශ්‍ය නොවන බව නැවතත් පෙන්නුම් කරයි.)

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

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

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

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

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

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

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

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

නවීන භාෂාවක සියළුම අංගයන් නැවත සොයා ගැනීමට මට පෞද්ගලිකව කිසිදු උනන්දුවක් නැත. දැනටමත් විසඳා ඇති ගැටලුවලට විසඳුම් ඇතුළත් භාෂාවකින් මට ප්‍රයෝජන ගත හැකි නම්, එසේ නොවන්නේ මන්ද?

එබැවින් මම ඔබේ ප්‍රශ්නය හරවා ඔබෙන් අසමි, භාෂාවන් සංවෘත කිරීම සහ බහුමාපකය වැනි පහසු අංග සපයන්නේ නම්, අප ඒවා භාවිතා නොකළ යුත්තේ ඇයි?

ඔබ විස්තර කරන්නේ ඕඕපී නොවේ, එය වියුක්ත කිරීමකි. OOP නොවන නවීන නිර්මාණ වල පවා වියුක්තකරණය පවතී. OOP යනු ඉතා නිශ්චිත ආකාරයේ සාරාංශයකි.

පළමුවෙන්ම, OOP පිළිබඳ තනි අර්ථ දැක්වීමක් නොමැති බව සඳහන් කිරීම වටී, එබැවින් මම OOP ලෙස සංලක්ෂිත කරන දෙයට එකඟ නොවන පුද්ගලයින් සිටිය හැකිය.

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

කෙසේ වෙතත්, ඔබ කියූ දෙයට වඩා OOP වඩාත් සූක්ෂම ආකාර කිහිපයක් මෙන්න:

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

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

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

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

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

මෘදුකාංග සංකීර්ණත්වය කළමනාකරණය කිරීමට අපට ඇත්ත වශයෙන්ම OO භාෂා අවශ්‍යද?

මෙය "අවශ්‍යතාවය" යන වචනයේ තේරුම මත රඳා පවතී.

“අවශ්‍ය” යන්නෙන් අදහස් කරන්නේ නම්, අපට එය අවශ්‍ය නොවේ.

“අවශ්‍යතාවය” යන්නෙන් “ශක්තිමත් ප්‍රතිලාභ ලබා දෙයි” නම්, “ඔව්” යැයි මම කියමි.

ලොකු පින්තූරයක්

OO භාෂා ක්‍රියාකාරිත්වය දත්ත සමඟ බැඳේ.

දත්ත අගයන් පසුකර යන මෙම බන්ධන හා ලිවීමේ කාර්යයන් ඔබට වළක්වා ගත හැකිය.

නමුත් එවිට ඔබ බොහෝ විට එකට එකතු වන දත්ත රාශි සමඟ සුළං හමන අතර, ඔබ දත්ත, ශබ්ද හෝ ශබ්ද කෝෂ වටා ගමන් කිරීමට පටන් ගනී.

ඇත්ත වශයෙන්ම, ඒ සියල්ලම ක්‍රම ඇමතුම් වේ: බැඳී ඇති දත්ත කට්ටලවල අර්ධ ශ්‍රිත.

විශේෂාංගය අනුව විශේෂාංගය

OOP හි විශේෂාංග:

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

කෙසේ වෙතත්, ඒ කිසිවක් පළමු පන්තියේ සහය ඇති වස්තු නැඹුරු භාෂාවක් තරම් පහසුවෙන් සිදු නොවේ.

යොමුව

OOP ගැන බොහෝ විවේචකයන් ඇත .

කෙසේ වෙතත්, අධ්‍යයනවලින් පෙනී යන්නේ OOP හරහා කේත නැවත භාවිතා කිරීමෙන් අපට වැඩි ක්‍රමලේඛක produc ලදායිතාවයක් ලැබෙන බවයි. මෙය මතභේදාත්මක සොයා ගැනීමක් වන අතර සමහර පර්යේෂකයන් පවසන්නේ යම් යම් බාධාවන් සැලකිල්ලට ගෙන මෙම tivity ලදායිතා වාසි ප්‍රතිනිෂ්පාදනය කළ නොහැකි බවයි. (මූලාශ්රය)

නිගමනය

අපට OOP "අවශ්‍ය" නොවේ. නමුත් සමහර අවස්ථාවලදී පරිශීලකයාට OOP අවශ්‍ය වේ.

පරිණත ක්‍රමලේඛකයන්ට වස්තු-නැඹුරු ශෛලිය තුළ තරමක් tive ලදායී විය හැකි බව මගේ අවබෝධයයි. පහසුවෙන් තේරුම් ගත හැකි සරල අතුරුමුහුණත් සහිත මූලික වස්තු පැකේජ ඇති විට, නව ක්‍රමලේඛකයන්ට පවා ඉක්මනින් produc ලදායී විය හැකිය.

මම කෙටියෙන් කියන්න උත්සාහ කරමි.

OO හි මූලික මූලධර්මය වන්නේ තනි ආයතනික ඒකකයක (වස්තුවක්) දත්ත හා හැසිරීම සංයෝජනය කිරීමයි.

සංකීර්ණත්වය පාලනය කිරීමට මෙය අපට ඉඩ සලසන අතර එය මතුවූ විට එය ඉතා නව්‍ය සංකල්පයක් විය. එය එක් අතකින් ඇති ගොනු (පිරිසිදු දත්ත), අනෙක් අතට එම ලිපිගොනු කියවා සකස් කරන වැඩසටහන් (පිරිසිදු තර්කනය) සහ ප්‍රතිදානය (පිරිසිදු දත්ත නැවත) සමඟ සසඳන්න.

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

ඉතින්, ඔව්, ඕඕ විශාල ගනුදෙනුවක්. නැත, එය විසිතුරු නමක් සහිත පැරණි දේවල් පොකුරක් පමණක් නොවේ.

ඒ සියල්ල පසෙකට දමා, මූලද්‍රව්‍ය දෙස බලා "අනේ, මම මීට පෙර දැක නැති කිසිවක් මෙහි නැත" යැයි පැවසීම නවෝත්පාදනයන් දරණ එකලස් කිරීම හඳුනා නොගනී. ප්රති result ලය එහි කොටස්වල එකතුවට වඩා වැඩිය.

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

එන්කැප්සියුලේෂන් සහ මොඩියුලරිටි යනු නිර්මාණයේ වඩාත් මූලික මූලධර්ම වන අතර ඒවා සියලු ක්‍රමලේඛන පරාමිතීන්හි යෙදිය යුතුය. OO හි යෝජකයින් මෙම ගුණාංග සාක්ෂාත් කරගත හැක්කේ OO සමඟ පමණක් යැයි කියා නැත - මෙය සාක්ෂාත් කර ගැනීම සඳහා OO විශේෂයෙන් සුදුසු වේ. ඇත්ත වශයෙන්ම ක්‍රියාකාරී ක්‍රමලේඛනය වැනි වෙනත් උපමා වල යෝජනා කරන්නන් ඔවුන්ගේ පරමාදර්ශයට සමාන යැයි කියති. ප්‍රායෝගිකව බොහෝ සාර්ථක භාෂාවන් බහු-පරමාදර්ශී වන අතර OO, ක්‍රියාකාරී යනාදිය “එක් සත්‍ය මාර්ගයකට” වඩා මෙවලම් ලෙස දැකිය යුතුය.

සංකීර්ණත්වය කළමනාකරණය කිරීම සඳහා භාවිතා කරන සියලුම මූලධර්ම කාර්ය පටිපාටික ක්‍රමලේඛන භාෂාවන් මගින් අවබෝධ කර ගත හැකි යැයි මම සිතමි.

ඇත්ත, මන්ද අවසානයේ ඔබට ඕනෑම ක්‍රමලේඛන භාෂාවකින් ඕනෑම දෙයක් කළ හැකිය. සෑම භාෂාවකටම විවිධ ශක්තීන් හා දුර්වලතා ඇති බැවින් එය සමහර භාෂාවලට වඩා පහසු විය හැකිය.

අනෙක් පිළිතුරු සඳහන් කර නැති දෙයක්: තත්වය.

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

මම හිතන්නේ අපි කතා කරන්නේ රාජ්‍යයට සම්බන්ධ සංකීර්ණතාව ගැනයි.

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

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

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

අනෙක් විශාල ක්‍රමලේඛන පරාමිතීන් දෙක (OO සහ ක්‍රියාකාරී) සිත්ගන්නාසුළු නමුත් රාජ්‍ය සම්බන්ධිත සංකීර්ණතාවයේ ගැටලුවට බොහෝ දුරට විරුද්ධ විසඳුම් ඉදිරිපත් කරයි. ක්‍රියාකාරී ක්‍රමලේඛනයේදී යමෙක් එය මුළුමනින්ම මග හැරීමට උත්සාහ කරයි: කාර්යයන් සාමාන්‍යයෙන් පිරිසිදු ය, දත්ත ව්‍යුහයන්හි මෙහෙයුම් මුල් පිටපත යාවත්කාලීන කරනවාට වඩා පිටපත් යවයි.

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

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

මෘදුකාංග සංකීර්ණත්වය කළමනාකරණය කිරීමට අපට ඇත්ත වශයෙන්ම OO භාෂා අවශ්‍යද?

නැත, නමුත් ඔවුන්ට බොහෝ අවස්ථාවන්හිදී උදව් කළ හැකිය.

මම දශක ගණනාවක් තිස්සේ මූලික වශයෙන් තනි OO භාෂාවක් භාවිතා කර ඇත, නමුත් මගේ බොහෝ කේතයන් ඇත්ත වශයෙන්ම OO- ශෛලියේ පූර්ව ක්‍රියා පටිපාටියකි. කෙසේ වෙතත්, GUI සම්බන්ධ ඕනෑම දෙයක් සඳහා, මම භාෂාවේ අතිවිශාල OO පුස්තකාලය භාවිතා කරන්නේ ගොඩනංවන ලද ක්‍රම සහ වස්තූන්ය, මන්ද එය මගේ කේතය බෙහෙවින් සරල කරයි.

උදාහරණයක් ලෙස, පෝරමයක්, බොත්තමක් සහ සංස්කරණ ක්ෂේත්‍රයක් ප්‍රදර්ශනය කිරීම සඳහා මුල් පහත් මට්ටමේ වින්ඩෝස් ඒපීඅයි භාවිතා කරන වින්ඩෝස් යෙදුමක් සඳහා කේත විශාල ප්‍රමාණයක් අවශ්‍ය වන අතර ඒ වෙනුවට විෂුවල් බේසික් හෝ සී # හෝ ඩෙල්ෆි සමඟ එන වස්තූන්ගේ පුස්තකාල භාවිතා කිරීම සමාන වේ. වැඩසටහන ඉතා කුඩා හා සුළු. ඉතින්, මගේ OO කේතය සාමාන්‍යයෙන් සාපේක්ෂව කුඩා වන අතර GUI සඳහා වන අතර, එම වස්තූන් ඉල්ලා සිටින මගේ කේතය සාමාන්‍යයෙන් වඩා විශාල වන අතර සාමාන්‍යයෙන් OO වීම ගැන සැලකිලිමත් නොවේ (මම විසඳීමට උත්සාහ කරන ගැටලුව අනුව එය වෙනස් විය හැකි වුවද).

OO වැඩසටහන් ඕනෑවට වඩා සංකීර්ණ වූ, වස්තූන් ක්‍රියාත්මක කළ ආකාරය පිළිබඳ සංකීර්ණ එසෝටරික් රීති මත රඳා පවතින අතර OO සංකල්ප නොමැතිව ලියා ඇත්නම් වඩා සරල විය හැකි බව මම දැක ඇත්තෙමි. මම ද ප්‍රතිවිරුද්ධ දෙය දැක ඇත්තෙමි: සංකීර්ණ පද්ධති වස්තූන් භාවිතයෙන් නැවත සකස් කර සරල කළ යුතු යැයි හ crying නඟයි.

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

මුළුමනින්ම C හි ලියා ඇති ඉතා විශාල ව්‍යාපෘතියකට සම්බන්ධ අයෙකු ලෙස, මට නියත වශයෙන්ම කිව හැකිය පිළිතුර “නැත” යන්නයි.

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

ව්‍යුහයන් සංයුතියට සහාය වේ. උදාහරණයක් ලෙස, ඔබට නිශ්ශබ්ද අගුලක් සහ සාමාන්‍ය හැෂ් වගුවකින් සමන්විත අගුලු දැමූ හැෂ් වගුවක් තිබිය හැකිය. මෙය වස්තු නැඹුරු වැඩසටහන්කරණය නොවේ; උප කාණ්ඩයක් සිදු නොකෙරේ. සංයුතිය යනු වස්තු දිශානත වැඩසටහන්කරණයේ අදහසට වඩා බොහෝ පැරණි මෙවලමකි.

සම්පාදන මට්ටමේ මොඩියුලරිටි ප්‍රමාණවත් නොවන සහ ඔබට ධාවන කාල මොඩියුලරිටි අවශ්‍ය වන අවස්ථා වලින් 1% ක් සඳහා, ශ්‍රිත දර්ශක ලෙස හැඳින්වෙන දෙයක් තිබේ. මනාව නිර්වචනය කරන ලද අතුරු මුහුණතක් තනි තනිව ක්‍රියාත්මක කිරීමට ඒවා ඉඩ දෙයි. මෙය වස්තු-නැඹුරු භාෂාවකින් වස්තු දිශානත වැඩසටහන් නොවන බව සලකන්න. මෙය අතුරු මුහුණතක් නිර්වචනය කර එය ක්‍රියාත්මක කිරීමයි. උදාහරණයක් ලෙස, උප පංතිය මෙහි භාවිතා නොවේ.

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

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

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

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

වස්තු-නැඹුරු ක්‍රම ඇතුළුව ක්‍රමලේඛන පරාමිතීන් හඳුන්වාදීමට හේතුව වඩාත් නවීන හා බලවත් වැඩසටහන් සෑදීම පහසු කිරීමයි. බයිට් සඟරාවේ 1981 අගෝස්තු කලාපයේ, ස්මාල්ටෝක් හි ප්‍රධාන නිර්මාතෘවරයෙකු වන ඩැනියෙල් ඉන්ගල්ස් , “වස්තු නැඹුරුව” යන්න පහත සඳහන් හැකියාවන්ගෙන් අර්ථ දැක්වීය:

• ස්වයංක්‍රීය ගබඩා කළමනාකරණය
• පණිවිඩ හුවමාරු කර ගැනීමේ හැකියාව
• භාෂාවේ සියලුම මෙහෙයුම් සඳහා අදාළ වන ඒකාකාර රූපකයක්
• කිසිදු සංරචකයක් වෙනත් සංරචකයක අභ්‍යන්තරය මත රඳා නොපවතී (මොඩියුලරිටි)
• වැඩසටහන අර්ථ දක්වන්නේ වස්තූන්ගේ හැසිරීම මිස ඒවායේ නිරූපණය නොවේ (බහුමාපකය)
• සෑම සංරචකයක්ම එක් ස්ථානයක පමණක් දර්ශනය විය යුතුය (සාධකකරණය)
• දෘඩාංග ස්වාධීන වන අථත්‍ය යන්ත්‍රයක් භාවිතා කිරීම
• පරිශීලකයාට ප්‍රවේශ විය හැකි සෑම අංගයක්ම නිරීක්ෂණය සහ පාලනය සඳහා තිබිය යුතුය (ප්‍රතික්‍රියාශීලී මූලධර්මය)
• සමස්ත පාලකයක් නොතිබිය යුතුය (මෙහෙයුම් පද්ධතියක් නොමැත)

සෙරොක්ස් පාර්ක් රිසර්ච් විසින් වැඩි දියුණු කරන ලද ස්මාල්ටෝක් -80 සඳහා රියදුරු සැලසුම් සලකා බැලීම් ලෙස ඉන්ගල්ස් හඳුනාගත් මූලධර්ම මේවාය. ඉහත සඳහන් කළ සඟරා ලිපියෙන් ඔබට මෙම එක් එක් මූලධර්ම පිළිබඳ සවිස්තරාත්මක විස්තරයක් කියවිය හැකිය.

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

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

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

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

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

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

අරමුණ - මෘදුකාංග සංකීර්ණත්වය කළමනාකරණය කරන්න . අරමුණ "OO භාෂාව භාවිතා කිරීම" නොවේ.

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

තථ්‍ය ලෝක ආයතන අනුව කේතීකරණය යනු අප සැබෑ ලෝක ආයතන ගැන කේත කරන විට කේත කිරීමට ඇති පැහැදිලි හා නිවැරදි ක්‍රමයයි .

සම්බන්ධිත ලැයිස්තුවේ කෙළවරට නෝඩයක් එක් කිරීම සමඟ පරිගණකයකට වැඩ කළ හැකි අතර දුම්රියේ කෙළවරට අමතර පුහුණුකරුවෙකු එක් කිරීම සමඟ වැඩ කළ හැකිය. නමුත් මිනිසුන් සඳහා දුම්රිය හා පුහුණුකරු සමඟ සම්බන්ධිත ලැයිස්තුවක් හා නෝඩ් සමඟ වැඩ කිරීම පහසුය. අප යම් මට්ටමකට ගැඹුරට ගියත් දුම්රිය සම්බන්ධ වී ඇත්තේ සම්බන්ධිත ලැයිස්තුවක් මගිනි.

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

එබැවින් ඔබට සංකේතාත්මක හා හොඳින් සංයුක්ත කර ඇති කේත ලිවිය හැකිය, මන්ද මේ දෙක එකිනෙකට වෙනස් සංකල්ප වේ.

යථාර්ථය සමඟ සමීපව සිටීම නිසා සංකීර්ණත්වය කළමනාකරණය කිරීමට එන්කැප්සුලේෂන් උපකාරී වේ.

එමනිසා, වස්තූන් තුළ වැඩසටහන් කරන්න, මන්ද එය ඔබට කේත කිරීම පහසු වන අතර එය ඔබට සහ අනෙක් සියල්ලන්ටම තේරුම් ගැනීමට වේගවත් වේ.

මතක තබා ගත යුතු එක් දෙයක් මෙයයි:
OOP යනු භාෂා ලක්ෂණ ගැන නොවේ; එය ඔබගේ කේතය සැකසෙන ආකාරය ගැන ය .

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

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

ඉතින්, නැත, අපට OOP කිරීමට OO භාෂා අවශ්‍ය නොවේ . හොඳ OO භාෂාවක් සමඟ OOP කිරීම පහසුය .

වස්තු දිශානත වැඩසටහන් යනු මොඩියුල + සංවෘතකරණයට වඩා වැඩි ය. ඔබ පවසන පරිදි, වස්තු-නැඹුරු (ක්‍රියා පටිපාටික) භාෂාවක මොඩියුල + සංසරණය භාවිතා කළ හැකිය. OOP ඊට වඩා වැඩි යමක් සම්බන්ධ වේ: එයට වස්තූන් හා ක්‍රම සම්බන්ධ වේ. ඉතින්, නැත, එය OOP අල්ලා නොගනී. බලන්න, උදා: https://en.wikipedia.org/wiki/Object-oriented_programming හෝ OOP සඳහා හොඳ පෙළ පොතක් හඳුන්වාදීම.

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

පංති 100 ක පද්ධතියක් ගැන සිතා බලමු, එක් එක් මෙහෙයුම් 20 ක් පමණ සිදු කළ හැකිය; එය කාර්යයන් 2,000 කි. කෙසේ වෙතත්, ඒවායින් 500 ක් පමණක් 'සුරකින්න' සහ 'මකන්න' වැනි සම්පූර්ණ මෙහෙයුම් වන අතර 1500 ක් අභ්‍යන්තර කාර්යයන් වන අතර ඒවා සුළු වශයෙන් නඩත්තු කරන හෝ යම් උපයෝගීතා කාර්යභාරයක් ඉටු කරයි. සලකා බලන්න;

// intentionally in a non-specific language!

setName(person, name) {
    nameParts = splitPersonName(name);
    person.firstName = nameParts[0];
    person.lastName = nameParts[1];
    person.modified = true;
}

splitPersonName(name) {
    var result = [];
    result.add(name.substring(0, name.indexOf(" ")));
    result.add(name.substring(name.indexOf(" ") + 1));
    return result;
}

ඒ නිසා SetNameජනතාව කරන්නේ කළ යුතු ශ්රිතයක් වේ කිරීමට පුද්ගලයෙකු, නමුත් SplitPersonNameභාවිතා කරන උපයෝගීතා ශ්රිතයක් වේ විසින් පුද්ගලයා.

Proced ජු ක්‍රියා පටිපාටි ක්‍රමලේඛනය මෙම මෙහෙයුම් දෙක අතර වෙනසක් නොදක්වයි. ඒ කියන්නේ ඔබේ අවධානයට ලක්වන 2,000 ක්‍රියාකාරී සියල්ල. කෙසේ වෙතත්, අපට මෙම කාර්යයන් 'පුද්ගල වාර්තාවක් ඇති සෑම කෙනෙකුටම ලබා ගත හැකිය' සහ 'පුද්ගල වාර්තාව තුළ උපයෝගිතා ශ්‍රිතයක් ලෙස පමණක් භාවිතා කර ඇත' යනුවෙන් සලකුණු කළ හැකි නම්, අපගේ අවධානය දැන් 500 'සෑම දෙනාගේම කාර්යයන් සඳහා ලබා ගත හැකි අතර 15' උපයෝගීතා ' ඔබ සංස්කරණය කරන පන්තියේ කාර්යයන්.

එයයි publicසහ privateකරන්නේ;

public class Person {
    public void setName(...) {...}
    private string[] splitPersonName(...) { ...}
}