ആശ്രിതത്വ വിപരീത തത്വം ഉപയോഗിച്ച് നടപ്പിലാക്കുന്നു. ആശ്രിതത്വ വിപരീതം

വാസ്തവത്തിൽ, എല്ലാ തത്വങ്ങളും സോളിഡ്ശക്തമായി പരസ്പരബന്ധിതമാണ്, ഉയർന്ന നിലവാരമുള്ളതും അളക്കാവുന്നതുമായ സോഫ്‌റ്റ്‌വെയർ സൃഷ്ടിക്കാൻ സഹായിക്കുക എന്നതാണ് അവരുടെ പ്രധാന ലക്ഷ്യം. എന്നാൽ അവസാന തത്വം സോളിഡ്ശരിക്കും അവർക്കെതിരെ നിലകൊള്ളുന്നു. ആദ്യം, ഈ തത്വത്തിന്റെ രൂപീകരണം നോക്കാം. അതിനാൽ, ആശ്രിതത്വ വിപരീത തത്വം (ആശ്രിതത്വ വിപരീത തത്വം - ഡിഐപി): “അമൂർത്തതകളെ ആശ്രയിക്കൽ. പ്രത്യേകമായ ഒന്നിനെയും ആശ്രയിക്കുന്നില്ല.. കുപ്രസിദ്ധ സോഫ്‌റ്റ്‌വെയർ ഡെവലപ്‌മെന്റ് വിദഗ്ധൻ റോബർട്ട് മാർട്ടിനും ഈ തത്വം എടുത്തുകാണിക്കുന്നു മുക്കുകമറ്റ് തത്ത്വങ്ങൾ പിന്തുടരുന്നതിന്റെ ഫലമായി അത് അവതരിപ്പിക്കുന്നു സോളിഡ്- തുറന്ന/അടഞ്ഞ തത്വവും ലിസ്കോവ് സബ്സ്റ്റിറ്റ്യൂഷൻ തത്വവും. പുതിയ മാറ്റങ്ങൾ വരുത്തുന്നതിനായി ക്ലാസ് പരിഷ്‌ക്കരിക്കരുതെന്ന് ആദ്യത്തേത് പറയുന്നത് ഓർക്കുക, രണ്ടാമത്തേത് അനന്തരാവകാശവുമായി ഇടപഴകുകയും പ്രോഗ്രാമിന്റെ ശരിയായ പ്രവർത്തനത്തെ തകർക്കാതെ ചില അടിസ്ഥാന തരങ്ങളുടെ ഡെറിവേഡ് തരങ്ങളുടെ സുരക്ഷിതമായ ഉപയോഗം അനുമാനിക്കുകയും ചെയ്യുന്നു. റോബർട്ട് മാർട്ടിൻ ആദ്യം ഈ തത്ത്വം ഇനിപ്പറയുന്ന രീതിയിൽ രൂപപ്പെടുത്തി:

ഒന്ന്). ഉയർന്ന തലത്തിലുള്ള മൊഡ്യൂളുകൾ താഴ്ന്ന നിലയിലുള്ള മൊഡ്യൂളുകളെ ആശ്രയിക്കരുത്. രണ്ട് തലങ്ങളിലുമുള്ള മൊഡ്യൂളുകൾ അമൂർത്തതകളെ ആശ്രയിച്ചിരിക്കണം.

2). സംഗ്രഹങ്ങൾ വിശദാംശങ്ങളെ ആശ്രയിക്കരുത്. വിശദാംശങ്ങൾ അമൂർത്തതകളെ ആശ്രയിച്ചിരിക്കണം.

അതായത്, അമൂർത്തതകളുടെ അടിസ്ഥാനത്തിൽ ക്ലാസുകൾ വികസിപ്പിക്കേണ്ടത് ആവശ്യമാണ്, അല്ലാതെ അവയുടെ നിർദ്ദിഷ്ട നടപ്പാക്കലുകളല്ല. നിങ്ങൾ തത്വങ്ങൾ പാലിക്കുകയാണെങ്കിൽ ഒ.സി.പിഒപ്പം എൽ.എസ്.പി, അപ്പോൾ ഇതാണ് നമ്മൾ നേടുക. അതിനാൽ, നമുക്ക് പാഠത്തിലേക്ക് കുറച്ച് മടങ്ങാം. അവിടെ, ഒരു ഉദാഹരണമായി, ഞങ്ങൾ ക്ലാസ് പരിഗണിച്ചു ബാർഡ്, അത് തുടക്കത്തിൽ തന്നെ ക്ലാസ്സിന് ബുദ്ധിമുട്ടായിരുന്നു ഗിറ്റാർ, ഒരു പ്രത്യേക സംഗീത ഉപകരണത്തെ പ്രതിനിധീകരിക്കുന്നു:

പബ്ലിക് ക്ലാസ് ബാർഡ് (സ്വകാര്യ ഗിറ്റാർ ഗിറ്റാർ; പബ്ലിക് ബാർഡ് (ഗിറ്റാർ ഗിറ്റാർ) (ഇത്.ഗിറ്റാർ = ഗിറ്റാർ; ) പൊതു ശൂന്യമായ പ്ലേ() (guitar.play(); ) )

ഈ ക്ലാസിലേക്ക് മറ്റ് സംഗീതോപകരണങ്ങൾക്കുള്ള പിന്തുണ ചേർക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ എങ്ങനെയെങ്കിലും ഈ ക്ലാസ് പരിഷ്‌ക്കരിക്കേണ്ടതുണ്ട്. ഇത് തത്വത്തിന്റെ വ്യക്തമായ ലംഘനമാണ് ഒ.സി.പി. ഇവയും തത്വത്തിന്റെ ലംഘനങ്ങളാണെന്ന് നിങ്ങൾ ഇതിനകം ശ്രദ്ധിച്ചിരിക്കാം മുക്കുക, ഞങ്ങളുടെ കാര്യത്തിൽ ഞങ്ങളുടെ സംഗ്രഹം വിശദാംശങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു. ഞങ്ങളുടെ ക്ലാസ്സിന്റെ കൂടുതൽ വിപുലീകരണത്തിന്റെ വീക്ഷണകോണിൽ, ഇത് ഒട്ടും നല്ലതല്ല. ഞങ്ങളുടെ ക്ലാസ് തത്വത്തിന്റെ വ്യവസ്ഥകൾ പാലിക്കുന്നതിന് ഒ.സി.പിഞങ്ങൾ സിസ്റ്റത്തിലേക്ക് ഒരു ഇന്റർഫേസ് ചേർത്തു ഉപകരണം, ഇത് ചിലതരം സംഗീതോപകരണങ്ങളെ പ്രതിനിധീകരിക്കുന്ന പ്രത്യേക ക്ലാസുകൾ നടപ്പിലാക്കി.

ഫയൽ Instrument.java:

പബ്ലിക് ഇന്റർഫേസ് ഇൻസ്ട്രുമെന്റ് (ശൂന്യമായ പ്ലേ(); )

ഫയൽ Guitar.java:

ക്ലാസ് ഗിറ്റാർ ഇൻസ്ട്രുമെന്റ് നടപ്പിലാക്കുന്നു( @Override public void play() ( System.out.println("Play Guitar!"); )

ഫയൽ lute.java:

പബ്ലിക് ക്ലാസ് ലൂട്ട് ഇൻസ്ട്രുമെന്റ് നടപ്പിലാക്കുന്നു( @ഓവർറൈഡ് പബ്ലിക് അസാധുവായ പ്ലേ() ( System.out.println("Play Lute!"); )

അതിനു ശേഷം ഞങ്ങൾ ക്ലാസ്സ് മാറ്റി ബാർഡ്അതിനാൽ, ആവശ്യമെങ്കിൽ, നമുക്ക് ആവശ്യമുള്ളവ ഉപയോഗിച്ച് നടപ്പിലാക്കലുകൾ മാറ്റിസ്ഥാപിക്കാം. ഇത് സൃഷ്ടിക്കപ്പെടുന്ന സിസ്റ്റത്തിന് അധിക വഴക്കം നൽകുകയും അതിന്റെ ഏകീകരണം കുറയ്ക്കുകയും ചെയ്യുന്നു (പരസ്പരം ശക്തമായ ക്ലാസ് ആശ്രിതത്വം).

പബ്ലിക് ക്ലാസ് ബാർഡ് (സ്വകാര്യ ഉപകരണ ഉപകരണം; പബ്ലിക് ബാർഡ്() () പൊതു ശൂന്യമായ പ്ലേ() (ഇൻസ്ട്രമെന്റ്.പ്ലേ();

2 മറുപടികൾ

നല്ല കാര്യം - വിപരീതം എന്ന വാക്ക് അൽപ്പം ആശ്ചര്യകരമാണ് (ഡിഐപി പ്രയോഗിച്ചതിന് ശേഷം, ലോവർ-ലെവൽ ഡിപൻഡൻസി മൊഡ്യൂൾ ഇപ്പോൾ ഉയർന്ന തലത്തിലുള്ള കോളർ മൊഡ്യൂളിനെ ആശ്രയിക്കുന്നില്ല: ഒന്നുകിൽ വിളിക്കുന്നയാളോ ആശ്രിതനോ ഒരു അധിക അമൂർത്തീകരണത്തിലൂടെ കൂടുതൽ അയവുള്ളതാണ്. ).

എന്തുകൊണ്ടാണ് ഞാൻ "വിപരീതം" എന്ന വാക്ക് ഉപയോഗിക്കുന്നത് എന്ന് നിങ്ങൾ ചോദിച്ചേക്കാം. വ്യക്തമായി പറഞ്ഞാൽ, ഘടനാപരമായ വിശകലനവും രൂപകൽപ്പനയും പോലുള്ള കൂടുതൽ പരമ്പരാഗത സോഫ്‌റ്റ്‌വെയർ വികസന രീതികൾ സോഫ്റ്റ്‌വെയർ ഘടനകൾ നിർമ്മിക്കാൻ പ്രവണത കാണിക്കുന്നു, അതിൽ ഉയർന്ന തലത്തിലുള്ള മൊഡ്യൂളുകൾ ലോ-ലെവൽ മൊഡ്യൂളുകളെ ആശ്രയിച്ചിരിക്കുന്നു, അതിൽ അമൂർത്തങ്ങൾ വിശദാംശങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു. വാസ്തവത്തിൽ, ഈ രീതികളുടെ ഉദ്ദേശ്യങ്ങളിലൊന്ന്, ഉയർന്ന തലത്തിലുള്ള മൊഡ്യൂളുകൾ ലോ-ലെവൽ മൊഡ്യൂളുകളിലേക്ക് എങ്ങനെ കോളുകൾ വിളിക്കുന്നു എന്ന് വിവരിക്കുന്ന സബ്റൂട്ടീനുകളുടെ ഒരു ശ്രേണി നിർവചിക്കുക എന്നതാണ്.... അങ്ങനെ, നന്നായി രൂപകൽപ്പന ചെയ്ത ഒബ്ജക്റ്റ് ഓറിയന്റഡ് പ്രോഗ്രാമിന്റെ ഡിപൻഡൻസി ഘടനയാണ് ആശ്രിതത്വ ഘടനയുമായി ബന്ധപ്പെട്ട് "വിപരീത", ഇത് സാധാരണയായി പരമ്പരാഗത നടപടിക്രമ രീതികളുടെ ഫലമാണ്.

ഡിഐപിയിൽ അങ്കിൾ ബോബിന്റെ പേപ്പർ വായിക്കുമ്പോൾ ശ്രദ്ധിക്കേണ്ട ഒരു കാര്യം, C++ ന് ഇന്റർഫേസുകളില്ല (എഴുതുന്ന സമയത്ത്, ഇല്ല), അതിനാൽ C++ ൽ ഈ അമൂർത്തീകരണം കൈവരിക്കുന്നത് സാധാരണയായി അമൂർത്തമായ/ശുദ്ധമായ വെർച്വൽ ബേസ് ക്ലാസിലൂടെയാണ്, അതേസമയം ജാവയിൽ നേടാം. അല്ലെങ്കിൽ C# കപ്ലിംഗ് അഴിക്കാനുള്ള അമൂർത്തീകരണം സാധാരണയായി ഡിപൻഡൻസിയിൽ നിന്ന് ഇന്റർഫേസ് അബ്‌സ്‌ട്രാക്റ്റ് ചെയ്യുകയും ഉയർന്ന ലെവൽ മൊഡ്യൂൾ(കൾ) ഇന്റർഫേസുമായി ബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

എഡിറ്റ് ചെയ്യുകവ്യക്തമാക്കാൻ മാത്രം:

"ചില സ്ഥലങ്ങളിൽ ഇതിനെ ആശ്രിതത്വ വിപരീതം എന്ന് വിളിക്കുന്നതും ഞാൻ കാണുന്നു"

വിപരീതം:ആപ്ലിക്കേഷനിൽ നിന്ന് കണ്ടെയ്നറിലേക്ക് ഡിപൻഡൻസി മാനേജ്മെന്റ് വിപരീതമാക്കുക (സ്പ്രിംഗ് പോലെ).

ആശ്രിതത്വ കുത്തിവയ്പ്പ്:

ഒരു ഫാക്ടറി പാറ്റേൺ എഴുതുന്നതിനുപകരം, ക്ലയന്റ് ക്ലാസിലേക്ക് ഒബ്ജക്റ്റ് നേരിട്ട് കുത്തിവയ്ക്കുന്നത് എങ്ങനെ. അതിനാൽ നമുക്ക് ക്ലയന്റ് ക്ലാസിനെ ഇന്റർഫേസിലേക്ക് റഫർ ചെയ്യാം, കൂടാതെ ക്ലയന്റ് ക്ലാസിലേക്ക് കോൺക്രീറ്റ് തരം കുത്തിവയ്ക്കാൻ ഞങ്ങൾക്ക് കഴിയണം. ഇതോടെ, ക്ലയന്റ് ക്ലാസിന് പുതിയ കീവേഡ് ഉപയോഗിക്കേണ്ടതില്ല, കോൺക്രീറ്റ് ക്ലാസുകളിൽ നിന്ന് പൂർണ്ണമായും വേർതിരിക്കപ്പെടുന്നു.

ഇൻവേർഷൻ ഓഫ് കൺട്രോൾ (IoC) സംബന്ധിച്ചെന്ത്?

പരമ്പരാഗത പ്രോഗ്രാമിംഗിൽ, ബിസിനസ്സ് ലോജിക്കിന്റെ ഒഴുക്ക് നിർവചിക്കുന്നത് പരസ്പരം നിശ്ചലമായി നിയോഗിക്കപ്പെട്ടിരിക്കുന്ന വസ്തുക്കളാണ്. നിയന്ത്രണത്തിന്റെ വിപരീതത്തോടെ, ഒഴുക്ക് ഒരു ഒബ്‌ജക്റ്റ് ഗ്രാഫിനെ ആശ്രയിച്ചിരിക്കുന്നു, അത് അസംബ്ലർ തൽക്ഷണം നടത്തുകയും അമൂർത്തതകളിലൂടെ നിർവചിക്കപ്പെട്ട ഒബ്‌ജക്റ്റ് ഇന്ററാക്ഷനുകൾ വഴി സാധ്യമാക്കുകയും ചെയ്യുന്നു. ഒരു സർവീസ് ലൊക്കേറ്റർ ഉപയോഗിക്കുന്നത് നിയന്ത്രണത്തിന്റെ വിപരീതവും നൽകുന്നുവെന്ന് ചിലർ വാദിക്കുന്നുണ്ടെങ്കിലും, ബണ്ടിംഗ് പ്രക്രിയ ഡിപൻഡൻസി ഇഞ്ചക്ഷൻ വഴിയാണ് സാധ്യമാകുന്നത്.

ഒരു ഡിസൈൻ ഗൈഡായി നിയന്ത്രണത്തിന്റെ വിപരീതം ഇനിപ്പറയുന്ന ഉദ്ദേശ്യങ്ങൾ നിറവേറ്റുന്നു:

• നിർവ്വഹണത്തിൽ നിന്ന് ഒരു പ്രത്യേക ചുമതലയുടെ നിർവ്വഹണത്തിന്റെ ഒരു വേർപെടുത്തൽ ഉണ്ട്.
• ഓരോ മൊഡ്യൂളിനും അത് ഉദ്ദേശിച്ചതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിയും.
• മൊഡ്യൂളുകൾ മറ്റ് സിസ്റ്റങ്ങൾ ചെയ്യുന്നതിനെ കുറിച്ച് അനുമാനങ്ങളൊന്നും ഉണ്ടാക്കുന്നില്ല, എന്നാൽ അവയുടെ കരാറുകളെ ആശ്രയിക്കുന്നു.
• മൊഡ്യൂളുകൾ മാറ്റിസ്ഥാപിക്കുന്നത് മറ്റ് മൊഡ്യൂളുകളെ ബാധിക്കില്ല.

കൂടുതൽ വിവരങ്ങൾക്ക് കാണുക.

അവസാനം അപ്ഡേറ്റ് ചെയ്തത്: 03/11/2016

ആശ്രിതത്വ വിപരീത തത്വം(ഡിപൻഡൻസി ഇൻവേർഷൻ പ്രിൻസിപ്പിൾ) ടെസ്റ്റ് ചെയ്യാനും പരിഷ്കരിക്കാനും അപ്ഡേറ്റ് ചെയ്യാനും എളുപ്പമുള്ള ലൂസ്ലി കപ്പിൾഡ് എന്റിറ്റികൾ സൃഷ്ടിക്കാൻ ഉപയോഗിക്കുന്നു. ഈ തത്വം ഇനിപ്പറയുന്ന രീതിയിൽ രൂപപ്പെടുത്താം:

ഉയർന്ന തലത്തിലുള്ള മൊഡ്യൂളുകൾ താഴ്ന്ന നിലയിലുള്ള മൊഡ്യൂളുകളെ ആശ്രയിക്കരുത്. രണ്ടും അമൂർത്തതകളെ ആശ്രയിക്കണം.

സംഗ്രഹങ്ങൾ വിശദാംശങ്ങളെ ആശ്രയിക്കരുത്. വിശദാംശങ്ങൾ അമൂർത്തതകളെ ആശ്രയിച്ചിരിക്കണം.

തത്വം മനസിലാക്കാൻ, ഇനിപ്പറയുന്ന ഉദാഹരണം പരിഗണിക്കുക:

ക്ലാസ് ബുക്ക് (പബ്ലിക് സ്‌ട്രിംഗ് ടെക്‌സ്‌റ്റ് (ഗെറ്റ്; സെറ്റ്; ) പബ്ലിക് കൺസോൾ പ്രിന്റർ പ്രിന്റർ (ഗെറ്റ്; സെറ്റ്; ) പബ്ലിക് അസാധുവായ പ്രിന്റ് () ( പ്രിന്റർ.പ്രിന്റ് (ടെക്‌സ്റ്റ്); ) ) ക്ലാസ് കൺസോൾ പ്രിന്റർ (പബ്ലിക് അസാധുവായ പ്രിന്റ് (സ്‌ട്രിംഗ് ടെക്‌സ്‌റ്റ്) ( കൺസോൾ.റൈറ്റ്‌ലൈൻ (ടെക്സ്റ്റ്); )

ഒരു പുസ്തകത്തെ പ്രതിനിധീകരിക്കുന്ന ബുക്ക് ക്ലാസ്, പ്രിന്റ് ചെയ്യാൻ കൺസോൾ പ്രിന്റർ ക്ലാസ് ഉപയോഗിക്കുന്നു. ഇങ്ങനെ നിർവചിക്കുമ്പോൾ, ബുക്ക് ക്ലാസ് കൺസോൾ പ്രിന്റർ ക്ലാസിനെ ആശ്രയിച്ചിരിക്കുന്നു. മാത്രമല്ല, കൺസോൾ പ്രിന്റർ ക്ലാസ് ഉപയോഗിച്ച് കൺസോളിൽ മാത്രമേ ഒരു പുസ്തകം അച്ചടിക്കാൻ കഴിയൂ എന്ന് ഞങ്ങൾ കർശനമായി നിർവചിച്ചിട്ടുണ്ട്. മറ്റ് ഓപ്ഷനുകൾ, ഉദാഹരണത്തിന്, ഒരു പ്രിന്ററിലേക്കുള്ള ഔട്ട്പുട്ട്, ഒരു ഫയലിലേക്കുള്ള ഔട്ട്പുട്ട്, അല്ലെങ്കിൽ ഒരു ഗ്രാഫിക്കൽ ഇന്റർഫേസിന്റെ ചില ഘടകങ്ങൾ ഉപയോഗിക്കുന്നത് - ഈ സാഹചര്യത്തിൽ ഇതെല്ലാം ഒഴിവാക്കിയിരിക്കുന്നു. കൺസോൾപ്രിന്റർ ക്ലാസിന്റെ വിശദാംശങ്ങളിൽ നിന്ന് പുസ്തക പ്രിന്റിംഗ് സംഗ്രഹം വേറിട്ടതല്ല. ഇതെല്ലാം ആശ്രിതത്വ വിപരീത തത്വത്തിന്റെ ലംഘനമാണ്.

ലോ-ലെവൽ ഇംപ്ലിമെന്റേഷനിൽ നിന്ന് അമൂർത്തതകളെ വേർതിരിച്ച് ഡിപൻഡൻസി ഇൻവേർഷൻ തത്വത്തിന് അനുസൃതമായി നമ്മുടെ ക്ലാസുകൾ കൊണ്ടുവരാൻ നമുക്ക് ശ്രമിക്കാം:

ഇന്റർഫേസ് IPrinter (അല്ല പ്രിന്റ് (സ്‌ട്രിംഗ് ടെക്‌സ്‌റ്റ്); ) ക്ലാസ് ബുക്ക് (പബ്ലിക് സ്‌ട്രിംഗ് ടെക്‌സ്‌റ്റ് (ഗെറ്റ്; സെറ്റ്; ) പബ്ലിക് ഐപ്‌പ്രിൻറർ പ്രിന്റർ (ഗെറ്റ്; സെറ്റ്; ) പബ്ലിക് ബുക്ക് (ഇപ്രിൻറർ പ്രിന്റർ) (ഇത്. പ്രിന്റർ = പ്രിന്റർ; ) പൊതു ശൂന്യമായ പ്രിന്റ്( ) ( Printer.Print(Text); ) ക്ലാസ് കൺസോൾപ്രിന്റർ: IPrinter (പബ്ലിക് അസാധുവായ പ്രിന്റ്(സ്ട്രിംഗ് ടെക്സ്റ്റ്) ( Console.WriteLine("പ്രിന്റ് ടു കൺസോൾ"); ) ക്ലാസ് HtmlPrinter: IPrinter (പൊതു ശൂന്യമായ പ്രിന്റ് (സ്ട്രിംഗ് ടെക്സ്റ്റ്) ( Console.WriteLine("print to html"); ) )

ഇപ്പോൾ പുസ്തക പ്രിന്റിംഗ് അമൂർത്തീകരണം കോൺക്രീറ്റ് നിർവ്വഹണങ്ങളിൽ നിന്ന് വേർതിരിച്ചിരിക്കുന്നു. തൽഫലമായി, ബുക്ക് ക്ലാസും കൺസോൾ പ്രിന്റർ ക്ലാസും IPrinter സംഗ്രഹത്തെ ആശ്രയിച്ചിരിക്കുന്നു. കൂടാതെ, ഇപ്പോൾ നമുക്ക് IPprinter അബ്‌സ്‌ട്രാക്ഷന്റെ അധിക ലോ-ലെവൽ നിർവ്വഹണങ്ങൾ സൃഷ്ടിക്കാനും പ്രോഗ്രാമിൽ ചലനാത്മകമായി പ്രയോഗിക്കാനും കഴിയും:

പുസ്തക പുസ്തകം = പുതിയ പുസ്തകം(പുതിയ കൺസോൾ പ്രിന്റർ()); book.Print(); book.Printer = പുതിയ HtmlPrinter(); book.Print();

ഡിപൻഡൻസി ഇൻവേർഷൻ ഏറ്റവും പ്രധാനപ്പെട്ട പ്രോഗ്രാമിംഗ് ഐഡിയം ആണ്. റഷ്യൻ ഭാഷാ ഇൻറർനെറ്റിൽ ഈ ഐഡിയത്തിന്റെ (തത്ത്വത്തിന്റെ) കുറച്ച് വിവരണങ്ങൾ ഉണ്ട്. അതിനാൽ ഒരു വിവരണം നടത്താൻ ഞാൻ തീരുമാനിച്ചു. ഏത് പ്രോഗ്രാമിംഗ് ഭാഷയ്ക്കും ആശ്രിതത്വ വിപരീത തത്വം ബാധകമാണെങ്കിലും, ജാവയിൽ ഞാൻ ഉദാഹരണങ്ങൾ ചെയ്യും, ഇപ്പോൾ ഇത് എനിക്ക് എളുപ്പമാണ്.

ജാവ വിദ്യാർത്ഥികളുമായുള്ള ക്ലാസുകൾക്കുള്ള തയ്യാറെടുപ്പിനായി ഈ വിവരണം വ്‌ളാഡിമിർ മാറ്റ്വീവുമായി സംയുക്തമായി വികസിപ്പിച്ചെടുത്തു.

ഈ പരമ്പരയിലെ മറ്റ് ലേഖനങ്ങൾ:

"ആശ്രിതത്വം" എന്നതിന്റെ നിർവചനത്തിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം. എന്താണ് ആസക്തി? നിങ്ങളുടെ കോഡ് ചില ക്ലാസ് ആന്തരികമായി ഉപയോഗിക്കുകയാണെങ്കിൽ അല്ലെങ്കിൽ ചില ക്ലാസിന്റെ അല്ലെങ്കിൽ ഫംഗ്‌ഷന്റെ സ്റ്റാറ്റിക് രീതിയെ സ്‌പഷ്‌ടമായി വിളിക്കുന്നുവെങ്കിൽ, ഇതൊരു ആശ്രിതത്വമാണ്. ഞാൻ ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് വിശദീകരിക്കാം:

ചില മെത്തേഡ്() എന്ന ഒരു മെത്തേഡിനുള്ളിൽ എ ക്ലാസ്സിന് താഴെ, ക്ലാസ്സ് ബി യുടെ ഒരു ഒബ്ജക്റ്റ് വ്യക്തമായി സൃഷ്ടിക്കുകയും അതിന്റെ മെത്തേഡ് ചില മെത്തേഡ്ഓഫ്ബി() ആക്സസ് ചെയ്യുകയും ചെയ്യുന്നു.

പൊതു ക്ലാസ് A (അസാധുവായ ചില രീതി() (B b = പുതിയ B(); b.someMethodOfB(); )

അതുപോലെ, ഉദാഹരണത്തിന്, ക്ലാസ് B എന്നത് സിസ്റ്റം ക്ലാസിന്റെ സ്റ്റാറ്റിക് ഫീൽഡുകളെയും രീതികളെയും വ്യക്തമായി സൂചിപ്പിക്കുന്നു:

പൊതു ക്ലാസ് ബി (അസാധുവായ someMethodOfB() ( System.out.println("Hello world"); ) )

ഏതെങ്കിലും ക്ലാസ് (ടൈപ്പ് എ) തന്നെ ഏതെങ്കിലും ക്ലാസ് (ടൈപ്പ് ബി) സൃഷ്ടിക്കുകയോ അല്ലെങ്കിൽ സ്റ്റാറ്റിക് ഫീൽഡുകളോ ക്ലാസ് അംഗങ്ങളോ വ്യക്തമായി ആക്സസ് ചെയ്യുന്നതോ ആയ എല്ലാ സാഹചര്യങ്ങളിലും, ഇതിനെ വിളിക്കുന്നു ഋജുവായത്ആസക്തി. ആ. പ്രധാനം: അതിനുള്ളിലെ ഒരു ക്ലാസ് മറ്റൊരു ക്ലാസുമായി സ്വയം പ്രവർത്തിക്കുന്നുവെങ്കിൽ, ഇതൊരു ആശ്രിതത്വമാണ്. അവനും ഉള്ളിൽ ഈ ക്ലാസ് സൃഷ്ടിക്കുകയാണെങ്കിൽ, ഇത് ഋജുവായത്ആസക്തി.

നേരിട്ടുള്ള ആശ്രയത്വങ്ങളിൽ എന്താണ് തെറ്റ്? നേരിട്ടുള്ള ആശ്രിതത്വങ്ങൾ മോശമാണ്, കാരണം സ്വതന്ത്രമായി മറ്റൊരു ക്ലാസ് സൃഷ്ടിക്കുന്ന ഒരു ക്ലാസ് ഈ ക്ലാസുമായി "ഇറുകിയതായി" ബന്ധപ്പെട്ടിരിക്കുന്നു. ആ. B = new B() എന്ന് വ്യക്തമായി എഴുതിയിട്ടുണ്ടെങ്കിൽ; , അപ്പോൾ ക്ലാസ് എ എല്ലായ്‌പ്പോഴും ബി ക്ലാസിനൊപ്പം പ്രവർത്തിക്കും, മറ്റ് ക്ലാസുകളൊന്നുമില്ല. അല്ലെങ്കിൽ System.out.println("...") എന്ന് പറഞ്ഞാൽ; അപ്പോൾ ക്ലാസ് എല്ലായ്‌പ്പോഴും System.out-ലേക്ക് ഔട്ട്‌പുട്ട് ചെയ്യും, മറ്റെവിടെയുമില്ല.

ചെറിയ ക്ലാസുകൾക്ക്, ആശ്രിതത്വം ഭയാനകമല്ല. അത്തരം കോഡ് നന്നായി പ്രവർത്തിച്ചേക്കാം. എന്നാൽ ചില സന്ദർഭങ്ങളിൽ, നിങ്ങളുടെ ക്ലാസ് എ വ്യത്യസ്ത ക്ലാസുകളുടെ പരിതസ്ഥിതിയിൽ സാർവത്രികമായി പ്രവർത്തിക്കുന്നതിന്, അതിന് ക്ലാസുകളുടെ മറ്റ് നിർവ്വഹണങ്ങൾ ആവശ്യമായി വന്നേക്കാം - ഡിപൻഡൻസികൾ. ആ. നിങ്ങൾക്ക് ആവശ്യമാണ്, ഉദാഹരണത്തിന്, ക്ലാസ് ബി അല്ല, അതേ ഇന്റർഫേസുള്ള മറ്റൊരു ക്ലാസ്, അല്ലെങ്കിൽ System.out അല്ല, പക്ഷേ, ഉദാഹരണത്തിന്, ഒരു ലോഗറിലേക്ക് ഔട്ട്പുട്ട് ചെയ്യുക (ഉദാഹരണത്തിന്, log4j).

നേരിട്ടുള്ള ആശ്രിതത്വം ഇതുപോലെ ഗ്രാഫിക്കായി പ്രദർശിപ്പിക്കാം:

ആ. നിങ്ങളുടെ കോഡിൽ ക്ലാസ് എ സൃഷ്ടിക്കുമ്പോൾ: A a = പുതിയ A(); വാസ്തവത്തിൽ, ഒരു ക്ലാസ് എ സൃഷ്ടിക്കപ്പെട്ടിട്ടില്ല, മറിച്ച് ആശ്രിത ക്ലാസുകളുടെ ഒരു മുഴുവൻ ശ്രേണിയാണ്, അതിന്റെ ഉദാഹരണം മുകളിലുള്ള ചിത്രത്തിൽ ഉണ്ട്. ഈ ശ്രേണി "കർക്കശമാണ്": വ്യക്തിഗത ക്ലാസുകളുടെ സോഴ്സ് കോഡ് മാറ്റാതെ, ശ്രേണിയിലെ ക്ലാസുകളൊന്നും മാറ്റിസ്ഥാപിക്കാൻ കഴിയില്ല. അതിനാൽ, അത്തരമൊരു നടപ്പാക്കലിലെ ക്ലാസ് എ മാറുന്ന പരിതസ്ഥിതിക്ക് മോശമായി പൊരുത്തപ്പെടുന്നില്ല. മിക്കവാറും, നിങ്ങൾ ഇത് എഴുതിയ നിർദ്ദിഷ്ട കോഡിൽ ഒഴികെ ഒരു കോഡിലും ഇത് ഉപയോഗിക്കാൻ കഴിയില്ല.

നിർദ്ദിഷ്‌ട ഡിപൻഡൻസികളിൽ നിന്ന് ക്ലാസ് എ ഡീകൂപ്പിൾ ചെയ്യാൻ, അപേക്ഷിക്കുക ആശ്രിതത്വ കുത്തിവയ്പ്പ്. എന്താണ് ഡിപൻഡൻസി ഇഞ്ചക്ഷൻ? കോഡിൽ ആവശ്യമുള്ള ക്ലാസ് വ്യക്തമായി സൃഷ്ടിക്കുന്നതിനുപകരം, കൺസ്ട്രക്റ്റർ വഴി ഡിപൻഡൻസികൾ ക്ലാസ് എയിലേക്ക് കൈമാറുന്നു:

പബ്ലിക് ക്ലാസ് എ (പ്രൈവറ്റ് ഫൈനൽ ബി ബി; പബ്ലിക് എ(ബി ബി) (ഇത്.ബി = ബി; ) പൊതു അസാധുവായ ചില രീതി() (ബി.സൗമെമെത്തോഫ്ബി(); ) )

അത്. ക്ലാസ് എ ഇപ്പോൾ കൺസ്ട്രക്റ്റർ വഴി അതിന്റെ ആശ്രിതത്വം നേടുന്നു. ഇപ്പോൾ, ക്ലാസ് എ സൃഷ്ടിക്കുന്നതിന്, നിങ്ങൾ ആദ്യം അതിന്റെ ആശ്രിത ക്ലാസ് സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഈ സാഹചര്യത്തിൽ, ഇത് ബി:

B b = പുതിയ B(); A a = പുതിയ A(b); a.someMethod();

എല്ലാ ക്ലാസുകൾക്കും ഒരേ നടപടിക്രമം ആവർത്തിക്കുകയാണെങ്കിൽ, അതായത്. ക്ലാസ് D യുടെ ഒരു ഉദാഹരണം ക്ലാസ് B യുടെ കൺസ്‌ട്രക്‌റ്ററിലേക്കും, ക്ലാസ് D യുടെ കൺസ്‌ട്രക്‌റ്ററിലേക്കും - അതിന്റെ ഡിപൻഡൻസികൾ E, F മുതലായവയ്ക്ക് കൈമാറുക, അപ്പോൾ നിങ്ങൾക്ക് കോഡ് ലഭിക്കും, അവയുടെ എല്ലാ ഡിപൻഡൻസികളും വിപരീത ക്രമത്തിൽ സൃഷ്‌ടിക്കപ്പെട്ടിരിക്കുന്നു:

G g = പുതിയ G(); H h = പുതിയ H(); F f = പുതിയത് (g,h); E e = പുതിയ E(); D d = പുതിയ D(e,f); B b = പുതിയ B(d); A a = പുതിയ A(b); a.someMethod();

ഗ്രാഫിക്കലായി, ഇത് ഇതുപോലെ പ്രദർശിപ്പിക്കാം:

നിങ്ങൾ 2 ചിത്രങ്ങൾ താരതമ്യം ചെയ്താൽ - മുകളിലെ ചിത്രം നേരിട്ടുള്ള ഡിപൻഡൻസികളും രണ്ടാമത്തെ ചിത്രം ഡിപൻഡൻസി കുത്തിവയ്പ്പും ഉപയോഗിച്ച് - അമ്പടയാളങ്ങളുടെ ദിശ വിപരീതമായി മാറിയതായി നിങ്ങൾക്ക് കാണാൻ കഴിയും. ഇക്കാരണത്താൽ, പദപ്രയോഗത്തെ "ആശ്രിതത്വ വിപരീതം" എന്ന് വിളിക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ക്ലാസ് സ്വന്തമായി ഡിപൻഡൻസികൾ സൃഷ്ടിക്കുന്നില്ല, മറിച്ച് കൺസ്ട്രക്റ്ററിൽ (അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും) സൃഷ്ടിച്ച രൂപത്തിൽ അവ സ്വീകരിക്കുന്നു എന്ന വസ്തുതയിലാണ് ഡിപൻഡൻസി വിപരീതം.

എന്തുകൊണ്ട് ആശ്രിതത്വ വിപരീതം നല്ലതാണ്? ഡിപൻഡൻസി ഇൻവേർഷൻ ഉപയോഗിച്ച്, ഒരു ക്ലാസിലെ എല്ലാ ഡിപൻഡൻസികളും അതിന്റെ കോഡ് മാറ്റാതെ തന്നെ നിങ്ങൾക്ക് മാറ്റിസ്ഥാപിക്കാം. ഇതിനർത്ഥം നിങ്ങളുടെ ക്ലാസ് എ ആദ്യം എഴുതിയതിനേക്കാൾ മറ്റൊരു പ്രോഗ്രാമിൽ ഉപയോഗിക്കുന്നതിന് ഫ്ലെക്സിബിൾ ആയി കോൺഫിഗർ ചെയ്യാമെന്നാണ്. അത്. ഫ്ലെക്സിബിൾ, മോഡുലാർ, പുനരുപയോഗിക്കാവുന്ന കോഡ് നിർമ്മിക്കുന്നതിന് ഡിപൻഡൻസി ഇൻവേർഷന്റെ തത്വം (ചിലപ്പോൾ ഡിപൻഡൻസി ഇൻജക്ഷൻ തത്വം എന്ന് വിളിക്കുന്നു) പ്രധാനമാണ്.

ഡിപൻഡൻസി കുത്തിവയ്പ്പിന്റെ പോരായ്മയും ഒറ്റനോട്ടത്തിൽ ദൃശ്യമാണ് - ഈ പാറ്റേൺ ഉപയോഗിച്ച് രൂപകൽപ്പന ചെയ്ത ക്ലാസുകളുടെ വസ്തുക്കൾ നിർമ്മിക്കുന്നത് ശ്രമകരമാണ്. അതിനാൽ, ഡിപൻഡൻസി ഇഞ്ചക്ഷൻ (ഇൻവേർഷൻ) സാധാരണയായി ഈ ടാസ്ക്ക് സുഗമമാക്കുന്നതിന് രൂപകൽപ്പന ചെയ്തിട്ടുള്ള ചില ലൈബ്രറികൾക്കൊപ്പം ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, Google Guice ലൈബ്രറികളിൽ ഒന്ന്. സെമി. .