சார்பு தலைகீழ்

9.1 சார்பு தலைகீழ்

சர்வர் பயன்பாட்டில் நீங்கள் ஸ்ட்ரீம்களை உருவாக்க முடியாது என்று நாங்கள் ஒருமுறை கூறியதை நினைவில் கொள்க new Thread().start()? கொள்கலன் மட்டுமே நூல்களை உருவாக்க வேண்டும். இப்போது இந்த யோசனையை மேலும் மேம்படுத்துவோம்.

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

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

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

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

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

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

ஒரு வகையில், அத்தகைய முடிவு ஒற்றைத் தேர்வுக் கொள்கையைப் பின்பற்றுகிறது, இது கூறுகிறது: "ஒரு மென்பொருள் அமைப்பு பல மாற்றுகளை ஆதரிக்க வேண்டும், அவற்றின் முழுமையான பட்டியல் கணினியின் ஒரு தொகுதிக்கு மட்டுமே தெரியும்" .

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

உதாரணம் 1

new ArrayList வரிசைப்பட்டியல், லிங்க்டுலிஸ்ட் அல்லது கன்கரன்ட்லிஸ்ட் போன்றவற்றை எழுதுவதற்குப் பதிலாக, List.new()ஒரு இலையின் சரியான செயலாக்கத்தை JDK உங்களுக்கு வழங்குவது அர்த்தமுள்ளதாக இருக்கும் .

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

எடுத்துக்காட்டு 2

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

sort()10 க்கும் குறைவான கூறுகளின் தொகுப்பை நீங்கள் முறைக்கு அனுப்பினால், அதை குமிழ் வரிசை (குமிழி வரிசை) மூலம் வரிசைப்படுத்துவது மிகவும் சாத்தியமாகும், மேலும் Quicksort அல்ல .

எடுத்துக்காட்டு 3

நீங்கள் சரங்களை எவ்வாறு இணைக்கிறீர்கள் என்பதை கம்பைலர் ஏற்கனவே பார்த்துக் கொண்டிருக்கிறது, மேலும் உங்கள் குறியீட்டை StringBuilder.append().

9.2 நடைமுறையில் சார்பு தலைகீழ்

இப்போது மிகவும் சுவாரஸ்யமானது: கோட்பாடு மற்றும் நடைமுறையை எவ்வாறு இணைப்பது என்பதைப் பற்றி சிந்திக்கலாம். தொகுதிகள் எவ்வாறு அவற்றின் "சார்புகளை" சரியாக உருவாக்கலாம் மற்றும் பெறலாம் மற்றும் சார்பு தலைகீழ் மீறலை எவ்வாறு செய்யலாம்?

இதைச் செய்ய, ஒரு தொகுதி வடிவமைக்கும் போது, ​​நீங்களே முடிவு செய்ய வேண்டும்:

• தொகுதி என்ன செய்கிறது, என்ன செயல்பாடு செய்கிறது;
• தொகுதி அதன் சூழலில் இருந்து தேவை, அதாவது, என்ன பொருள்கள் / தொகுதிகள் சமாளிக்க வேண்டும்;
• மற்றும் அவர் அதை எப்படி பெறுவார்?

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

மேலும் இங்கே பின்வரும் விருப்பங்கள் உள்ளன:

• தொகுதியே பொருள்களை உருவாக்குகிறது;
• தொகுதி கொள்கலனில் இருந்து பொருட்களை எடுக்கிறது;
• பொருள்கள் எங்கிருந்து வருகின்றன என்று தொகுதிக்கு தெரியாது.

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

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

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

9.3 சேவை இருப்பிடத்தைப் பயன்படுத்துதல்

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

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

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

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

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

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

• சர்வீஸ் லொக்கேட்டர் ஒரு எதிர்ப்பு வடிவமாகும்
• சுருக்கம் தொழிற்சாலை அல்லது சேவை இருப்பிடம்?

9.4 சார்பு ஊசி

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

இதுவே அழைக்கப்படுகிறது - சார்பு ஊசி. பொதுவாக, தேவையான சார்புகள் கன்ஸ்ட்ரக்டர் அளவுருக்கள் (கட்டமைப்பாளர் ஊசி) அல்லது வகுப்பு முறைகள் (செட்டர் ஊசி) மூலம் அனுப்பப்படுகின்றன.

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

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

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

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

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

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

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

தலைகீழ் கட்டுப்பாட்டின் கொள்கை (சார்பு ஊசி மற்றும் சர்வீஸ் லொக்கேட்டருடன் சேர்ந்து) மார்ட்டின் ஃபோலரால் விரிவாக விவாதிக்கப்பட்டது. அவரது இரண்டு கட்டுரைகளின் மொழிபெயர்ப்புகள் உள்ளன: "கட்டுப்பாட்டு கொள்கலன்களின் தலைகீழ் மற்றும் சார்பு ஊசி முறை" மற்றும் "கட்டுப்பாட்டின் தலைகீழ்" .