SOLID கொள்கைகளைப் பற்றி கேள்விப்படாத டெவலப்பர்களை நான் அடிக்கடி சந்திக்கிறேன் (நாங்கள் . — Transl.) அல்லது பொருள் சார்ந்த நிரலாக்கம் (OOP), அல்லது அவற்றைப் பற்றி கேள்விப்பட்டிருந்தாலும், நடைமுறையில் அவற்றைப் பயன்படுத்த வேண்டாம். டெவலப்பரின் அன்றாட வேலைகளில் உதவும் OOP கொள்கைகளின் நன்மைகளை இந்தக் கட்டுரை விவரிக்கிறது. அவற்றில் சில நன்கு அறியப்பட்டவை, மற்றவை அதிகம் இல்லை, எனவே கட்டுரை ஆரம்ப மற்றும் அனுபவம் வாய்ந்த புரோகிராமர்களுக்கு பயனுள்ளதாக இருக்கும்.
நாங்கள் நினைவூட்டுகிறோம்: அனைத்து Habr வாசகர்களுக்கும் - Habr விளம்பரக் குறியீட்டைப் பயன்படுத்தி எந்த Skillbox படிப்பிலும் சேரும்போது 10 ரூபிள் தள்ளுபடி.
Skillbox பரிந்துரைக்கிறது: கல்வி ஆன்லைன் படிப்பு .
உலர் (உங்களை மீண்டும் செய்ய வேண்டாம்)
மிகவும் எளிமையான கொள்கை, இதன் சாராம்சம் பெயரிலிருந்து தெளிவாகிறது: "உங்களை மீண்டும் செய்யாதீர்கள்." ஒரு புரோகிராமருக்கு, நகல் குறியீட்டைத் தவிர்க்க வேண்டியதன் அவசியத்தையும், அவர்களின் வேலையில் சுருக்கத்தைப் பயன்படுத்துவதற்கான வாய்ப்பையும் இது குறிக்கிறது.
குறியீட்டில் மீண்டும் மீண்டும் இரண்டு பிரிவுகள் இருந்தால், அவை ஒரு முறைக்கு இணைக்கப்பட வேண்டும். ஹார்ட்கோட் செய்யப்பட்ட மதிப்பு ஒன்றுக்கு மேற்பட்ட முறை பயன்படுத்தப்பட்டால், அதை பொது மாறிலியாக மாற்றுவது மதிப்பு.
குறியீட்டை எளிதாக்குவதற்கும், பராமரிப்பதை எளிதாக்குவதற்கும் இது அவசியம், இது OOP இன் முக்கிய குறிக்கோளாகும். ஒரே குறியீடு OrderId மற்றும் SSN இரண்டிலும் சரிபார்ப்பை அனுப்பாது என்பதால், யூனியனை நீங்கள் அதிகமாகப் பயன்படுத்தக்கூடாது.
மாற்றங்களை இணைக்கிறது
பெரும்பாலான நிறுவனங்களின் மென்பொருள் தயாரிப்புகள் தொடர்ந்து உருவாகி வருகின்றன. இதன் பொருள் குறியீட்டில் மாற்றங்கள் செய்யப்பட வேண்டும், அது ஆதரிக்கப்பட வேண்டும். என்கேப்சுலேஷன் மூலம் உங்கள் வாழ்க்கையை எளிதாக்கலாம். ஏற்கனவே உள்ள குறியீட்டுத் தளத்தை மிகவும் திறமையாகச் சோதித்து பராமரிக்க இது உங்களை அனுமதிக்கும். .
ஜாவாவில் எழுதினால் .
திறந்த/மூடிய கொள்கை
பின்வரும் அறிக்கையைப் படிப்பதன் மூலம் இந்தக் கொள்கையை எளிதாக நினைவில் கொள்ளலாம்: "மென்பொருள் நிறுவனங்கள் (வகுப்புகள், தொகுதிகள், செயல்பாடுகள் போன்றவை) நீட்டிப்புக்காகத் திறந்திருக்க வேண்டும், ஆனால் மாற்றத்திற்காக மூடப்பட்டிருக்க வேண்டும்." நடைமுறையில், மூலக் குறியீட்டை மாற்றாமல் அவர்கள் தங்கள் நடத்தையை மாற்ற அனுமதிக்க முடியும் என்பதே இதன் பொருள்.
மூலக் குறியீட்டில் மாற்றங்களுக்கு குறியீடு திருத்தம், அலகு சோதனை மற்றும் பிற நடைமுறைகள் தேவைப்படும்போது கொள்கை முக்கியமானது. திறந்த/மூடப்பட்ட கொள்கையைப் பின்பற்றும் குறியீடு நீட்டிக்கப்படும்போது மாறாது, எனவே அதில் மிகக் குறைவான சிக்கல்கள் உள்ளன.
இந்தக் கொள்கையை மீறும் குறியீட்டின் உதாரணம் இங்கே.
நீங்கள் அதில் ஏதாவது மாற்ற வேண்டும் என்றால், அது நிறைய நேரம் எடுக்கும், ஏனெனில் விரும்பிய துண்டுடன் இணைக்கப்பட்ட குறியீட்டின் அனைத்து பிரிவுகளும் மாற்றப்பட வேண்டும்.
மூலம், திறந்தநிலை-மூடுதல் என்பது SOLID இன் கொள்கைகளில் ஒன்றாகும்.
ஒற்றைப் பொறுப்புக் கொள்கை (SRP)
SOLID தொகுப்பிலிருந்து மற்றொரு கொள்கை. "வகுப்பில் மாற்றத்தை ஏற்படுத்தும் ஒரே ஒரு காரணம் உள்ளது" என்று அது கூறுகிறது. வகுப்பு ஒரு சிக்கலை மட்டுமே தீர்க்கிறது. இது பல முறைகளைக் கொண்டிருக்கலாம், ஆனால் அவை ஒவ்வொன்றும் பொதுவான சிக்கலைத் தீர்க்க மட்டுமே பயன்படுத்தப்படுகின்றன. அனைத்து முறைகளும் பண்புகளும் இதற்கு மட்டுமே சேவை செய்ய வேண்டும்.
இந்த கொள்கையின் மதிப்பு என்னவென்றால், இது தனிப்பட்ட மென்பொருள் கூறு மற்றும் குறியீட்டிற்கு இடையே உள்ள இணைப்பை தளர்த்துகிறது. நீங்கள் ஒரு வகுப்பில் ஒன்றுக்கு மேற்பட்ட செயல்பாடுகளைச் சேர்த்தால், அது இரண்டு செயல்பாடுகளுக்கு இடையே ஒரு உறவை அறிமுகப்படுத்துகிறது. இவ்வாறு, நீங்கள் அவற்றில் ஒன்றை மாற்றினால், முதலில் இணைக்கப்பட்ட இரண்டாவது ஒன்றை அழிக்க அதிக வாய்ப்பு உள்ளது. இது அனைத்து சிக்கல்களையும் முன்கூட்டியே கண்டறியும் பொருட்டு சோதனை சுழற்சிகளை அதிகரிப்பதாகும்.
சார்பு தலைகீழ் கோட்பாடு (டிஐபி)
AppManager ஆனது EventLogWriter ஐச் சார்ந்திருக்கும் குறியீட்டு எடுத்துக்காட்டு மேலே உள்ளது, இது AppManager உடன் நெருக்கமாக இணைக்கப்பட்டுள்ளது. அறிவிப்பைக் காட்ட உங்களுக்கு வேறு வழி தேவைப்பட்டால், அது புஷ், எஸ்எம்எஸ் அல்லது மின்னஞ்சலாக இருக்கலாம், நீங்கள் AppManager வகுப்பை மாற்ற வேண்டும்.
DIP ஐப் பயன்படுத்தி சிக்கலை தீர்க்க முடியும். எனவே, AppManager க்குப் பதிலாக, நாங்கள் EventLogWriter ஐக் கோருகிறோம், இது கட்டமைப்பைப் பயன்படுத்தி உள்ளிடப்படும்.
டிஐபி சார்பு தொகுதியை மாற்றுவதன் மூலம் தனிப்பட்ட தொகுதிகளை எளிதாக மாற்றுவதை சாத்தியமாக்குகிறது. இது ஒரு தொகுதியை மற்றவற்றை பாதிக்காமல் மாற்றுவதை சாத்தியமாக்குகிறது.
பரம்பரைக்கு பதிலாக கலவை
குறியீட்டை மீண்டும் பயன்படுத்த இரண்டு முக்கிய வழிகள் உள்ளன: பரம்பரை மற்றும் கலவை, இவை இரண்டும் அவற்றின் சொந்த நன்மைகள் மற்றும் தீமைகள் உள்ளன. பொதுவாக இரண்டாவது விரும்பப்படுகிறது, ஏனெனில் இது மிகவும் நெகிழ்வானது.
ஒரு வகுப்பின் பண்புகளை அமைப்பதன் மூலம் இயக்க நேரத்தில் அதன் நடத்தையை மாற்றும் திறனை கலவை உங்களுக்கு வழங்குகிறது. இடைமுகங்களை செயல்படுத்தும் போது, பாலிமார்பிசம் பயன்படுத்தப்படுகிறது, இது மிகவும் நெகிழ்வான செயலாக்கத்தை அளிக்கிறது.
ஜோசுவா ப்ளாச்சின் எஃபெக்டிவ் ஜாவா கூட மரபுரிமைக்கு மேல் கலவையைத் தேர்ந்தெடுக்க அறிவுறுத்துகிறது.
பார்பரா லிஸ்கோவ் மாற்றுக் கோட்பாடு (LSP)
SOLID கருவித்தொகுப்பிலிருந்து மற்றொரு கொள்கை. துணை வகைகள் சூப்பர் வகைக்கு மாற்றாக இருக்க வேண்டும் என்று அது கூறுகிறது. அதாவது, ஒரு சூப்பர் கிளாஸ் உடன் வேலை செய்யும் முறைகள் மற்றும் செயல்பாடுகள் அதன் துணைப்பிரிவுகளில் சிக்கல்கள் இல்லாமல் செயல்பட வேண்டும்.
LSP ஒற்றை பொறுப்புக் கொள்கை மற்றும் பகிரப்பட்ட பொறுப்புக் கொள்கை ஆகிய இரண்டுடனும் தொடர்புடையது. ஒரு வகுப்பு துணைப்பிரிவை விட அதிக செயல்பாட்டை வழங்கினால், பிந்தையது இந்த கொள்கையை மீறும் சில செயல்பாடுகளை ஆதரிக்காது.
LSP க்கு முரணான குறியீட்டின் ஒரு பகுதி இங்கே உள்ளது.
பகுதி (செவ்வக r) முறை ஒரு செவ்வகத்தின் பரப்பளவைக் கணக்கிடுகிறது. சதுரத்தை இயக்கிய பிறகு நிரல் செயலிழக்கும், ஏனெனில் சதுரம் இங்கு செவ்வகமாக இல்லை. LSP கொள்கையின்படி, அடிப்படை வகுப்புகளுக்கான குறிப்புகளைப் பயன்படுத்தும் செயல்பாடுகள் கூடுதல் அறிவுறுத்தல்கள் இல்லாமல் பெறப்பட்ட வகுப்புகளின் பொருட்களைப் பயன்படுத்த முடியும்.
துணை வகையின் ஒரு குறிப்பிட்ட வரையறையான இந்தக் கொள்கை, 1987 ஆம் ஆண்டு மாநாட்டின் முக்கிய உரையில் "தரவு சுருக்கம் மற்றும் படிநிலை" என்ற தலைப்பில் பார்பரா லிஸ்கோவ் முன்மொழியப்பட்டது.
இடைமுகப் பிரிப்புக் கொள்கை (ISP)
மற்றொரு SOLID கொள்கை. அதன் படி, பயன்படுத்தப்படாத ஒரு இடைமுகத்தை செயல்படுத்தக்கூடாது. இந்தக் கொள்கையைப் பின்பற்றுவது, இயக்க தர்க்கத்தில் மாற்றங்கள் செய்யப்படும்போது, கணினி நெகிழ்வானதாகவும், மறுசீரமைப்பிற்கு ஏற்றதாகவும் இருக்க உதவுகிறது.
பெரும்பாலும், இடைமுகம் ஒரே நேரத்தில் பல செயல்பாடுகளைக் கொண்டிருக்கும்போது இந்த நிலைமை ஏற்படுகிறது, மேலும் கிளையண்டிற்கு அவற்றில் ஒன்று மட்டுமே தேவைப்படும்.
இடைமுகம் எழுதுவது கடினமான பணி என்பதால், வேலை முடிந்த பிறகு எதையும் உடைக்காமல் மாற்றுவது சவாலாக இருக்கும்.
ஜாவாவில் உள்ள ISP கொள்கையின் நன்மை என்னவென்றால், அனைத்து முறைகளும் முதலில் செயல்படுத்தப்பட வேண்டும், பின்னர் மட்டுமே அவை வகுப்புகளால் பயன்படுத்தப்படலாம். எனவே, கொள்கை முறைகளின் எண்ணிக்கையை குறைக்க உதவுகிறது.
இடைமுகத்திற்கான நிரலாக்கம், செயல்படுத்தல் அல்ல
இங்கே எல்லாம் பெயரிலிருந்து தெளிவாகிறது. இந்தக் கொள்கையைப் பயன்படுத்துவதன் மூலம், இடைமுகத்தின் எந்தவொரு புதிய செயலாக்கத்திலும் செயல்படக்கூடிய நெகிழ்வான குறியீட்டை உருவாக்க முடியும்.
மாறிகள், திரும்பும் வகைகள் அல்லது முறை வாதம் வகைக்கு இடைமுக வகையைப் பயன்படுத்த வேண்டும். சப்கிளாஸை விட சூப்பர் கிளாஸைப் பயன்படுத்துவது ஒரு எடுத்துக்காட்டு.
இதன் பொருள்:
பட்டியல் எண்கள்= getNumbers();
ஆனால் இல்லை:
வரிசைப்பட்டியல் எண்கள் = getNumbers();
மேலே விவாதிக்கப்பட்டவற்றின் நடைமுறைச் செயலாக்கம் இங்கே.
பிரதிநிதித்துவத்தின் கொள்கை
ஒரு பொதுவான உதாரணம் ஜாவாவில் சமம்() மற்றும் ஹாஷ்கோட்() முறைகள். இரண்டு பொருட்களை ஒப்பிட்டுப் பார்க்க வேண்டிய அவசியம் ஏற்பட்டால், இந்தச் செயல் கிளையன்ட் ஒன்றிற்குப் பதிலாக தொடர்புடைய வகுப்பிற்குக் கொடுக்கப்படும்.
கொள்கையின் நன்மை என்னவென்றால், குறியீட்டின் நகல் இல்லை மற்றும் நடத்தை மாற்றுவது ஒப்பீட்டளவில் எளிதானது. இது நிகழ்வு பிரதிநிதிகளுக்கும் பொருந்தும்.
இந்த கொள்கைகள் அனைத்தும் அதிக ஒருங்கிணைப்பு மற்றும் குறைந்த இணைப்புடன் மிகவும் நெகிழ்வான, அழகான மற்றும் நம்பகமான குறியீட்டை எழுத உங்களை அனுமதிக்கின்றன. நிச்சயமாக, கோட்பாடு நல்லது, ஆனால் ஒரு டெவலப்பர் உண்மையில் வாங்கிய அறிவைப் பயன்படுத்த, பயிற்சி தேவை. OOP கொள்கைகளை நீங்கள் தேர்ச்சி பெற்றவுடன், பொதுவான மென்பொருள் மேம்பாடு சிக்கல்களைத் தீர்க்க வடிவமைப்பு வடிவங்களைக் கற்றுக்கொள்வது உங்கள் அடுத்த படியாக இருக்கலாம்.
Skillbox பரிந்துரைக்கிறது:
- நடைமுறை படிப்பு .
- ஆன்லைன் படிப்புக்கு விண்ணப்பித்தேன் .
- இரண்டு வருட நடைமுறை படிப்பு .
ஆதாரம்: www.habr.com