පන්ති නම් කිරීම - සෑම දෙයක්ම “<WhatEver> කළමනාකරුවෙකු” ලෙස හැඳින්වීමෙන් වළක්වා ගන්නේ කෙසේද? [වසා ඇත]

බොහෝ කලකට පෙර මම ලිපියක් කියවා ඇත්තෙමි (බ්ලොග් සටහනක්) එය වස්තූන් නම් කිරීම පිළිබඳ "නිවැරදි" මාවතට මාව යොමු කළේය: ඔබේ වැඩසටහනේ දේවල් නම් කිරීම පිළිබඳව ඉතා සූක්ෂ්ම ලෙස කටයුතු කරන්න.

උදාහරණයක් ලෙස මගේ යෙදුම (සාමාන්‍ය ව්‍යාපාරික යෙදුමක් ලෙස) පරිශීලකයින්, සමාගම් සහ ලිපින හසුරුවන්නේ නම් මට User, අ, Companyසහ Addressඩොමේන් පංතියක් තිබේ නම් - සහ බොහෝ විට කොහේ හරි UserManager, ඒ CompanyManagerසහ AddressManagerඒ දේවල් හසුරුවන උත්පතන වේ.

ඒ නිසා ඔබ එම කියන්න පුළුවන් UserManager, CompanyManagerසහ AddressManagerද? නැත, මන්ද කළමනාකරු යනු ඔබගේ වසම් වස්තු සමඟ ඔබට කළ හැකි ඕනෑම දෙයකට ගැලපෙන ඉතා සාමාන්‍ය යෙදුමකි.

මා කියවූ ලිපිය ඉතා නිශ්චිත නම් භාවිතා කිරීම නිර්දේශ කර ඇත. එය සී ++ යෙදුමක් නම් සහ UserManagerකාර්යය නම් පරිශීලකයින් ගොඩවල් වලින් වෙන් කිරීම සහ නිදහස් කිරීම නම් එය පරිශීලකයින් කළමනාකරණය නොකර ඔවුන්ගේ උපත සහ මරණය ආරක්ෂා කරනු ඇත. හ්ම්, සමහර විට අපට මෙය අ UserShepherd.

එසේත් නැතිනම් UserManagerඑක් එක් පරිශීලක වස්තුවේ දත්ත පරීක්ෂා කර දත්ත ගුප්ත ලේඛනගතව අත්සන් කිරීම විය හැකිය. එහෙනම් අපිට අ UserRecordsClerk.

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

පංති කරන දේ මට විස්තර කළ හැකි අතර (මම ඉක්මන් හා අපිරිසිදු කේතීකරණයට ලිස්සා නොයන තාක් කල්) මා ලියන පන්ති හරියටම එක දෙයක් කරයි. එම විස්තරයේ සිට නම් දක්වා යාමට මට මග හැරෙන්නේ එක්තරා නාම නාමාවලියකි, සංකල්ප නම් වලට සිතියම් ගත කරන වචන මාලාවකි.

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

• කර්මාන්තශාලාව - වෙනත් වස්තූන් නිර්මාණය කරයි (සැලසුම් රටාවෙන් නම් කිරීම)
• එ pher ේරා - එ pher ේරෙක් වස්තූන්ගේ ආයු කාලය, ඒවා නිර්මාණය කිරීම සහ වසා දැමීම පාලනය කරයි
• සමමුහුර්තකරණය - වස්තු දෙකක් හෝ වැඩි ගණනක් අතර දත්ත පිටපත් කරයි (හෝ වස්තු ධූරාවලිය)

• නැනී - නිර්මාණය කිරීමෙන් පසු වස්තූන් “භාවිතා කළ හැකි” තත්වයට ළඟා වීමට උපකාරී වේ - නිදසුනක් ලෙස වෙනත් වස්තූන් වෙත රැහැන් ඇදීමෙන්

• ආදිය.

ඉතින්, ඔබ එම ප්‍රශ්නය විසඳන්නේ කෙසේද? ඔබට ස්ථාවර වචන මාලාවක් තිබේද, ඔබ මැස්ස මත නව නම් නිර්මාණය කරනවාද? එසේ නැතිනම් එතරම් වැදගත් නොවන හෝ වැරදි නොවන දේවල් නම් කිරීම ගැන ඔබ සිතනවාද?

PS: මමත් මේ ගැන සාකච්ඡා කරන ලිපි සහ බ්ලොග් වලට සබැඳි ගැන උනන්දු වෙමි. ආරම්භයක් ලෙස, මට ඒ ගැන සිතීමට සැලැස්වූ මුල් ලිපිය මෙන්න: 'කළමනාකරුවෙකු' නොමැතිව ජාවා පන්ති නම් කිරීම.

