ක්‍රමලේඛන භාෂාවලට ශුන්‍ය යොමු ඇතුළත් කිරීම “ඩොලර් බිලියනයක වැරැද්ද” බව මම අසා ඇත්තෙමි. නමුත් ඇයි? නිසැකවම, ඒවා NullReferenceException වලට හේතු විය හැක, නමුත් ඉතින් කුමක් ද? භාෂාවේ ඕනෑම අංගයක් අනිසි ලෙස භාවිතා කරන්නේ නම් දෝෂ ඇති විය හැකිය.

විකල්පය කුමක්ද? මම හිතන්නේ මෙය කියනවා වෙනුවට:

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

ඔබට මෙය පැවසිය හැකිය:

if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); 
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

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

වඩාත් සවිස්තරාත්මක වීම නිසා NullReferenceException වලට වඩා CustomerNotFoundException නිදොස්කරණය කිරීම ටිකක් පහසු යැයි මම සිතමි. එපමණක්ද?

ශුන්‍යය නපුරකි

මෙම මාතෘකාව පිළිබඳ InfoQ පිළිබඳ ඉදිරිපත් කිරීමක් ඇත: ශූන්‍ය යොමු: ටෝනි හෝරේ විසින් ඩොලර් බිලියනයක වැරැද්ද

විකල්ප වර්ගය

ක්‍රියාකාරී ක්‍රමලේඛනයේ විකල්පය වන්නේ අඩංගු විය හැකි SOME valueහෝ ඇතුළත් කළ හැකි විකල්ප වර්ගයකිNONE .

හොඳ ලිපියක් “විකල්පය” රටාව විකල්ප වර්ගය සාකච්ඡා කර ජාවා සඳහා එය ක්‍රියාත්මක කිරීම සපයයි.

මෙම ගැටළුව පිළිබඳව මම ජාවා සඳහා දෝෂ වාර්තාවක් ද සොයාගෙන ඇත: NullPointerException වලක්වා ගැනීම සඳහා ජාවා වෙත හොඳ විකල්ප වර්ග එකතු කරන්න . මෙම ඉල්ලා ලක්ෂණය ජාවා 8 හදුන්වා දෙන ලදි.

ගැටළුව වන්නේ න්‍යාය අනුව ඕනෑම වස්තුවක් ශුන්‍ය විය හැකි අතර ඔබ එය භාවිතා කිරීමට උත්සාහ කරන විට ව්‍යතිරේකයක් විසි කරයි, ඔබේ වස්තු-නැඹුරු කේතය මූලික වශයෙන් පුපුරා නොගිය බෝම්බ එකතුවකි.

සුන්දර දෝෂ හැසිරවීම ශුන්‍ය-පරීක්ෂා කිරීමේ ifප්‍රකාශයන්ට ක්‍රියාකාරීව සමාන විය හැකි බව ඔබ හරි . නමුත් ඔබ විසින්ම ඒත්තු ගැන්වූ දෙයක් ශුන්‍ය විය නොහැකි විට කුමක් සිදුවේද ? කර්බූම්. ඊළඟට කුමක් සිදු වුවද, මම ඔට්ටු ඇල්ලීමට කැමැත්තෙමි 1) එය සුන්දර නොවනු ඇති අතර 2) ඔබ එයට කැමති නොවනු ඇත.

තවද "නිදොස් කිරීම පහසුය" යන අගය බැහැර නොකරන්න. පරිණත නිෂ්පාදන කේතය පිස්සු, විහිදෙන සත්වයෙකි; වැරදුණු දේ පිළිබඳ වැඩි අවබෝධයක් ලබා දෙන සහ කැණීම් පැය ගණනක් ඉතිරි කර ගත හැකි ඕනෑම දෙයක්.

කේතයේ ශුන්‍ය යොමු භාවිතා කිරීමේදී ගැටළු කිහිපයක් තිබේ.

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

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

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

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

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

ඇයි භාවිතා නොකළ NullObject රටාව කිරීමට ඇති ධාවන චෙක්පත වාසිය ලබා ගැනීමට පහ එය කිරීමට NOP ඔබගේ codebase පුරා ශූන්ය යොමු කිරීම සඳහා සියලු අතිරේක පිරික්සුමක් දකිමින් (සාමාන්ය ප්රාන්තයේ අතුරු මුහුණත අනුකූල) රාජ්ය ක්රම විශේෂිත?

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

ශූන්‍යයන් එතරම් නරක නැත, ඔබ ඒවා බලාපොරොත්තු නොවන්නේ නම්. ඔබ කළ යුතු සුවිශේෂව කේතය දී නියම කිරීමට ඔබ භාෂාවක් නිර්මාණය කිරීමට ප්රශ්නයක් වන ශූන්ය, බලාපොරොත්තු කරන්නේ බව අවශ්යයි. මෙය සලකා බලන්න:

