තනි ප්‍රවේශය, තනි පිටවීම (SESE) පිළිබඳ මෙම අදහස පැමිණෙන්නේ සී සහ එකලස් කිරීම වැනි පැහැදිලි සම්පත් කළමනාකරණය සහිත භාෂාවලින් ය . C හි, මෙවැනි කේත මඟින් සම්පත් කාන්දු වේ:
void f()
{
resource res = acquire_resource(); // think malloc()
if( f1(res) )
return; // leaks res
f2(res);
release_resource(res); // think free()
}
එවැනි භාෂාවලින්, ඔබට මූලික වශයෙන් විකල්ප තුනක් ඇත:
පිරිසිදු කිරීමේ කේතය අනුකරණය කරන්න.
අහ්. අතිරික්තය සෑම විටම නරක ය.
gotoපිරිසිදු කිරීමේ කේතයට පනින්න a භාවිතා කරන්න .
මේ සඳහා පිරිසිදු කිරීමේ කේතය ශ්‍රිතයේ අවසාන දෙය විය යුතුය. (මේ නිසා සමහරු තර්ක කරන්නේ gotoඑයට තැනක් ඇති බවය. ඇත්තෙන්ම එය සී.
දේශීය විචල්යයක් හඳුන්වා දී ඒ හරහා පාලන ප්‍රවාහය හසුරුවන්න.
අවාසිය කාරක රීති මගින් හසුරුවනු පාලනය ගලා (හිතන්නේ break, return, if, while) (ඔබ ඇල්ගොරිතමය දෙස බලන කල එම විචල්ය කිසිදු රාජ්ය නිසා) විචල්ය රාජ්ය හරහා මෙහෙයවනවා පාලනය ගලා වඩා අනුගමනය කිරීමට වඩාත් පහසු වේ.
එකලස් කිරීමේදී එය ඊටත් වඩා වෙහෙසකරය, මන්ද ඔබ එම ශ්‍රිතය අමතන විට ශ්‍රිතයක ඕනෑම ලිපිනයකට පනින්නට පුළුවන, එයින් අදහස් කරන්නේ ඔබට ඕනෑම ශ්‍රිතයකට අසීමිත ප්රවේශ සංඛ්‍යාවක් ඇති බවයි. (සමහර විට මෙය ප්‍රයෝජනවත් වේ. C ++ හි බහු උරුම අවස්ථා වලදී thisඇමතුම් virtualකාර්යයන් සඳහා අවශ්‍ය දර්ශක ගැලපුම ක්‍රියාත්මක කිරීම සඳහා සම්පාදකයින්ට පොදු ක්‍රමවේදයකි .
ඔබට සම්පත් අතින් කළමණාකරනය කිරීමට සිදු වූ විට, ඕනෑම තැනක ශ්‍රිතයකට ඇතුළු වීමේ හෝ පිටවීමේ විකල්පයන් ගසාකෑම වඩාත් සංකීර්ණ කේතයකට තුඩු දෙන අතර එමඟින් දෝෂ ඇති වේ. එමනිසා, පිරිසිදු කේත සහ අඩු දෝෂ ලබා ගැනීම සඳහා SESE ප්‍රචාරය කරන ලද චින්තනයක් ඇති විය.
කෙසේ වෙතත්, භාෂාවක ව්‍යතිරේකයක් ඇති විට, (පාහේ) ඕනෑම ශ්‍රිතයක් ඕනෑම වේලාවක (පාහේ) අකාලයේ පිටවිය හැකිය, එබැවින් ඔබ කෙසේ හෝ නොමේරූ නැවත පැමිණීම සඳහා ප්‍රතිපාදන සැපයිය යුතුය. (මම සිතන finallyප්රධාන වශයෙන් ජාවා භාවිතා කරන බව හා usingයා මක ( IDisposable, finally; C ++ වෙනුවට සේවක C # දී නැතිව) RAII ඔබ විසින් මෙය සිදු කළ පසු, ඔබ.) නො හැකි නිසා මුල් කිරීමට ඔබ පසු පිරිසිදු කිරීමට අපොහොසත් return, ප්රකාශය ඒ දේ, සමහරවිට SESE ට පක්ෂව ඇති ප්‍රබලම තර්කය අතුරුදහන් වී ඇත.
එමඟින් කියවීමේ හැකියාව ඉතිරි වේ. ඇත්ත වශයෙන්ම, returnප්‍රකාශ දුසිම් භාගයක් සහිත 200 LoC ශ්‍රිතයක් අහඹු ලෙස ඉසිනු ලැබීම හොඳ ක්රමලේඛ ශෛලියක් නොවන අතර කියවිය හැකි කේතයක් සෑදෙන්නේ නැත. නමුත් එවැනි ක්‍රියාකාරීත්වයක් නොමේරූ ප්රතිලාභ නොමැතිව තේරුම් ගැනීම පහසු නොවනු ඇත.
සම්පත් අතින් හෝ කළමනාකරණය නොකළ යුතු භාෂාවල, පැරණි SESE සම්මුතියට අනුගත වීමේ වටිනාකමක් හෝ වටිනාකමක් නැත. OTOH, මා ඉහත තර්ක කළ පරිදි, SESE බොහෝ විට කේතය වඩාත් සංකීර්ණ කරයි. (සී හැර) වර්තමාන බොහෝ භාෂාවලට නොගැලපෙන ඩයිනෝසෝරයෙකි. කේතයේ අවබෝධය සඳහා උදව් කරනවා වෙනුවට එය එයට බාධා කරයි.
ජාවා ක්‍රමලේඛකයින් මෙයට ඇලී සිටින්නේ ඇයි? මම නොදනිමි, නමුත් මගේ (පිටත) POV වෙතින්, ජාවා සී වෙතින් සම්මුතීන් රාශියක් ගෙන (ඒවා අර්ථවත් වන තැන) සහ ඒවා එහි OO ලෝකයට (ඒවා නිෂ් less ල හෝ සම්පූර්ණයෙන්ම නරක) තැනට යොදන ලදි, එහිදී එය දැන් ඇලී තිබේ ඒවා, කුමන වියදමක් දැරුවත් කමක් නැත. (විෂය පථයේ ආරම්භයේ දී ඔබගේ සියලු විචල්‍යයන් අර්ථ දැක්වීමේ සම්මුතිය මෙන්.)
ක්‍රමලේඛකයින් අතාර්කික හේතූන් මත සියලු ආකාරයේ අමුතු සංකේතවලට ඇලී සිටිති. (ගැඹුරින් කැදැලි කරන ලද ව්‍යුහාත්මක ප්‍රකාශයන් - "ඊතල හෙඩ්ස්" - පැස්කල් වැනි භාෂාවලින් වරෙක ලස්සන කේතයක් ලෙස දැකගත හැකි විය.) මේ සඳහා පිරිසිදු තාර්කික තර්කනයක් යෙදීමෙන් ඔවුන්ගෙන් බහුතරයක් ඔවුන්ගේ ස්ථාපිත මාර්ග වලින් බැහැර වීමට ඒත්තු ගැන්වීමට අපොහොසත් වන බව පෙනේ. එවැනි පුරුදු වෙනස් කිරීමට ඇති හොඳම ක්‍රමය බොහෝ විට සාම්ප්‍රදායික දේ නොව හොඳම දේ කිරීමට ඔවුන්ට ඉක්මනින් ඉගැන්වීමයි. ක්‍රමලේඛන ගුරුවරයෙකු වන ඔබ එය ඔබගේ අතේ තබා ගන්න.:)
