இணைத்தல்

"ஹலோ, அமிகோ! நான் இன்றைய விரிவுரையை என்காப்சுலேஷனுக்கு அர்ப்பணிக்க விரும்புகிறேன் . அது என்னவென்று உங்களுக்கு ஏற்கனவே பொதுவான யோசனை இருக்கிறது."

எனவே அடைப்பின் நன்மைகள் என்ன? பல உள்ளன, ஆனால் எனது பார்வையில் மிக முக்கியமானவை நான் நான்கு சுட்டிக்காட்டுகிறேன்:

1) சரியான உள் நிலை.

நிரல்களில் ஒரே பொருளுடன் தொடர்பு கொள்ளும் பல வகுப்புகள் அடிக்கடி உள்ளன. பொருளின் உள் தரவுகளுடன் ஒரே நேரத்தில் தொடர்புகொள்வதன் மூலம், அவை பொருளின் தரவு ஒருமைப்பாட்டை மீறலாம், இதனால் பொருள் சரியாக வேலை செய்வதை நிறுத்தும்.

எனவே பொருள் அதன் உள் தரவுகளில் ஏதேனும் மாற்றங்களைக் கண்காணிக்க வேண்டும், அல்லது இன்னும் சிறப்பாக - அந்த மாற்றங்களைச் செய்வது அதுவாக இருக்க வேண்டும்.

சில வகுப்பு மாறிகள் மற்ற வகுப்புகளால் மாற்றப்படுவதை நாங்கள் விரும்பவில்லை என்றால், நாங்கள் அதை தனிப்பட்டதாக அறிவிக்கிறோம் , அதாவது அந்த வகுப்பின் முறைகள் மட்டுமே அதை அணுக முடியும். மாறிகள் மற்ற வகுப்புகளுக்கு மட்டும் படிக்க வேண்டும் என விரும்பினால், இந்த மாறிகளில் பொது பெறுநரைச் சேர்க்கிறோம்.

எடுத்துக்காட்டாக, எங்கள் சேகரிப்பில் எத்தனை கூறுகள் உள்ளன என்பதை அனைவரும் தெரிந்து கொள்ள வேண்டும் என்று நாங்கள் விரும்பலாம், ஆனால் எங்கள் அனுமதியின்றி யாரும் அதை மாற்ற முடியாது. இந்த வழக்கில், ஒரு மாறி தனியார் எண்ணின் எண்ணிக்கை மற்றும் பொது getCount() முறையை அறிவிக்கிறோம் .

மற்ற வகுப்புகள் எங்கள் வகுப்பின் உள் தரவை நேரடியாக அணுக முடியாது என்பதையும், அதன் விளைவாக, அவர்களின் செயல்களை நம்மால் கட்டுப்படுத்த முடியாமல் அதை மாற்ற முடியாது என்பதையும் முறையான இணைத்தல் உத்தரவாதம் செய்கிறது . மாற்றப்படும் மாறிகளைக் கொண்ட வகுப்பின் முறைகளை அவர்கள் அழைக்க வேண்டும்.

மற்ற புரோகிராமர்கள் உங்களுக்கு (அல்லது உங்கள் வகுப்புக்கு) பாதுகாப்பான முறையில் அல்லாமல், அவர்களுக்கு மிகவும் வசதியான வழியில் உங்கள் வகுப்புகளைப் பயன்படுத்துவார்கள் என்று கருதுவது சிறந்தது. இது பிழைகளின் ஆதாரம் மற்றும் அவற்றைத் தடுப்பதற்கான ஒரு வழியாகும்.

2) அளவுரு சோதனை.

சில நேரங்களில் உங்கள் வகுப்பின் முறைகளில் அனுப்பப்பட்ட அளவுருக்களை நீங்கள் சரிபார்க்க வேண்டும். எடுத்துக்காட்டாக, எங்களிடம் ஒரு "நபரை" குறிக்கும் ஒரு வகுப்பு உள்ளது என்று வைத்துக்கொள்வோம், அதன் பிறந்த தேதியை நீங்கள் குறிப்பிடலாம். அனுப்பப்பட்ட எந்தத் தரவும் நிரலின் தர்க்கம் மற்றும் வகுப்பின் தர்க்கத்துடன் ஒத்துப்போகிறதா என்பதைச் சரிபார்க்க வேண்டும். எடுத்துக்காட்டாக, 13 வது மாதம் இல்லை, பிப்ரவரி 30 போன்றவை இல்லை.

"ஏன் யாராவது பிப்ரவரி 30 ஆம் தேதி பிறந்த தேதியைக் குறிப்பிடுகிறார்கள்?"

"சரி, முதலில், இது தரவு உள்ளீடு பிழையின் விளைவாக இருக்கலாம்."

இரண்டாவதாக, ஒரு நிரல் கடிகார வேலை போல செயல்படும் முன், அதில் நிறைய பிழைகள் இருக்கலாம். உதாரணமாக, இது போன்ற ஏதாவது நடக்கலாம்.

ஒரு புரோகிராமர் நாளை மறுநாள் யாருக்கு பிறந்தநாள் என்பதை தீர்மானிக்கும் குறியீட்டை எழுதுகிறார். இன்று மார்ச் 3 என்று வைத்துக் கொள்வோம். இந்தத் திட்டம் தற்போதைய தேதியுடன் 2ஐக் கூட்டி, மார்ச் 5ஆம் தேதி பிறந்த அனைவரையும் கண்டுபிடிக்கும். இதுவரை, நன்றாக இருக்கிறது.