Customer? c = Customer.GetByLastName("Goodman");
// note the question mark -- 'c' is either a Customer or null
if (c != null)
{
    // c is not null, therefore its type in this block is
    // now 'Customer' instead of 'Customer?'
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

ඔබ ක්‍රමයට ආයාචනා කිරීමට උත්සාහ කරන්නේ නම් Customer?, ඔබට සම්පාදක කාල දෝෂයක් ලැබිය යුතුය. බොහෝ භාෂාවන් මෙය නොකිරීමට හේතුව (IMO) විචල්‍යයේ වර්ගය එහි විෂය පථය අනුව වෙනස් වීමට ඒවා ලබා නොදීමයි. භාෂාවට එය හැසිරවිය හැකි නම්, ගැටළුව මුළුමනින්ම විසඳිය හැක්කේ වර්ගය පද්ධතිය.

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

අවාසනාවන්ත රෝග ලක්ෂණ ආවරණය වන පරිදි විශිෂ්ට පිළිතුරු ඕනෑ තරම් තිබේ null, එබැවින් විකල්ප තර්කයක් ඉදිරිපත් කිරීමට මම කැමතියි: ශුන්‍යය යනු වර්ග පද්ධතියේ අඩුපාඩුවක්.

වර්ග පද්ධතියක පරමාර්ථය වන්නේ වැඩසටහනක විවිධ සංරචක නිසි ලෙස “එකට ගැලපෙන” බව සහතික කිරීමයි; හොඳින් ටයිප් කළ වැඩසටහනකට "රේල් පීලි වලින් බැහැරව" නිර්වචනය කළ නොහැකි හැසිරීමට නොහැකිය.

ජාවා හි උපකල්පිත උපභාෂාවක් සලකා බලන්න, නැතහොත් ඔබ කැමති සංඛ්‍යාත්මකව ටයිප් කළ භාෂාව කුමක් වුවත්, ඔබට "Hello, world!"ඕනෑම වර්ගයක ඕනෑම විචල්‍යයකට නූල පැවරිය හැකිය :

Foo foo1 = new Foo();  // Legal
Foo foo2 = "Hello, world!"; // Also legal
Foo foo3 = "Bonjour!"; // Not legal - only "Hello, world!" is allowed

ඔබට එවැනි විචල්‍යයන් පරීක්ෂා කළ හැකිය:

if (foo1 != "Hello, world!") {
    bar(foo1);
} else {
    baz();
}

මේ ගැන කළ නොහැකි කිසිවක් නැත - යමෙකුට අවශ්‍ය නම් එවැනි භාෂාවක් නිර්මාණය කළ හැකිය. විශේෂ අගය විය යුතු නැත "Hello, world!"- එය අංක 42, ටුපල් (1, 4, 9)හෝ, කියන්න, විය nullහැකිය. නමුත් ඔබ මෙය කරන්නේ ඇයි? වර්ගයක විචල්‍යයක් Fooතිබිය යුත්තේ Foos පමණි - එය වර්ග පද්ධතියේ සමස්ත ලක්ෂ්‍යයයි! nullයනු Fooඊට වඩා වැඩි දෙයක් "Hello, world!"නොවේ. නරකම දෙය nullනම් ඕනෑම වර්ගයක වටිනාකමක් නොවන අතර ඔබට එය සමඟ කළ හැකි කිසිවක් නැත!

ක්‍රමලේඛකයාට කිසි විටෙකත් විචල්‍යයක් ඇත්ත වශයෙන්ම a ඇති බව සහතික Fooකළ නොහැක. නිර්වචනය නොකළ හැසිරීම වළක්වා ගැනීම සඳහා, එය විචල්‍යයන් s "Hello, world!"ලෙස භාවිතා කිරීමට පෙර පරීක්ෂා කළ යුතුය Foo. පෙර ස්නිපටයේ නූල් පරීක්‍ෂා කිරීමෙන් foo1 සැබවින්ම a යන කාරණය ප්‍රචාරය නොකරන බව සලකන්න Foo- ආරක්ෂිතව සිටීම සඳහා barතමන්ගේම චෙක්පතක් ද තිබිය හැකිය.

රටා ගැලපීම සමඟ Maybe/ Optionවර්ගයක් භාවිතා කිරීම සමඟ සසඳන්න :

case maybeFoo of
 |  Just foo => bar(foo)
 |  Nothing => baz()

Just fooවගන්තිය ඇතුළත , අපගේ Maybe Fooවිචල්‍යය සැබවින්ම Fooවටිනාකමක් ඇති බව ඔබ සහ වැඩසටහන යන දෙදෙනාම නිසැකවම දනිති - එම තොරතුරු ඇමතුම් දාමයෙන් පහළට ප්‍රචාරය වන අතර barකිසිදු පරීක්‍ෂණයක් කිරීමට අවශ්‍ය නොවේ. නිසා Maybe Fooසිට වෙනස් වර්ගයක් වන අතර Foo, ඔබ එය අඩංගු විය හැකි බව හැකියාව හැසිරවීමට බල කරන්නේ Nothingඔබ විසින් අන්ද මන්දව විසින් කිසි විටෙකත් ලබා ගත නොහැකි නිසා, NullPointerException. ඔබේ වැඩසටහන ගැන ඔබට වඩාත් පහසුවෙන් තර්ක කළ හැකි අතර, සියලු වර්ගවල විචල්‍යයන් Fooසැබවින්ම Foos අඩංගු වන බව දැන දැන සම්පාදකයාට ශුන්‍ය චෙක්පත් මඟ හැරිය හැක . හැමෝම දිනනවා.

ඒ nullපහිටුම් දක්වනය උපකරනයක්

සතුරෙක් නොවේ. ඔබ ඒවා නිවැරදිව භාවිතා කළ යුතුයි.

ශුන්‍ය දර්ශක දෝෂයක් සොයා ගැනීමට සහ නිවැරදි කිරීමට සාපේක්ෂව සාමාන්‍ය අවලංගු දර්ශක දෝෂයක් සොයා ගැනීමට සහ නිවැරදි කිරීමට කොපමණ කාලයක් ගතවේදැයි විනාඩියක් සිතන්න . එරෙහිව දර්ශකයක් පරීක්ෂා කිරීම පහසුය null. වලංගු දත්ත වෙත ශුන්‍ය නොවන දර්ශකයක් යොමු කරන්නේද නැද්ද යන්න තහවුරු කිරීම PITA වේ.

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

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

සංස්කරණය: වුව NullObjectරටාව ශූන්ය විය හැකි බව සඳහන් වඩා හොඳ විසඳුමක් බව පෙනේ, එය ප්රශ්න තමන්ගේ ම හඳුන්වා දෙයි:

• ඒ ආශ්රිත දැරීම NullObject(න්යාය අනුව) කළ යුතු ක්රමයක් ලෙස හැඳින්වේ විට දෙයක් කරන්නේ නැහැ. මේ අනුව, සියුම් දෝෂ හඳුන්වා දිය හැක්කේ වැරදි ලෙස නම් කර නොමැති යොමු කිරීම් නිසා වන අතර ඒවා දැන් ශුන්‍ය නොවන බවට සහතික වී ඇත (ඔව්!) නමුත් අනවශ්‍ය ක්‍රියාවක් සිදු කරයි: කිසිවක් නැත. එන්පීඊ සමඟ එය ගැටළුව පවතින්නේ කොතැනද යන්න පැහැදිලිව පෙනේ. සමඟ NullObjectඒවා ස්වාධීන කෙසේ හෝ (නමුත් වැරදි) ඒ, අපි (ද) දෝශ අනාවරණය වීමේ අවදානමට හඳුන්වා අග. මෙය අවලංගු දර්ශක ගැටලුවකට සමාන නොවන අතර ඒ හා සමාන ප්‍රතිවිපාක ඇත: යොමු දැක්වීම වලංගු දත්ත මෙන් පෙනෙන නමුත් දත්ත දෝෂ හඳුන්වා දෙන අතර එය සොයා ගැනීමට අපහසු විය හැකිය. අවංක විය, මෙම නඩු මම ගනයට ඇතුලත් තොරව අසමත් බව NPE කැමති වනු ඇත වහාම, දැන්,තාර්කික / දත්ත දෝෂයක් නිසා හදිසියේම මට පසුව පාරට වැටේ. දෝෂවල පිරිවැය ඒවා හඳුනාගනු ලබන්නේ කුමන අවධියේද යන්න පිළිබඳ IBM අධ්‍යයනය මතකද?

• ක්‍රමවේදයක් කැඳවූ විට කිසිවක් NullObjectනොකිරීමේ සංකල්පය නොපවතින විට, දේපල ලබා ගන්නෙකු හෝ ශ්‍රිතයක් කැඳවූ විට හෝ ක්‍රමය මඟින් අගයන් ලබා දෙන විට out. අපි කියමු, ප්‍රතිලාභ අගය යනු intඅපි කිසිවක් නොකරන්න යන්නෙන් අදහස් කරන්නේ "ආපසු 0" යන්නයි. නමුත් 0 යනු නිවැරදි “කිසිවක්” (ආපසු නොලැබීම) බව අපට සහතික විය හැක්කේ කෙසේද? සියල්ලට පසු, NullObjectකිසිවක් නොකළ යුතුය, නමුත් වටිනාකමක් ඉල්ලා සිටින විට, එය කෙසේ හෝ ප්රතික්රියා කළ යුතුය. අසමත් වීම විකල්පයක් නොවේ: අපි NullObjectඑන්පීඊ වැළැක්වීම සඳහා භාවිතා කරන අතර, අපි එය වෙනත් ව්‍යතිරේකයකට එරෙහිව වෙළඳාම් නොකරන්නෙමු (ක්‍රියාත්මක නොකෙරේ, ශුන්‍යයෙන් බෙදන්න, ...), එසේ ද? ඔබට යමක් ආපසු ලබා දීමට සිදු වූ විට ඔබ කිසිවක් නිවැරදිව ආපසු ලබා දෙන්නේ කෙසේද?

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

(පැරණි ප්‍රශ්නයක් සඳහා මගේ තොප්පිය වළල්ලට විසි කිරීම;))

