අපි සෑම දෙයක් සඳහාම වර්ග නිර්වචනය කළ යුතුද?

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

අන්තර්ක්‍රියාකාරී හැකියාව නිසා හැඳුනුම්පත අහඹු ලෙස විය යුතුය. මෙය ඉතා අපැහැදිලි අත්සනක් ඇති ක්‍රමයක් නිර්මාණය කළේය:

public string CreateNewThing()

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

public OperationIdentifier CreateNewThing()

වර්ගයෙහි අඩංගු වන්නේ නූල් පමණක් වන අතර මෙම නූල භාවිතා කරන සෑම විටම භාවිතා වේ.

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

ආරක්ෂිත හේතූන් මත පන්තියක සරල වර්ග ඔතා ගැනීම හොඳ පුරුද්දක් යැයි ඔබ සිතනවාද?

ව්‍යාපාරික වසමක stringහෝ වැනි ප්‍රාථමිකයන්ට intඅර්ථයක් නැත. මෙහි සෘජු ප්‍රතිවිපාකය නම් නිෂ්පාදන හැඳුනුම්පතක් අපේක්ෂා කරන විට ඔබ වැරදීමකින් URL එකක් භාවිතා කිරීම හෝ මිල අපේක්ෂා කරන විට ප්‍රමාණය භාවිතා කිරීමයි .

ඇයි ද මෙය වස්තූන් Calisthenics අභියෝගය එහි නීති එකක් ලෙස සැලකෙතත් ඔතන ලක්ෂණයන්ද හෙබි වෙයි:

3 වන රීතිය: සියළුම ප්‍රාථමික හා නූල් ඔතා

ජාවා භාෂාවෙන්, int යනු ප්‍රාථමික, සැබෑ වස්තුවක් නොවේ, එබැවින් එය වස්තූන්ට වඩා වෙනස් නීති වලට අවනත වේ. එය වස්තු-නැඹුරු නොවන සින්ටැක්ස් සමඟ භාවිතා කරයි. වැදගත්ම දෙය නම්, int එකක් තනිවම පරිමාණයකි, එබැවින් එයට අර්ථයක් නැත. ක්‍රමයක් පරාමිතියක් ලෙස int එකක් ගත් විට, ක්‍රමයේ නමට අභිප්‍රාය ප්‍රකාශ කිරීමේ සියලු කාර්යයන් කළ යුතුය. එකම ක්‍රමය පරාමිතියක් ලෙස පැයක් ගත කරන්නේ නම්, සිදුවන්නේ කුමක්ද යන්න බැලීම වඩා පහසුය.

අතිරේක ප්‍රතිලාභයක් ඇති බව එම ලේඛනයම පැහැදිලි කරයි:

පැය හෝ මුදල් වැනි කුඩා වස්තූන් වෙනත් පංති වටා පැටලී ඇති හැසිරීමක් තැබීමට අපට පැහැදිලි ස්ථානයක් ලබා දෙයි .

ඇත්ත වශයෙන්ම, ප්‍රාථමිකයන් භාවිතා කරන විට, සාමාන්‍යයෙන් එම වර්ග වලට අදාළ කේතයේ නිශ්චිත ස්ථානය සොයා ගැනීම අතිශයින් දුෂ්කර වන අතර බොහෝ විට එය දැඩි කේත අනුපිටපත් කිරීමට හේතු වේ. Price: Moneyපංතියක් තිබේ නම් , ඇතුළත පරාසය පරීක්ෂා කිරීම ස්වාභාවිකය. නිෂ්පාදන මිල ගබඩා කිරීම සඳහා int(වඩා නරක, අ double) භාවිතා කරන්නේ නම්, පරාසය වලංගු කළ යුත්තේ කවුද? නිපැයුම? වට්ටම? කරත්තය?

අවසාන වශයෙන්, ලේඛනයේ සඳහන් නොවන තුන්වන වාසිය නම් යටින් පවතින වර්ගය සාපේක්ෂව පහසුවෙන් වෙනස් කිරීමේ හැකියාවයි. අද මගේ නම් ProductIdකර shortඑහි යටින් වර්ගය ලෙස සහ පසුව මම භාවිතා කිරීමට අවශ්ය int, ඒ වෙනුවට, අවස්ථා වෙනස් කිරීමට කේතය සමස්ත කේතය පදනම span නොකරනු ඇත.