ஆனால் மார்ச் 30 வரும்போது, ​​நிரல் யாரையும் கண்டுபிடிக்கவில்லை, ஏனெனில் மார்ச் 32 இல்லை. முறைகள் அளவுரு சரிபார்ப்பைச் செய்யும்போது நிரல்கள் மிகவும் குறைவான தரமற்றதாக இருக்கும்."

"நாங்கள் ArrayList ஐப் படித்தபோது, ​​அதன் குறியீட்டைப் பார்த்தது எனக்கு நினைவிருக்கிறது, மேலும் குறியீட்டு அளவுரு பூஜ்ஜியத்தை விட அதிகமாகவோ அல்லது சமமாகவோ மற்றும் வரிசையின் நீளத்தை விடக் குறைவாகவோ இருப்பதை உறுதிசெய்ய, பெறுதல் மற்றும் அமைக்கும் முறைகளில் சோதனைகள் இருந்தன. குறியீடு எறியும். அணிவரிசையில் குறியீட்டுடன் தொடர்புடைய உறுப்பு இல்லை என்றால் விதிவிலக்கு.

"ஆம், அது உன்னதமான உள்ளீட்டுச் சரிபார்ப்பு. "

3) வகுப்புகளுக்குள் குறியீட்டை மாற்றும்போது குறைவான பிழைகள்.

ஒரு பெரிய திட்டத்தின் ஒரு பகுதியாக நாங்கள் மிகவும் பயனுள்ள வகுப்பை எழுதினோம் என்று வைத்துக்கொள்வோம். எல்லோரும் இதை மிகவும் விரும்புகிறார்கள், மற்ற புரோகிராமர்கள் தங்கள் சொந்த குறியீட்டில் நூற்றுக்கணக்கான இடங்களில் இதைப் பயன்படுத்தத் தொடங்கினர்.

வகுப்பு மிகவும் பயனுள்ளதாக இருந்தது, அதை மேம்படுத்த நீங்கள் முடிவு செய்தீர்கள். ஆனால் வகுப்பில் உள்ள ஏதேனும் முறைகளை நீங்கள் அகற்றினால், டஜன் கணக்கான பிற புரோகிராமர்களின் குறியீடு இனி தொகுக்கப்படாது. அவர்கள் தங்கள் குறியீட்டை விரைவாக மீண்டும் எழுத வேண்டும். மேலும் மீண்டும் எழுதுவது, பிழைகளுக்கு அதிக வாய்ப்புகள் உள்ளன. நீங்கள் வழக்கமாக கட்டமைப்பை உடைத்தால், நீங்கள் வெறுக்கப்படுவீர்கள்.

ஆனால் தனிப்பட்டதாகக் குறிக்கப்பட்ட முறைகளை நாம் மாற்றினால், இந்த முறைகள் வேறு யாருடைய குறியீட்டாலும் எங்கும் அழைக்கப்படவில்லை என்பது எங்களுக்குத் தெரியும். நாம் அவற்றை மீண்டும் எழுதலாம் மற்றும் அளவுருக்களின் எண்ணிக்கை மற்றும் வகையை மாற்றலாம், மேலும் சார்பு குறியீடு இன்னும் வேலை செய்யும். அல்லது குறைந்தபட்சம் அது இன்னும் தொகுக்கும்.

4) மற்ற பொருள்கள் நமது பொருளுடன் எவ்வாறு தொடர்பு கொள்ளும் என்பதை வரையறுக்கிறோம்.

நம் பொருளின் மீது என்ன நடவடிக்கைகள் எடுக்கலாம் என்பதை நாம் கட்டுப்படுத்தலாம். எடுத்துக்காட்டாக, ஒரு வகுப்பின் ஒரே ஒரு நிகழ்வு மட்டுமே உருவாக்கப்பட வேண்டும் என்று நாங்கள் விரும்பலாம்—அது திட்டப்பணியில் ஒரே நேரத்தில் பல இடங்களில் உருவாக்கப்பட்டாலும் கூட. மேலும் இதை நாம் அடைப்பைப் பயன்படுத்தி அடையலாம்.

கூடுதல் பலன்களாக மாறக்கூடிய கூடுதல் கட்டுப்பாடுகளை இணைத்தல் நம்மை அனுமதிக்கிறது . எடுத்துக்காட்டாக, சரம் வகுப்பு ஒரு மாறாத பொருளாக செயல்படுத்தப்படுகிறது . சரம் வகுப்பின் நிகழ்வுகளை அதன் உருவாக்கத்திற்கும் அதன் அழிவுக்கும் இடையில் மாற்ற முடியாது. ஸ்ட்ரிங் வகுப்பின் அனைத்து முறைகளும் (அகற்று, சப்ஸ்ட்ரிங், ...) ஒரு புதிய சரத்தை வழங்குகின்றன, மேலும் அவை அழைக்கப்படும் பொருளை எந்த வகையிலும் மாற்றாது.

"புனிதப் பசு. அப்படித்தான்."

"இணைப்பு புதிரானது."

"நான் ஒப்புக்கொள்கிறேன்."