ශුන්‍යයේ ඇති විශේෂිත ගැටළුව නම් එය ස්ථිතික ටයිප් කිරීම බිඳ දැමීමයි.

මා සතුව ඇත්නම් Thing t, එවිට මට ඇමතිය හැකි බවට සම්පාදකයාට සහතික විය හැකිය t.doSomething(). හොඳයි, UNLESS tධාවන වේලාවේදී අහෝසි වේ. දැන් ඔට්ටු ඇල්ලීම අහෝසි වී ඇත. සම්පාදකයා කීවේ එය හරි, නමුත් බොහෝ කලකට පසුව tඑය සත්‍ය නොවන බව මම සොයා ගතිමි doSomething(). එබැවින්, දෝෂයන් හසු කර ගැනීම සඳහා සම්පාදකයා විශ්වාස කිරීමට වඩා, ඒවා අල්ලා ගැනීමට ධාවන කාලය තෙක් බලා සිටිය යුතුය. මමත් පයිතන් පාවිච්චි කරනවා!

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

ශුන්‍යයෙන් හෝ negative ණාත්මක ලොගයකින් බෙදීම අතර වෙනස වන්නේ i = 0 වන විට එය තවමත් පූර්ණ සංඛ්‍යාවක් වීමයි. සම්පාදකයාට තවමත් එහි වර්ගය සහතික කළ හැකිය. ගැටළුව වන්නේ තර්කනය විසින් එම අගය තර්කානුකූලව අවසර නොදෙන අයුරින් වැරදි ලෙස අදාළ කර ගැනීමයි ... නමුත් තර්කනය එසේ කරන්නේ නම් එය දෝෂයක අර්ථ දැක්වීමයි.