අවාසිය - සහ එකම තර්කය වස්තු කැලිස්ටෙනික්ස් ව්‍යායාමයේ සෑම රීතියකටම අදාළ වේ - සෑම දෙයක් සඳහාම පන්තියක් නිර්මාණය කිරීමට ඉක්මණින් අධික වුවහොත් . නම් Productඅඩංගු ProductPriceවන සිට අනුන PositivePriceඅනුන සිට Priceසිට අනෙක් අතට අනුන දී ඇති Money, මේ පිරිසිදු ගෘහ නිර්මාණ ශිල්පය නොවේ, ඒ වෙනුවට, සම්පූර්ණ අවුල් කිසිම දෙයක් සොයා ගැනීම සඳහා, පාලකයා දුසිම් කිහිපයක් සෑම අවස්ථාවකදීම ගොනු විවෘත කළ යුතු තැන.

සලකා බැලිය යුතු තවත් කරුණක් නම් අතිරේක පන්ති නිර්මාණය කිරීමේ පිරිවැය (කේත රේඛා අනුව) ය. එතීම වෙනස් කළ නොහැකි නම් (ඒවා සාමාන්‍යයෙන් විය යුතුය), එයින් අදහස් වන්නේ, අපි C # ගන්නවා නම්, ඔබට අවම වශයෙන් එතීම තුළ තිබිය යුතුය:

• දේපල ලබන්නා,
• එහි පසුබිම් ක්ෂේත්‍රය,
• පසුබිම් ක්ෂේත්‍රයට අගය පවරන ඉදිකිරීම්කරුවෙකු,
• සිරිතක් ToString(),
• XML ප්‍රලේඛන අදහස් (එය පේළි ගොඩක් ඇති කරයි),
• A Equalsසහ GetHashCodeඅතිච්ඡාදනයන් (LOC ගොඩක්).

අවසානයේදී, අදාළ වූ විට:

• නිදොස්කරණය කිරීමේ අංගයක් ,
• ==සහ !=ක්‍රියාකරුවන් අභිබවා යාම ,
• අවසානයේදී සංවෘත වර්ගයට සහ ඉන් පිටතට බාධාවකින් තොරව පරිවර්තනය කිරීම සඳහා ව්‍යංග පරිවර්තන ක්‍රියාකරුගේ අධික බරක්,
• කේත ගිවිසුම් (එහි ලක්ෂණ තුන සහිත තරමක් දිගු ක්‍රමයක් වන ආක්‍රමණ ඇතුළුව),
• XML අනුක්‍රමිකකරණය, JSON අනුක්‍රමිකකරණය හෝ දත්ත ගබඩාවකට / සිට අගයක් ගබඩා කිරීම / පැටවීම අතරතුර භාවිතා කරන පරිවර්තක කිහිපයක්.

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

නිගමනය:

• (1) එය වැරදි අඩු කිරීමට උපකාරී වන විට, (2) කේත අනුපිටපත් කිරීමේ අවදානම අඩු කරන විට හෝ (3) යටින් පවතින වර්ගය වෙනස් කිරීමට උපකාරී වන විට යෙදුමේ ව්‍යාපාරික වසමක අර්ථයක් ඇති පන්තිවල ප්‍රාථමිකයන් ඔතා තබන්න.

• ඔබේ කේතය තුළ ඔබ සොයා ගන්නා සෑම ප්‍රාථමිකයක්ම ස්වයංක්‍රීයව ඔතා නොගන්න: භාවිතා කිරීම stringහෝ intහොඳින් ගැලපෙන අවස්ථා බොහෝය .

ප්‍රායෝගිකව, දී public string CreateNewThing(), ThingIdපන්තියක් වෙනුවට අවස්ථාවක් ලබා දීම stringඋදව් විය හැකි නමුත් ඔබට ද එසේ කළ හැකිය:

• Id<string>පංතියේ නිදසුනක් නැවත ලබා දෙන්න, එය සාමාන්‍ය වර්ගයේ වස්තුවක් වන අතර එය යටින් පවතින වර්ගය නූලක් බව දක්වයි. වර්ග රාශියක් පවත්වා ගෙන යාමේ අඩුපාඩුවක් නොමැතිව ඔබට කියවීමේ හැකියාව ඇත.

• Thingපන්තියේ උදාහරණයක් ආපසු එවන්න . පරිශීලකයාට අවශ්‍ය වන්නේ හැඳුනුම්පත පමණක් නම්, මෙය පහසුවෙන් කළ හැක්කේ:

  var thing = this.CreateNewThing();
  var id = thing.Id;
  

