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

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

அமைப்புகள்

பின்வருபவை ஒரு அமைப்பின் பொதுவாக விரும்பத்தக்க பண்புகள்:

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

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

பட ஆதாரம்

ஒரு அமைப்பை வடிவமைக்கும் நிலைகள்

1. மென்பொருள் அமைப்பு. பயன்பாட்டை ஒட்டுமொத்தமாக வடிவமைக்கவும்.
2. துணை அமைப்புகள்/தொகுப்புகளாகப் பிரித்தல். தர்க்கரீதியாக வேறுபட்ட பகுதிகளை வரையறுத்து, அவற்றுக்கிடையேயான தொடர்புக்கான விதிகளை வரையறுக்கவும்.
3. துணை அமைப்புகளை வகுப்புகளாகப் பிரித்தல். கணினியின் பகுதிகளை குறிப்பிட்ட வகுப்புகள் மற்றும் இடைமுகங்களாகப் பிரித்து, அவற்றுக்கிடையேயான தொடர்புகளை வரையறுக்கவும்.
4. வகுப்புகளை முறைகளாகப் பிரித்தல். ஒரு வகுப்பிற்குத் தேவையான முறைகளின் முழுமையான வரையறையை, அதற்கு ஒதுக்கப்பட்ட பொறுப்பின் அடிப்படையில் உருவாக்கவும்.
5. முறை வடிவமைப்பு. தனிப்பட்ட முறைகளின் செயல்பாட்டின் விரிவான வரையறையை உருவாக்கவும்.

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

கணினி வடிவமைப்பின் பொதுவான கொள்கைகள் மற்றும் கருத்துக்கள்

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

AOP

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

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

SOLID

ஒரு அமைப்பை வடிவமைக்கும் போது, ​​நன்கு அறியப்பட்ட SOLID கொள்கைகளை கருத்தில் கொள்வது மதிப்பு:

எஸ் (ஒற்றை பொறுப்பு), ஓ (திறந்த-மூடப்பட்டது), எல் (லிஸ்கோவ் மாற்று), I (இடைமுகம் பிரித்தல்), டி (சார்பு தலைகீழ்).

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

இடைமுகம்

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

வர்க்கம்

பட ஆதாரம்

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

1. பொது நிலையான மாறிலிகள்;
2. தனிப்பட்ட நிலையான மாறிலிகள்;
3. தனிப்பட்ட நிகழ்வு மாறிகள்.

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

வகுப்பு அளவு

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

பொருள்கள்

இணைத்தல்

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

டிமீட்டர் சட்டம்

டிமீட்டரின் சட்டத்தையும் நாம் பரிசீலிக்கலாம்: இது வகுப்பு மற்றும் முறை மட்டத்தில் சிக்கலை நிர்வகிக்க உதவும் ஒரு சிறிய விதிகள் ஆகும். நம்மிடம் ஒரு கார் பொருள் இருப்பதாக வைத்துக்கொள்வோம், அதற்கு ஒரு நகர்வு (ஆப்ஜெக்ட் arg1, ஆப்ஜெக்ட் arg2) முறை உள்ளது. டிமீட்டரின் சட்டத்தின்படி, இந்த முறை அழைப்பிற்கு மட்டுப்படுத்தப்பட்டுள்ளது:

• கார் பொருளின் முறைகள் (வேறுவிதமாகக் கூறினால், "இந்த" பொருள்);
• நகர்வு முறைக்குள் உருவாக்கப்பட்ட பொருட்களின் முறைகள் ;
• வாதங்களாக அனுப்பப்பட்ட பொருள்களின் முறைகள் ( arg1 , arg2 );
• உள் கார் பொருள்களின் முறைகள் (மீண்டும், "இது").

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

தரவு அமைப்பு

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

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

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

மாறிகளை உருவாக்கும் கோட்பாடுகள்

மாறிகள் பற்றி கொஞ்சம் யோசிப்போம். இன்னும் குறிப்பாக, அவற்றை உருவாக்கும் போது என்ன கொள்கைகள் பொருந்தும் என்பதைப் பற்றி சிந்திக்கலாம்:

1. வெறுமனே, நீங்கள் ஒரு மாறியைப் பயன்படுத்துவதற்கு முன்பு அதை அறிவித்து துவக்க வேண்டும் (ஒன்றை உருவாக்கி அதை மறந்துவிடாதீர்கள்).
2. முடிந்தால், துவக்கத்திற்குப் பிறகு அவற்றின் மதிப்பு மாறுவதைத் தடுக்க மாறிகளை இறுதி என அறிவிக்கவும்.
3. எதிர் மாறிகளைப் பற்றி மறந்துவிடாதீர்கள், இது நாம் வழக்கமாக சில வகையான லூப்பில் பயன்படுத்துகிறோம் . அதாவது, அவற்றை பூஜ்ஜியமாக்க மறக்காதீர்கள். இல்லையெனில், நமது தர்க்கங்கள் அனைத்தும் உடைந்து போகலாம்.
4. நீங்கள் கன்ஸ்ட்ரக்டரில் மாறிகளை துவக்க முயற்சிக்க வேண்டும்.
5. குறிப்புடன் அல்லது இல்லாமல் ( புதிய SomeObject() ) ஒரு பொருளைப் பயன்படுத்துவதில் விருப்பம் இருந்தால், இல்லாமல் தேர்வு செய்யவும், ஏனெனில் பொருள் பயன்படுத்தப்பட்ட பிறகு அடுத்த குப்பை சேகரிப்பு சுழற்சியின் போது அது நீக்கப்படும் மற்றும் அதன் ஆதாரங்கள் வீணாகாது.
6. ஒரு மாறியின் ஆயுட்காலத்தை (மாறியின் உருவாக்கத்திற்கும் கடைசியாகக் குறிப்பிடப்பட்டதற்கும் இடையிலான தூரம்) முடிந்தவரை குறுகியதாக வைத்திருங்கள்.
7. லூப்பைக் கொண்டிருக்கும் முறையின் தொடக்கத்தில் இல்லாமல், லூப்பிற்கு சற்று முன் ஒரு லூப்பில் பயன்படுத்தப்படும் மாறிகளை துவக்கவும்.
8. எப்பொழுதும் மிகவும் வரையறுக்கப்பட்ட நோக்கத்துடன் தொடங்கவும் மற்றும் தேவைப்படும் போது மட்டும் விரிவாக்கவும் (நீங்கள் ஒரு மாறியை முடிந்தவரை உள்ளூராக உருவாக்க முயற்சிக்க வேண்டும்).
9. ஒவ்வொரு மாறியையும் ஒரு நோக்கத்திற்காக மட்டுமே பயன்படுத்தவும்.
10. மறைந்த நோக்கத்துடன் மாறிகளைத் தவிர்க்கவும், எ.கா. இரண்டு பணிகளுக்கு இடையே ஒரு மாறி பிளவு - இதன் வகை, அவற்றில் ஒன்றைத் தீர்ப்பதற்கு ஏற்றதாக இல்லை என்று அர்த்தம்.

முறைகள்

"ஸ்டார் வார்ஸ்: எபிசோட் III - ரிவெஞ்ச் ஆஃப் தி சித்" (2005) திரைப்படத்திலிருந்து

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

1. விதி #1 - சுருக்கம். வெறுமனே, ஒரு முறை 20 வரிகளுக்கு மேல் இருக்கக்கூடாது. இதன் பொருள் என்னவென்றால், ஒரு பொது முறை கணிசமாக "வீங்கினால்", நீங்கள் தர்க்கத்தை உடைத்து தனித்தனி தனிப்பட்ட முறைகளுக்கு நகர்த்துவது பற்றி சிந்திக்க வேண்டும்.

2. விதி #2 — என்றால் , வேறு , மற்றும் பிற அறிக்கைகள் அதிக அளவில் உள்ளமைக்கப்பட்ட தொகுதிகளைக் கொண்டிருக்கக்கூடாது: நிறைய கூடு கட்டுவது குறியீட்டின் வாசிப்புத் திறனைக் கணிசமாகக் குறைக்கிறது . வெறுமனே, உங்களிடம் இரண்டு உள்ளமை {} தொகுதிகளுக்கு மேல் இருக்கக்கூடாது .

   இந்த தொகுதிகளில் உள்ள குறியீட்டை சுருக்கமாகவும் எளிமையாகவும் வைத்திருப்பது விரும்பத்தக்கது.

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

   ஆனால் அறுவை சிகிச்சை ஒரு தனி முறையில் வைக்க மிகவும் எளிமையானதாக தோன்றினால் என்ன செய்வது? உண்மை, சில நேரங்களில் சிட்டுக்குருவிகள் மீது பீரங்கியை சுடுவது போல் உணரலாம், ஆனால் சிறிய முறைகள் பல நன்மைகளை வழங்குகின்றன:

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

4. ஸ்டெப்டவுன் விதி - குறியீடு மேலிருந்து கீழாகப் படிக்கப்பட வேண்டும்: நீங்கள் எவ்வளவு குறைவாகப் படிக்கிறீர்களோ, அவ்வளவு ஆழமாக நீங்கள் தர்க்கத்தைப் படிக்கிறீர்கள். அதற்கு நேர்மாறாக, நீங்கள் எவ்வளவு அதிகமாக செல்கிறீர்களோ, அவ்வளவு சுருக்கமான முறைகள். எடுத்துக்காட்டாக, சுவிட்ச் அறிக்கைகள் கச்சிதமானவை மற்றும் விரும்பத்தகாதவை, ஆனால் நீங்கள் ஒரு சுவிட்சைப் பயன்படுத்துவதைத் தவிர்க்க முடியாவிட்டால், அதை முடிந்தவரை குறைவாக, குறைந்த-நிலை முறைகளுக்கு நகர்த்த முயற்சிக்க வேண்டும்.

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

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

7. ஒரு முறை அதிக எண்ணிக்கையிலான உள்ளீட்டு அளவுருக்களைக் கொண்டிருந்தால் (ஒரு தீவிரமானது 7, ஆனால் நீங்கள் உண்மையில் 2-3க்குப் பிறகு சிந்திக்கத் தொடங்க வேண்டும்), சில வாதங்கள் ஒரு தனி பொருளாக தொகுக்கப்பட வேண்டும்.

8. பல ஒத்த (ஓவர்லோட்) முறைகள் இருந்தால், அதே அளவுருக்கள் ஒரே வரிசையில் அனுப்பப்பட வேண்டும்: இது வாசிப்புத்திறன் மற்றும் பயன்பாட்டினை மேம்படுத்துகிறது.

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

10. முயற்சி/பிடித்தல் இயற்கையில் மிகவும் அழகாகத் தெரியவில்லை, எனவே அதை ஒரு தனி இடைநிலை முறைக்கு (விதிவிலக்குகளைக் கையாளும் முறை) நகர்த்துவது நல்லது.

    
    public void exceptionHandling(SomeObject obj) {
        try {  
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    

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