(මෙම සම්පාදක හැකි BTW, එම ප්රශ්න කිහිපයක් අල්ලා. මෙන් වැනි ප්රකාශන සලකුණු i = 1 / 0බැදීමකට. එහෙත්, ඔබ ඇත්තටම සම්පාදකවරයා උත්සවයකට බවට අනුගමනය හා පරාමිතීන් සියලු කාර්යය ගේ තර්කය සමග අනුරූප වන බව සහතික කිරීම සඳහා බලාපොරොත්තු විය නො හැකි ය)

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

නූල් s = නව පූර්ණ සංඛ්‍යා (1234);

එසේ නම්, එය යොමු කිරීම බිඳ දැමිය හැකි අගයකට (ශුන්‍ය) පැවරීමට ඉඩ දිය යුත්තේ ඇයි s?

ඔබේ කේතයේ "ටයිප් කළ" යොමුව සමඟ "වටිනාකමක් නැත" මිශ්‍ර කිරීමෙන්, ඔබ ක්‍රමලේඛකයන්ට අමතර බරක් පැටවේ. NullPointerException සිදු වූ විට, ඒවා ලුහුබැඳීම ඊටත් වඩා කාලයක් ගතවනු ඇත. ඒ වෙනුවට කියන්න ස්ථිතික ටයිප් මත යැපෙනවාට වඩා "මෙම වන්නේ අපේක්ෂා දෙයක් සැඳහුම," ඔබ භාෂාව කියා දෙනවා "මෙම කරනවා වෙන්න පුළුවන් අපේක්ෂා දෙයක් සැඳහුම."

සංවේදී නොවන කේත වලට ඉඩ දෙන නිසා ශුන්‍ය යොමු කිරීම් වැරැද්දකි:

foo = null
foo.bar()

ඔබ වර්ගයේ පද්ධතිය උත්තේජනය කරන්නේ නම් විකල්ප ඇත:

Maybe<Foo> foo = null
foo.bar() // error{Maybe<Foo> does not have any bar method}

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

හස්කල්ට මුල සිටම ( Maybe) සිට ඇත , සී ++ හි ඔබට උත්තේජනය කළ හැකි boost::optional<T>නමුත් ඔබට තවමත් නිර්වචනය නොකළ හැසිරීම ලබා ගත හැකිය ...

විකල්පය කුමක්ද?

විකල්ප වර්ග සහ රටා ගැලපීම. මම C # නොදන්නා බැවින්, මෙහි Scala # :-) යන ප්‍රබන්ධ භාෂාවක කේත කැබැල්ලක් ඇත

Customer.GetByLastName("Goodman")    // returns Option[Customer]
match
{
    case Some(customer) =>
    Console.WriteLine(customer.FirstName + " " + customer.LastName + " is awesome!");

    case None =>
    Console.WriteLine("There was no customer named Goodman.  How lame!");
}

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

1. ඒවා ශුන්‍ය නොවනු ඇතැයි ඔබ අපේක්ෂා කරන වස්තූන් කිසි විටෙකත් ශුන්‍ය නොවේ
2. ඔබගේ ආරක්ෂක යාන්ත්‍රණයන් සැබවින්ම සියලු විභව අක්‍රීය ණය අක්‍රීය ණය සමඟ .ලදායී ලෙස කටයුතු කරන බව.

ඉතින්, ඇත්ත වශයෙන්ම, ශුන්‍යය අවසන් වීමට ඇත්තේ මිල අධික දෙයක් ලෙසිනි.

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

ගැටළුව එතරම් ශුන්‍ය නොවේ, එය ඔබට නූතන භාෂා රාශියක ශුන්‍ය නොවන යොමු වර්ගයක් නියම කළ නොහැක.

උදාහරණයක් ලෙස, ඔබේ කේතය සමාන විය හැකිය

public void MakeCake(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    egg.Crack();
    MixingBowl.Mix(egg, flour, milk);
    // etc
}

// inside Mixing bowl class
public void Mix(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    //... etc
}

පංති යොමු කිරීම් සම්මත වූ විට, ආරක්ෂිත ක්‍රමලේඛනය මඟින් ඔබව නැවත වරක් ශුන්‍යය සඳහා පරීක්ෂා කර බැලුවද, විශේෂයෙන් නැවත පරීක්ෂාවට ලක්විය හැකි නැවත භාවිතා කළ හැකි ඒකක ගොඩනඟන විට පවා, නැවත නැවත ශුන්‍යය සඳහා සියලු පරාමිතීන් පරීක්ෂා කිරීමට ඔබව දිරිමත් කරයි. එකම සඳහනක් කේත පදනම හරහා 10 වතාවක් ශුන්‍ය ලෙස පහසුවෙන් පරීක්ෂා කළ හැකිය!

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

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

http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

මෙය C # -> https://visualstudio.uservoice.com/forums/121579-visual-studio/category/30931-languages-c

ශූන්‍යය නපුරු ය. කෙසේ වෙතත්, ශූන්‍යයක් නොමැතිකම වඩා විශාල නපුරක් විය හැකිය.

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

ගුඩ්මන් නොමැති විට ඇය දෙස බලන්නේ කුමක් ද? ශුන්‍ය නොවී ඔබට යම් ආකාරයක පෙරනිමි ගනුදෙනුකරුවෙකු ආපසු ලබා දිය යුතුය - දැන් ඔබ එම පෙරනිමියට දේවල් විකුණයි.

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

100 න් අවම වශයෙන් 99 වතාවක් වත් මම ශුන්‍ය භාවිතා කිරීමට තෝරා ගනිමි. මම ඒවා ගැන ස්වයං ප්‍රකාශනය ගැන සතුටු වෙමි.

වඩාත් පොදු අවස්ථාව සඳහා ප්රශස්ත කරන්න.

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

සාමාන්‍ය අවස්ථාවේ දී, මෙය හොඳින් ක්‍රියාත්මක විය යුතුය - ඔබ සොයා බලා, වස්තුව ලබා ගෙන එය භාවිතා කරන්න.