යාවත්කාලීන කිරීම: පිළිතුරු වල සාරාංශය

මේ අතර මම මේ ප්‍රශ්නයෙන් ඉගෙන ගත් දේ පිළිබඳ කුඩා සාරාංශයක් මෙන්න.

• නව රූපක (නැනී) නිර්මාණය නොකිරීමට උත්සාහ කරන්න
• වෙනත් රාමු කරන්නේ කුමක්දැයි බලන්න

මෙම මාතෘකාව පිළිබඳ වැඩිදුර ලිපි / පොත්:

• නිතිපතා පන්තිවලට සූදානම් වීමට / එකතු වීමට ඔබ සිතන්නේ කුමන නම්ද?
• පන්ති නම් කිරීම සඳහා හොඳම ප්‍රවේශය කුමක්ද?
• පොත: සැලසුම් රටා: නැවත භාවිතා කළ හැකි වස්තු-නැඹුරු මෘදුකාංගයේ මූලද්‍රව්‍ය (දෘ c ආවරණ)
• පොත: ව්‍යවසාය යෙදුම් ගෘහ නිර්මාණ ශිල්පයේ රටා (දෘ c ආවරණ)
• පොත: ක්‍රියාත්මක කිරීමේ රටා (කඩදාසි)

පිළිතුරෙන් මම එකතු කළ (ආත්මීයව!) නාම උපසර්ග / උපසර්ගයන්ගේ වර්තමාන ලැයිස්තුවක්:

• සම්බන්ධීකාරක
• සාදන්නා
• ලේඛකයා
• පා er කයා
• හසුරුවන්නා
• බහාලුම්
• කෙටුම්පත
• ඉලක්කය
• පරිවර්තකය
• පාලකය
• දැක්ම
• කර්මාන්ත ශාලාව
• ආයතනය
• බාල්දිය

මාර්ගය සඳහා හොඳ ඉඟියක්:

අංශභාගය නම් නොකරන්න. ඔව්, නම් ඉතා වැදගත් නමුත් ඒවා විශාල කාලයක් නාස්ති කිරීමට තරම් වැදගත් නොවේ. ඔබට විනාඩි 10 කින් හොඳ නමක් සිතීමට නොහැකි නම්, ඉදිරියට යන්න.

මම ඒ හා සමාන ප්‍රශ්නයක් ඇසුවෙමි , නමුත් හැකි සෑම තැනකම .NET රාමුව තුළ දැනටමත් නම් පිටපත් කිරීමට උත්සාහ කරමි , මම ජාවා සහ ඇන්ඩ්‍රොයිඩ් රාමුවල අදහස් සොයමි.

එය පෙනෙන්නේ Helper, Managerසහ Utilකිසිදු රාජ්‍යයක් නොමැති සහ සාමාන්‍යයෙන් ක්‍රියා පටිපාටි සහ ස්ථිතික වන පන්ති සම්බන්ධීකරණය සඳහා ඔබ ඇමිණිය හැකි නොවැලැක්විය හැකි නාම පද වේ. විකල්පයක් Coordinator.

ඔබ නම් සමග විශේෂයෙන් පාට, දම් පාට prosey ලබා ගත හැකි හා වැනි දේවල් සඳහා යන්න Minder, Overseer, Supervisor, Administrator, හා Master, නමුත් මම ඔබ භාවිතා කරන්නේ රාමුව නම් වගේ එය පිළිපදින කැමති කී පරිදි.

.NET රාමුව තුළ ඔබ සොයා ගන්නා තවත් පොදු උපසර්ගයන් (එය නිවැරදි පදය නම්) :

• Builder
• Writer
• Reader
• Handler
• Container

ඔබට source-code-wordle.de දෙස බැලිය හැකිය .NET රාමුවේ සහ තවත් පුස්තකාලවල පන්ති නාමවල නිතර භාවිතා වන උපසර්ගයන් මම එහි විශ්ලේෂණය කර ඇත්තෙමි.

ඉහළම 20 දෙනා:

• ගුණාංගය
• වර්ගය
• උදව්කරු
• එකතු
• පරිවර්තකය
• හසුරුවන්නා
• තොරතුරු
• සපයන්නා
• ව්යතිරේකය
• සේවාව
• මූලද්රව්යය
• කළමනාකරු
• node
• විකල්පය
• කර්මාන්ත ශාලාව
• සන්දර්භය
• අයිතමය
• නිර්මාණකරු
• පදනම
• සංස්කරණය හෝ