මා විසින් විෂය පථය නියමානුකූල රීතියක් ලෙස භාවිතා කරමි : එවැනි උත්පාදනය හා පරිභෝජනය කිරීමේ විෂය පථය පටුය, valuesමෙම අගය නියෝජනය කරන වස්තුවක් ඔබ නිර්මාණය කිරීමට ඇති ඉඩකඩ අඩුය.

ඔබට පහත ව්‍යාජ කේතය ඇති බව පවසන්න

id = generateProcessId();
doFancyOtherstuff();
job.do(id);

එවිට විෂය පථය ඉතා සීමිත වන අතර එය වර්ගයක් බවට පත්කිරීමේ කිසිදු තේරුමක් මට නොපෙනේ. නමුත් කියන්න, ඔබ මෙම අගය එක් ස්ථරයකින් ජනනය කර එය වෙනත් ස්ථරයකට (හෝ වෙනත් වස්තුවකට) යවන්න, එවිට ඒ සඳහා වර්ගයක් නිර්මාණය කිරීම පරිපූර්ණ අර්ථයක් වනු ඇත.

ස්ථිතික වර්ග පද්ධති යනු දත්ත වැරදි ලෙස භාවිතා කිරීම වැළැක්වීමයි.

මෙය කරන වර්ග සඳහා පැහැදිලි උදාහරණ ඇත:

• ඔබට UUID මාසයක් ලබා ගත නොහැක
• ඔබට නූල් දෙකක් ගුණ කළ නොහැක.

වඩාත් සියුම් උදාහරණ තිබේ

• මේසයේ දිග භාවිතා කරමින් ඔබට යමක් ගෙවිය නොහැක
• යමෙකුගේ නම URL ලෙස භාවිතා කරමින් ඔබට HTTP ඉල්ලීමක් කළ නොහැක.

doubleමිල සහ දිග යන දෙකම සඳහා භාවිතා කිරීමට අප පෙළඹවිය හැකිය , නැතහොත් stringනමක් සහ URL එකක් සඳහා භාවිතා කරන්න . නමුත් එසේ කිරීමෙන් අපගේ පුදුමාකාර වර්ගයේ පද්ධතිය යටපත් වන අතර භාෂාවේ ස්ථිතික චෙක්පත් ලබා ගැනීමට මෙම අනිසි භාවිතය ඉඩ දෙයි.

පවුම්-තත්පර නිව්ටන්-තත්පර සමඟ පටලවා ගැනීම ධාවන වේලාවේදී දුර්වල ප්‍රති results ල ලබා ගත හැකිය .

මෙය විශේෂයෙන් නූල් සමඟ ගැටළුවක්. ඒවා නිතරම "විශ්ව දත්ත වර්ගය" බවට පත්වේ.

අප මූලික වශයෙන් පරිගණක සමඟ අතුරු මුහුණත් පෙළ යැවීමට පුරුදුව සිටින අතර, අපි බොහෝ විට මෙම මානව අතුරුමුහුණත් (UIs) ක්‍රමලේඛ අතුරුමුහුණත් (API) දක්වා විහිදුවමු . 34.25 අක්ෂර 34.25 ලෙස අපි සිතමු . දිනයක් 05-03-2015 අක්ෂර ලෙස අපි සිතමු . අපි UUID එකක් 75e945ee-f1e9-11e4-b9b2-1697f925ec7b අක්ෂර ලෙස සිතමු .

නමුත් මෙම මානසික ආකෘතිය API වියුක්තයට හානි කරයි.

වචන හෝ භාෂාව, ඒවා ලියා ඇති හෝ කථා කරන විට, මගේ චින්තන යාන්ත්‍රණය තුළ කිසිදු කාර්යභාරයක් ඉටු කරන බවක් නොපෙනේ.

ඇල්බට් අයින්ස්ටයින්

ඒ හා සමානව, පෙළ නිරූපණයන් වර්ග සහ ඒපීඅයි සැලසුම් කිරීමේදී කිසිදු කාර්යභාරයක් ඉටු නොකළ යුතුය. පරෙස්සම් වන්න string! (සහ වෙනත් ඕනෑවට වඩා ජනක "ප්‍රාථමික" වර්ග)

වර්ග සන්නිවේදනය කරන්නේ "කුමන මෙහෙයුම් අර්ථවත් කරයිද" යන්නයි.