තුළ සුවිශේෂී නඩුව ඔබ (අහඹු ලෙස) දක්වා පාරිභෝගික නම, එම වාර්තාව / වස්තුව පවතී ද යන්න නොදැන සොයන තැන,, ඔබට මෙම අසමත් වූ බව යම් ඇඟවීමක් අවශ්ය කියලා. මෙම තත්වය තුළ, පිළිතුර වන්නේ රෙකෝඩ්නොට්ෆවුන්ඩ් ව්‍යතිරේකයක් විසි කිරීමයි (නැතහොත් පහත SQL සැපයුම්කරු ඔබ වෙනුවෙන් මෙය කිරීමට ඉඩ දෙන්න).

(පරාමිතිය) එන දත්ත විශ්වාස කළ හැකිදැයි ඔබ නොදන්නා තත්වයක ඔබ සිටින්නේ නම්, සමහර විට එය පරිශීලකයෙකු විසින් ඇතුලත් කර ඇති නිසා, එවිට ඔබට 'ට්‍රයිජෙට් පාරිභෝගිකයා (නම, පිටත පාරිභෝගිකයා)' ද ලබා දිය හැකිය. රටාව. Int.Parse සහ int.TryParse සමඟ හරස් යොමු කිරීම.

ව්‍යතිරේකයන් පැහැදිලි නොවේ!

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

ශුන්‍ය වස්තු භාවිතා කිරීමෙන් වැළකී සිටීමෙන් ඔබ එම ව්‍යතිරේකයන්ගෙන් කොටසක් සඟවයි. මම OP උදාහරණය ගැන කතා නොකරමි, එහිදී ඔහු ශුන්‍ය දර්ශක ව්‍යතිරේකය හොඳින් ටයිප් කළ ව්‍යතිරේකයක් බවට පරිවර්තනය කරයි, මෙය කියවීමේ හැකියාව වැඩි කරන බැවින් මෙය ඇත්තෙන්ම හොඳ දෙයක් විය හැකිය. කොහොමද මෙතෙක් ඔබ ගත කරන විට ඔප්ෂන් වර්ගය @Jonas පෙන්වා දී ඇති පරිදි විසඳුමක්, ඔබ ව්යතිරේක සැඟවී ඇත.

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

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

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

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

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

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

val customer = customerDb getByLastName "Goodman"
val awesomeMessage =
  customer map (c => s"${c.firstName} ${c.lastName} is awesome!")
val notFoundMessage = "There was no customer named Goodman.  How lame!"
println(awesomeMessage getOrElse notFoundMessage)

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

A හා සසඳන විට null, එය ටයිප් කරන ස්ථානය ඉතා හොඳය, නමුත් ඔබ සෑම පියවරකදීම පැහැදිලි පරීක්‍ෂණයක් කළ යුතු තැන හෝ ඔබේ මුළු යෙදුමම ක්‍රියාත්මක වන වේලාවේදී පුපුරා යයි, භාවිත අවස්ථාවකදී ඔබ වාසනාවන්ත නම් ඔබේ ඒකකය ව්‍යායාම පරීක්ෂා කරයි. එය කරදරයට වටින්නේ නැත.

NULL හි කේන්ද්‍රීය ගැටළුව වන්නේ එය පද්ධතිය විශ්වාස කළ නොහැකි වීමයි. 1980 දී ටෝනි හෝරේ සිය ටියුරින් සම්මානය වෙනුවෙන් කැප කළ ලිපියේ මෙසේ ලිවීය.

ඒ නිසා, ADA හි ආරම්භකයින්ට සහ නිර්මාණකරුවන්ට මා දුන් හොඳම උපදෙස් නොසලකා හැර ඇත. …. විශ්වසනීයත්වය ඉතා වැදගත් වන යෙදුම්වල, එනම් න්‍යෂ්ටික බලාගාර, ක ise ස් මිසයිල, පූර්ව අනතුරු ඇඟවීමේ පද්ධති, ප්‍රතිබැලිස්ටික් මිසයිල ආරක්ෂක පද්ධති සඳහා මෙම භාෂාව වර්තමාන තත්වයේ භාවිතා කිරීමට ඉඩ නොදෙන්න. ක්‍රමලේඛන භාෂා දෝෂයක ප්‍රති ray ලයක් ලෙස නොමඟ යවන ඊළඟ රොකට්ටුව සිකුරු වෙත හානිකර ගමනක ගවේෂණාත්මක අභ්‍යවකාශ රොකට්ටුවක් නොවිය හැකිය: එය අපේම නගරයක් පුරා පුපුරා යන න්‍යෂ්ටික යුධ නෞකාවක් විය හැකිය. විශ්වාසදායක නොවන වැඩසටහන්, විෂ සහිත පළිබෝධනාශක හෝ න්‍යෂ්ටික බලාගාරවල සිදුවන අනතුරු වලට වඩා විශ්වාසදායක නොවන ක්‍රමලේඛන භාෂාවක් අපගේ පරිසරයට හා අපේ සමාජයට වඩා විශාල අවදානමක් ඇති කරයි. අවදානම අඩු කිරීමට සුපරීක්ෂාකාරී වන්න, එය වැඩි නොකරන්න.