මම සියල්ලම හොඳ නම් සඳහා වන අතර, දේවල් සඳහා නම් තෝරාගැනීමේදී විශාල සැලකිල්ලක් දැක්වීමේ වැදගත්කම ගැන මම බොහෝ විට ලියමි. මේ හේතුවෙන්ම, දේවල් නම් කිරීමේදී මම රූපක ගැන සැලකිලිමත් වෙමි. මුල් ප්‍රශ්නයේදී, "කර්මාන්තශාලාව" සහ "සමමුහුර්තකරණය" යන්නෙන් අදහස් කරන දේ සඳහා හොඳ නම් පෙනේ. කෙසේ වෙතත්, "එ pher ේරා" සහ "නැනී" එසේ නොවේ, මන්ද ඒවා රූපක මත පදනම් වී ඇති බැවිනි. ඔබේ කේතයේ පන්තියක් වචනාර්ථයෙන් නැනී විය නොහැක ; ඔබ එය නැනී ලෙස හඳුන්වන්නේ එය සැබෑ ජීවිතයේ නැනී ළදරුවන් හෝ ළමයින් බලා ගැනීම වැනි වෙනත් දේවල් බලා ගන්නා බැවිනි. අවිධිමත් කථනයේදී එය හරි, නමුත් කේතයේ පන්ති නම් කිරීම සඳහා හරි නැත (මගේ මතය අනුව) එය නඩත්තු කළ යුත්තේ කවදා දන්නේ කවුරුන්ද යන්න දන්නා අය විසිනි.

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

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

අපි ඕනෑම තොරව කරන්න පුළුවන් xxxFactory, xxxManagerහෝ xxxRepositoryඅපි නිවැරදිව සැබෑ ලෝකයේ ආදර්ශයට නම් පන්ති:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)

එය thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages" යනාදියෙහි පළ කළ හැකි දෙයකට ලිස්සන සුළු බෑවුමක් සේ පෙනේ.

එක් මොනොලිතික් මැනේජර් පංතියක් හොඳ නිර්මාණයක් නොවන බව මම සිතමි, නමුත් 'කළමනාකරු' භාවිතා කිරීම නරක නැත. UserManager වෙනුවට අපි එය UserAccountManager, UserProfileManager, UserSecurityManager යනාදිය ලෙස බිඳ දැමිය හැකිය.

'කළමනාකරු' යනු හොඳ වචනයකි, මන්ද එය පැහැදිලිව පෙන්නුම් කරන්නේ පන්තියක් සැබෑ ලෝකයක් නියෝජනය නොකරන බවයි. 'AccountsClerk' - එය පරිශීලක දත්ත කළමනාකරණය කරන පන්තියක්ද, නැතහොත් ඔවුන්ගේ රැකියාව සඳහා ගිණුම් ලිපිකරුවෙකු නියෝජනය කරන්නේද යන්න මා කියන්නේ කෙසේද?

ඔබ මෙම ප්‍රදේශයේ ලිපි ගැන උනන්දුවක් දක්වන බැවින්, ස්ටීව් යෙග්ගේ "නාම පද රාජධානියේ ක්‍රියාත්මක කිරීම" පිළිබඳ අදහස් ලිපිය ගැන ඔබ උනන්දු විය හැකිය:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

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

හොඳින් සැලසුම් කරන ලද පංති පවා (සැමවිටම) තමන් විසින්ම නම් නොකරන අතර, ඔබේ තේරීම් අර්ධ වශයෙන් රඳා පවතින්නේ ඔබ ව්‍යාපාර ආකෘති පන්ති හෝ තාක්ෂණික යටිතල පහසුකම් පන්ති නිර්මාණය කරන්නේද යන්න මතය.

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

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

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

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

මතක තබා ගත යුතු වැදගත්ම දෙය නම්: නම විස්තරාත්මකව ප්‍රමාණවත්ද? පංතිය විසින් කළ යුතු දේ නම බැලීමෙන් ඔබට පැවසිය හැකිද? ඔබේ පංති නාමවල "කළමනාකරු", "සේවය" හෝ "හෑන්ඩ්ලර්" වැනි වචන භාවිතා කිරීම සාමාන්‍ය දෙයක් ලෙස සැලකිය හැකිය, නමුත් බොහෝ ක්‍රමලේඛකයින් ඒවා භාවිතා කරන බැවින් එය පන්තිය සඳහා වන දේ තේරුම් ගැනීමටද උපකාරී වේ.