උදාහරණයක් ලෙස, මම වරක් සේවාදායකයකු සමඟ HTTP REST API වෙත වැඩ කළෙමි. REST, නිසියාකාරව සිදු කර ඇති අතර, අදාළ ආයතන වෙත යොමු කරන අධි-සබැඳි ඇති හයිපර්මීඩියා ආයතන භාවිතා කරන්න. මෙම සේවාදායකයා තුළ, ආයතන ටයිප් කර ඇතිවා පමණක් නොව (උදා: පරිශීලක, ගිණුම, දායකත්වය), එම ආයතන සඳහා සබැඳි ද ටයිප් කර ඇත (පරිශීලක ලින්ක්, ගිණුම් ලින්ක්, දායකත්ව ලින්ක්). සබැඳි එතීමට වඩා මඳක් වැඩි ය Uri, නමුත් වෙනම වර්ග නිසා පරිශීලකයෙකු ලබා ගැනීම සඳහා ගිණුම් සබැඳියක් භාවිතා කිරීමට උත්සාහ කළ නොහැකි විය. සෑම දෙයක්ම සරල Uriහෝ ඊටත් වඩා නරක නම් string- මෙම වැරදි සොයාගත හැක්කේ ධාවන වේලාවේදී පමණි.

ඒ හා සමානව, ඔබගේ තත්වය තුළ, ඔබ සතුව ඇත්තේ එක් අරමුණක් සඳහා පමණක් භාවිතා කරන දත්ත ය: හඳුනා ගැනීමට Operation. එය වෙනත් කිසිවක් සඳහා භාවිතා නොකළ යුතු අතර, Operationඅප විසින් සාදන ලද අහඹු නූල් සමඟ s හඳුනා ගැනීමට උත්සාහ නොකළ යුතුය . වෙනම පන්තියක් නිර්මාණය කිරීමෙන් ඔබේ කේතයට කියවීමේ හැකියාව සහ ආරක්ෂාව ලැබේ.

ඇත්ත වශයෙන්ම, සියලු යහපත් දේ අතිරික්තව භාවිතා කළ හැකිය. සලකා බලන්න

1. එය ඔබේ කේතයට කෙතරම් පැහැදිලි බවක් එක් කරයි

2. එය කොපමණ වාරයක් භාවිතා කරයි

දත්ත වර්ගයක් (වියුක්ත අර්ථයෙන්) නිතර, විශේෂ අරමුණු සඳහා සහ කේත අතුරුමුහුණත් අතර භාවිතා කරන්නේ නම්, එය වාචිකත්වයේ වියදමින් වෙනම පන්තියක් වීම සඳහා ඉතා හොඳ අපේක්ෂකයෙකි.

ආරක්ෂිත හේතූන් මත පන්තියක සරල වර්ග ඔතා ගැනීම හොඳ පුරුද්දක් යැයි ඔබ සිතනවාද?

සමහර විට.

මෙය stringවඩාත් කොන්ක්‍රීට් එකක් වෙනුවට භාවිතා කිරීමෙන් ඇතිවිය හැකි ගැටළු කිරා මැන බැලීමට අවශ්‍ය අවස්ථාවන්ගෙන් එකකි OperationIdentifier. ඔවුන්ගේ බරපතලකම කුමක්ද? ඔවුන්ගේ රුචිකත්වය කුමක්ද?

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

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

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

බොහෝ විට ඔබ ප්‍රාථමික හා නූල් සඳහා වර්ගයක් සෑදිය යුතු බව මම සාමාන්‍යයෙන් එකඟ වෙමි, නමුත් ඉහත පිළිතුරු බොහෝ අවස්ථාවන්හිදී වර්ගයක් සෑදීමට නිර්දේශ කරන හෙයින්, එසේ නොවීමට හේතු කිහිපයක් මම ලැයිස්තුගත කරමි:

• කාර්ය සාධනය. මම මෙහි සත්‍ය භාෂාවන් වෙත යොමු විය යුතුය. C # හි, ග්‍රාහක හැඳුනුම්පතක් කෙටි නම් සහ ඔබ එය පන්තියක ඔතා තිබේ නම් - ඔබ දැන් බොහෝ පොදු කාර්යයන් නිර්මාණය කර ඇත: මතකය, එය දැන් බිට් 64 ක පද්ධතියක් මත බයිට් 8 ක් සහ වේගය නිසා එය ගොඩවල් මත වෙන් කර ඇත.
• ඔබ වර්ගය පිළිබඳ උපකල්පන කරන විට. ග්‍රාහක හැඳුනුම්පතක් කෙටි නම් සහ එය යම් ආකාරයකින් ඇසුරුම් කරන තර්කනයක් තිබේ නම් - ඔබ සාමාන්‍යයෙන් දැනටමත් වර්ගය පිළිබඳ උපකල්පන සිදු කරයි. ඒ සෑම ස්ථානයකම ඔබට දැන් වියුක්තය බිඳ දැමිය යුතුයි. එය එක් ස්ථානයක් නම්, එය ලොකු දෙයක් නොවේ, එය සෑම තැනම තිබේ නම්, ඔබ ප්‍රාථමිකය භාවිතා කරන කාලයෙන් අඩක් ඔබට සොයා ගත හැකිය.
• සෑම භාෂාවකටම යතුරු ලියනය කර නැති නිසා. දැනටමත් ලියා නැති කේත සහ කේත සඳහා, එවැනි වෙනසක් කිරීම දෝෂ හඳුන්වා දීමට පවා ඉඩ ඇති විශාල කාර්යයක් විය හැකිය (නමුත් සෑම කෙනෙකුටම හොඳ ආවරණයක් සහිත පරීක්ෂණ කට්ටලයක් තිබේ, නේද?).
• සමහර අවස්ථාවල එය කියවීමේ හැකියාව අඩු කරයි . මෙය මුද්‍රණය කරන්නේ කෙසේද? මෙය වලංගු කරන්නේ කෙසේද? මම ශුන්‍යදැයි පරීක්ෂා කළ යුතුද? වර්ගය අර්ථ දැක්වීම සඳහා ඔබට අවශ්‍ය සියලුම ප්‍රශ්න තිබේද?

නැත, ඔබ "සියල්ල" සඳහා වර්ග (පන්ති) නිර්වචනය නොකළ යුතුය.

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

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

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

මතුපිටින් පෙනෙන්නේ ඔබ කළ යුත්තේ මෙහෙයුමක් හඳුනා ගැනීම පමණක් බවයි.

මීට අමතරව ඔබ කියන්නේ මෙහෙයුමක් කළ යුතු දේ:

කිරීමට මෙහෙයුම ආරම්භ [සහ] කිරීමට එහි අවසන් අධීක්ෂණය

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

එය පවසයි

විධාන රටාව [...] භාවිතා කරනුයේ ක්‍රියාවක් සිදු කිරීමට හෝ පසුව සිදුවීමක් අවුලුවාලීමට අවශ්‍ය සියලු තොරතුරු සංයුක්ත කිරීමට ය .

ඔබේ මෙහෙයුම් සමඟ ඔබට කිරීමට අවශ්‍ය දේ හා සසඳන විට මෙය බෙහෙවින් සමාන යැයි මම සිතමි. ක සඳහා හඳුනාගැනීමේ නැවත ඒ වෙනුවට වැලක් ආපසු (මම මේ ආකාරයටම දෙකේම තද කරන ලද වාක්ය සංසන්දනය), Operationඋදාහරණයක් ලෙස oop බව පන්තියේ වස්තුවක් අවධානය යොමුකළ වියුක්ත අර්ථයෙන්.

අදහස් දැක්වීම සම්බන්ධයෙන්

මෙම පංතිය විධානයක් ලෙස හැඳින්වීම wtf-y වනු ඇති අතර එය තුළ තර්කනය නොමැත.

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

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

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

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

රටා වියුක්ත බැවින් හොඳ සැබෑ ලෝක රූපක ඉදිරිපත් කිරීම දුෂ්කර විය හැකිය. මෙන්න උත්සාහයක්:

"ඒයි අත්තම්මා, කරුණාකර ඔබට රූපවාහිනියේ පටිගත කිරීමේ බොත්තම 12 ට එබිය හැකිද?

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

ප්‍රාථමික වර්ග ඔතා තැබීමේ අදහස,

• වසම් විශේෂිත භාෂාව ස්ථාපිත කිරීම
• වැරදි අගයන් පසු කිරීමෙන් පරිශීලකයින් කරන වැරදි සීමා කරන්න

නිසැකවම එය සෑම තැනකම කිරීම ඉතා අපහසු හා ප්‍රායෝගික නොවන නමුත් අවශ්‍ය අවස්ථාවන්හි එතීම වැදගත් වේ,

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