එතැන් සිට ADA භාෂාව බොහෝ වෙනස් වී ඇත, කෙසේ වෙතත් ජාවා, සී # සහ තවත් බොහෝ ජනප්‍රිය භාෂාවල එවැනි ගැටළු තවමත් පවතී.

සේවාදායකයෙකු සහ සැපයුම්කරුවෙකු අතර ගිවිසුම් ඇති කිරීම සංවර්ධකයාගේ යුතුකමයි. උදාහරණයක් ලෙස, C # හි, ජාවාහි මෙන්, කියවීමට පමණක් නිර්මාණය Genericsකිරීමෙන් Nullයොමු කිරීමේ බලපෑම අවම කිරීමට ඔබට භාවිතා කළ හැකිය NullableClass<T>(විකල්ප දෙකක්):

class NullableClass<T>
{
     public HasValue {get;}
     public T Value {get;}
}

ඉන්පසු එය භාවිතා කරන්න

NullableClass<Customer> customer = dbRepository.GetCustomer('Mr. Smith');
if(customer.HasValue){
  // one logic with customer.Value
}else{
  // another logic
} 

හෝ C # දිගු කිරීමේ ක්‍රම සමඟ විකල්ප දෙකක් භාවිතා කරන්න:

customer.Do(
      // code with normal behaviour
      ,
      // what to do in case of null
) 

වෙනස සැලකිය යුතු ය. ක්‍රමවේදයක සේවාදායකයෙකු ලෙස ඔබ අපේක්ෂා කළ යුතු දේ දන්නවා. කණ්ඩායමකට රීතිය තිබිය හැකිය:

පංතියක් NullableClass වර්ගයට අයත් නොවේ නම් එය නිදසුන් නොවිය යුතුය .

කොන්ත්රාත්තුව අනුව සැලසුම් කිරීම සහ සම්පාදනය කරන වේලාවේදී ස්ථිතික පරීක්ෂාව භාවිතා කිරීමෙන් කණ්ඩායමට මෙම අදහස ශක්තිමත් කළ හැකිය , උදා: පූර්ව කොන්දේසි සහිතව:

function SaveCustomer([NotNullAttribute]Customer customer){
     // there is no need to check whether customer is null 
     // it is a client problem, not this supplier
}

හෝ නූලක් සඳහා

function GetCustomer([NotNullAndNotEmptyAttribute]String customerName){
     // there is no need to check whether customerName is null or empty 
     // it is a client problem, not this supplier
}

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

නොමැත.

භාෂාවේ nullගැටලුව වැනි විශේෂ වටිනාකමක් සඳහා භාෂාවක් අසමත් වීම . සෑම හමුවීමකදීම ශුන්‍ය වටිනාකමක් ලබා ගැනීමේ හැකියාව පිළිබඳව පැහැදිලිව කටයුතු කිරීමට ලේඛකයාට බල කරන කොට්ලින් හෝ ස්විෆ්ට් වැනි භාෂාවන් දෙස බැලුවහොත් අනතුරක් නැත.

ප්රශ්නය එක් වැනි භාෂා, භාෂාව ඉඩ nullඕනෑම අගය කිරීමට ^-ish වර්ගය, නමුත් පසුව, එය බව සඳහන් කිරීමෙන් දේවල් මඟ පෙන්වන පිළිගනිමින් කිසිදු නිර්මාණය කරන ලබා දෙන්නේ නැත null, බලාපොරොත්තු නොවූ (වෙන කොහේ හරි සිට ඔබ වෙත සම්මත විශේෂයෙන්ම), සහ මේ අනුව ඔබට කඩාවැටීම් ඇති වේ. නපුර එයයි: ඔබ nullඑය සමඟ ගනුදෙනු නොකර භාවිතා කිරීමට ඉඩ දෙයි .

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

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

මට විරුද්ධව එක් සරල විරෝධයක් ඇත null:

එය අවිනිශ්චිතතාවය හඳුන්වා දීමෙන් ඔබේ කේතයේ අර්ථ නිරූපණය සම්පූර්ණයෙන්ම බිඳ දමයි .