මමම ෆැසෙඩ් රටාව බොහෝ දුරට භාවිතා කර ඇත්තෙමි (අවම වශයෙන්, එය හැඳින්වෙන්නේ එයයි). මට Userඑක් පරිශීලකයෙකු පමණක් විස්තර කරන Usersපන්තියක් සහ මගේ "පරිශීලක එකතුව" පිළිබඳව සොයා බලන පන්තියක් තිබිය හැකිය. මම පංතියේ අය ලෙස හඳුන්වන්නේ නැත, UserManagerමන්ද මම සැබෑ ජීවිතයේ කළමනාකරුවන්ට අකමැති නිසා සහ ඔවුන් ගැන මතක් කිරීමට මට අවශ්‍ය නැත :) බහු ස්වරූපය භාවිතා කිරීමෙන් පන්තිය කරන්නේ කුමක්ද යන්න තේරුම් ගැනීමට මට උපකාරී වේ.

සී # ට විශේෂිත වූ, නම් කිරීමේ තර්කනය පිළිබඳ හොඳ තොරතුරු රාශියක් ඇති "රාමු සැලසුම් මාර්ගෝපදේශ: සම්මුතීන්, අයිඩියම් සහ නැවත භාවිතා කළ හැකි .නෙට් පුස්තකාල සඳහා රටා" මට හමු විය.

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

මෙහි ඇති තීරණාත්මක දෙය ඔබේ කේතයේ දෘශ්‍යතාවයේ විෂය පථයට අනුකූල වීම බව මම විශ්වාස කරමි, එනම් ඔබේ කේතය දෙස බැලීමට / වැඩ කිරීමට අවශ්‍ය සෑම කෙනෙකුම ඔබේ නම් කිරීමේ සම්මුතිය තේරුම් ගන්නා තාක් කල් එය හොඳ විය යුතුය, ඔබ ඒවා ඇමතීමට තීරණය කළත් 'CompanyThingamabob' සහ 'UserDoohickey'. පළමු නැවතුම, ඔබ සමාගමක් සඳහා වැඩ කරන්නේ නම්, නම් කිරීම සඳහා සමාගම් සම්මුතියක් තිබේදැයි බැලීමයි. සමාගමක් නොමැති නම් හෝ ඔබ වැඩ නොකරන්නේ නම් ඔබට තේරුමක් ඇති වචන භාවිතා කර ඔබේම දෑ සාදන්න, විශ්වාසදායක සගයන් / මිතුරන් කිහිප දෙනෙකු වටා එය සම්මත කර ගන්න, අවම වශයෙන් සාමාන්‍යයෙන් කේත කරන්න, සහ අර්ථවත් වන ඕනෑම ප්‍රතිපෝෂණයක් ඇතුළත් කරන්න.

වෙනත් කෙනෙකුගේ සම්මුතියක් පුළුල් ලෙස පිළිගත් විට පවා එය ඔබ පිටුවෙන් පැන නොයන්නේ නම් එය මගේ පොතේ වැරැද්දකි. පළමුවෙන්ම හා ප්‍රධාන වශයෙන් මට වෙනත් ලියකියවිලි යොමු නොකර මගේ කේතය තේරුම් ගත යුතු නමුත් ඒ සමඟම එය එකම කර්මාන්තයේ එකම ක්ෂේත්‍රයේ වෙනත් කෙනෙකුට තේරුම්ගත නොහැකි තරමට සාමාන්‍ය විය යුතුය.

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

නිදසුනක් ලෙස, UserRecordsClerk සහ CompanyRecordsClerk යන දෙකම ක්‍රියාත්මක කරන හා පසුව විශේෂ ize වූ සාමාන්‍ය රෙකෝඩ්ස්ලර්ක් අතුරුමුහුණතක් විස්තාරණය කිරීමක් ලෙස UserRecordsClerk වඩා හොඳින් පැහැදිලි කළ හැකිය, එයින් අදහස් කරන්නේ යමෙකුට එහි උප පංති කරන්නේ කුමක්ද / සාමාන්‍යයෙන් කුමක් කරන්නේ දැයි බැලීමට අතුරු මුහුණතේ ඇති ක්‍රම දෙස බැලිය හැකි බවයි.

තොරතුරු සඳහා නිර්මාණ රටා වැනි පොතක් බලන්න , එය විශිෂ්ට පොතක් වන අතර ඔබේ කේතය සමඟ ඔබ සිටීමට බලාපොරොත්තු වන ස්ථානය ඉවත් කිරීමට ඔබට උදව් වනු ඇත - ඔබ දැනටමත් එය භාවිතා නොකරන්නේ නම්! ; o)

ඔබේ රටාව මනාව තෝරාගෙන සුදුසු තාක් දුරට භාවිතා කරන තාක් කල් මම සිතන්නේ, අනපේක්ෂිත සරල පන්තියේ නම් ප්‍රමාණවත් විය යුතු බවයි!