Order
{
   long OrderId { get; set; }
   string InvoiceNumber { get; set; }
   string Description { get; set; }
   double Amount { get; set; }
   string CurrencyCode { get; set; }
}

ඇණවුමක් සොයා බැලීම සඳහා වැදගත් ගුණාංග වන්නේ බොහෝ විට OrderId සහ InvoiceNumber ය. මුදල සහ මුදල් කේතය සමීපව සම්බන්ධ වන අතර, යමෙකු මුදල් කේතය වෙනස් නොකර ඇණවුම වෙනස් කළහොත් ඇණවුම තවදුරටත් වලංගු යැයි සැලකිය නොහැකිය.

එබැවින්, OrderId, InvoiceNumber ඔතා මුදල් සඳහා සංයුක්තයක් හඳුන්වා දීම පමණක් මෙම තත්වය තුළ අර්ථවත් වන අතර බොහෝ විට විස්තරය එතීමෙන් කිසිදු තේරුමක් නැත. එබැවින් කැමති ප්‍රති result ලය පෙනෙන්නේ,

    Order
    {
       OrderIdType OrderId { get; set; }
       InvoiceNumberType InvoiceNumber { get; set; }
       string Description { get; set; }
       Currency Amount { get; set; }
    }

එබැවින් සෑම දෙයක්ම එතීමට හේතුවක් නැත, නමුත් ඇත්ත වශයෙන්ම වැදගත් දේවල්.

ජනප්‍රිය නොවන මතය:

ඔබ සාමාන්‍යයෙන් නව වර්ගයක් නිර්වචනය නොකළ යුතුය!

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

ව්‍යාජ වර්ග පොදු පුස්තකාල ක්‍රියාකාරිත්වය නිෂ් .ල කරයි.

ජාවා හි ගණිත කාර්යයන් සියලු සංඛ්‍යා ප්‍රාථමිකයන් සමඟ ක්‍රියා කළ හැකිය. නමුත් ඔබ නව පන්තියේ ප්‍රතිශතයක් අර්ථ දක්වන්නේ නම් (0 ~ 1 පරාසයේ විය හැකි දෙගුණයක් ඔතා) මෙම සියලු කාර්යයන් නිෂ් less ල වන අතර ප්‍රතිශත පන්තියේ අභ්‍යන්තර නිරූපණය ගැන දැන ගැනීමට (ඊටත් වඩා නරක) පන්ති විසින් ඔතා තිබිය යුතුය. .

ව්‍යාජ වර්ග වෛරස් වේ

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

පණිවිඩය රැගෙන යන්න

ඔබ ඔතා ඇති වර්ගයට ව්‍යාපාර තර්කනයක් අවශ්‍ය නොවන තාක් කල් මම එය ව්‍යාජ පන්තියකට එතීමට එරෙහිව උපදෙස් දෙමි. ඔබ පංතියක් ඔතා තැබිය යුත්තේ බරපතල ව්‍යාපාරික බාධක තිබේ නම් පමණි. වෙනත් අවස්ථාවල දී ඔබේ විචල්‍යයන් නිවැරදිව නම් කිරීම අර්ථය ගෙන ඒමට බොහෝ දුර යා යුතුය.

උදාහරණයක්:

A uintහට UserId පරිපූර්ණ ලෙස නිරූපණය කළ හැකිය, අපට ජාවා හි ගොඩනගා ඇති ක්‍රියාකරුවන් සඳහා uint(== වැනි) දිගටම භාවිතා කළ හැකි අතර පරිශීලක හැඳුනුම්පතේ 'අභ්‍යන්තර තත්වය' ආරක්ෂා කිරීමට අපට ව්‍යාපාරික තර්කනයක් අවශ්‍ය නොවේ.

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

කියවීමේ හැකියාව සඳහා නම් කිරීම සම්මුතිය යතුරයි. මේ දෙක ඒකාබද්ධ කිරීමෙන් චේතනාව පැහැදිලිව ප්‍රකාශ කළ හැකිය.
නමුත් /// තවමත් ප්‍රයෝජනවත් වේ.

ඉතින් ඔව්, මම කියන්නේ ඔවුන්ගේ ජීවිත කාලය පන්ති සීමාවෙන් ඔබ්බට ගිය විට බොහෝ වර්ගයන් සාදන්න. ද යන දෙකම භාවිතය සලකා Structහා Class, සෑම විටම පන්තියේ.