බොහෝ විට ඔබ බලාපොරොත්තු වන්නේ ප්‍රති result ලය එක්තරා ආකාරයක එකක් වනු ඇති බවයි. මෙය අර්ථාන්විත ය. නිශ්චිත දත්ත භාවිතා කරන්නෙකු සඳහා ඔබ දත්ත සමුදාය ඉල්ලා ඇති බව පවසන්න, idනැවත ආරම්භ කිරීම එක්තරා ආකාරයක (= user) එකක් වනු ඇතැයි ඔබ අපේක්ෂා කරයි . නමුත්, එම හැඳුනුම්පත භාවිතා කරන්නෙකු නොමැති නම් කුමක් කළ යුතුද? එක් (නරක) විසඳුමක් නම්: nullඅගයක් එකතු කිරීමයි . එබැවින් ප්‍රති result ලය අපැහැදිලි ය : එක්කෝ එය a userහෝ එය ය null. නමුත් nullඅපේක්ෂිත වර්ගය නොවේ. කේත සුවඳ ආරම්භ වන්නේ මෙහිදීය .

වළක්වා nullගැනීමේදී, ඔබ ඔබේ කේතය අර්ථ නිරූපණය කරයි.

සෑම විටම අවට මාර්ග වේ null, එකතු කිරීමට refactoring: Null-objects, optionalsආදිය

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

1. ස්ථාන ශුන්‍ය දර්ශකයකට පෙරනිමියෙන් තබා ගන්න, නමුත් බිඳවැටීමකින් තොරව කේත බැලීමට (හෝ ඒවා ශුන්‍ය බව තීරණය කිරීමට) ඉඩ නොදෙන්න. දර්ශකයක් ශුන්‍ය කිරීමට සැකසීමේ පැහැදිලි මාධ්‍යයක් සැපයිය හැකිය.
2. ස්ථාන ශුන්‍ය දර්ශකයකට පෙරනිමියෙන් තබාගෙන එකක් කියවීමට උත්සාහ කළහොත් එය බිඳ වැටෙන්න, නමුත් දර්ශකයක් අහෝසි වී ඇත්දැයි පරීක්ෂා කිරීමට බිඳ වැටෙන්නේ නැති මාධ්‍යයක් සපයන්න. දර්ශකයක් ශුන්‍ය කිරීමට සැකසීමේ පැහැදිලි මාධ්‍යයක් ද සපයන්න.
3. නිශ්චිත වර්ගයේ සම්පාදක විසින් සපයන ලද පෙරනිමි අවස්ථාවකට දර්ශකය වෙත පෙරනිමියෙන් ස්ථාන දක්වන්න.
4. නිශ්චිත වැඩසටහන් මඟින් සපයන ලද පෙරනිමි උදාහරණයකට දර්ශකයට පෙරනිමියෙන් ස්ථාන දක්වන්න.
5. කිසියම් ශුන්‍ය-දර්ශක ප්‍රවේශයක් ලබා ගන්න (මෙහෙයුම් අවලංගු කිරීම පමණක් නොවේ) නිදසුනක් සැපයීම සඳහා යම් වැඩසටහන් සපයන පුරුද්දක් අමතන්න.
6. සියලු සාමාජිකයන් මත ආරම්භක චර්යාවන් ක්‍රියාත්මක වන තෙක්, ප්‍රවේශ කළ නොහැකි සම්පාදක තාවකාලිකයක් හැර, ගබඩා ස්ථාන එකතු නොකෙරෙන පරිදි භාෂා අර්ථ නිරූපණය කරන්න (අරාව සාදන්නෙකු වැනි දෙයක් පෙරනිමි අවස්ථාවක් සමඟ සැපයිය යුතුය, නිදසුනක් නැවත ලබා දෙන ශ්‍රිතයක්, හෝ සමහරවිට ශ්‍රිත යුගලයක් - එකක් නිදසුනක් ආපසු ලබා දීම සහ අරාව තැනීමේදී ව්‍යතිරේකයක් සිදුවුවහොත් කලින් ඉදිකරන ලද අවස්ථා සඳහා කැඳවනු ලැබේ).

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

ඔව්, NULL යනු වස්තු-නැඹුරු ලෝකයේ භයානක නිර්මාණයකි . කෙටියෙන් කිවහොත්, NULL භාවිතය පහත පරිදි වේ:

• තාවකාලික දෝෂ හැසිරවීම (ව්‍යතිරේක වෙනුවට)
• නොපැහැදිලි අර්ථකථනය
• වේගයෙන් අසමත් වීම වෙනුවට මන්දගාමී වේ
• පරිගණක චින්තනය එදිරිව වස්තු චින්තනය
• විකෘති සහ අසම්පූර්ණ වස්තු

සවිස්තරාත්මක පැහැදිලි කිරීමක් සඳහා මෙම බ්ලොග් සටහන පරීක්ෂා කරන්න: http://www.yegor256.com/2014/05/13/why-null-is-bad.html