സോളിഡ് തത്വങ്ങളെക്കുറിച്ച് കേട്ടിട്ടില്ലാത്ത ഡെവലപ്പർമാരെ ഞാൻ പലപ്പോഴും കണ്ടുമുട്ടാറുണ്ട് (ഞങ്ങൾ . — Transl.) അല്ലെങ്കിൽ ഒബ്ജക്റ്റ്-ഓറിയന്റഡ് പ്രോഗ്രാമിംഗ് (OOP), അല്ലെങ്കിൽ അവയെക്കുറിച്ച് കേട്ടിട്ടുണ്ട്, എന്നാൽ പ്രായോഗികമായി അവ ഉപയോഗിക്കരുത്. ഡെവലപ്പറെ അവന്റെ ദൈനംദിന ജോലിയിൽ സഹായിക്കുന്ന OOP തത്വങ്ങളുടെ പ്രയോജനങ്ങൾ ഈ ലേഖനം വിവരിക്കുന്നു. അവയിൽ ചിലത് നന്നായി അറിയാം, മറ്റുള്ളവർ അത്രയൊന്നും അല്ല, അതിനാൽ ലേഖനം തുടക്കക്കാർക്കും പരിചയസമ്പന്നരായ പ്രോഗ്രാമർമാർക്കും ഉപയോഗപ്രദമാകും.
ഞങ്ങൾ ഓർമ്മിപ്പിക്കുന്നു: എല്ലാ Habr വായനക്കാർക്കും - Habr പ്രൊമോഷണൽ കോഡ് ഉപയോഗിച്ച് ഏതെങ്കിലും സ്കിൽബോക്സ് കോഴ്സിൽ ചേരുമ്പോൾ 10 റൂബിൾ കിഴിവ്.
സ്കിൽബോക്സ് ശുപാർശ ചെയ്യുന്നു: വിദ്യാഭ്യാസ ഓൺലൈൻ കോഴ്സ് .
ഡ്രൈ (സ്വയം ആവർത്തിക്കരുത്)
വളരെ ലളിതമായ ഒരു തത്വം, അതിന്റെ സാരാംശം പേരിൽ നിന്ന് വ്യക്തമാണ്: "സ്വയം ആവർത്തിക്കരുത്." ഒരു പ്രോഗ്രാമറെ സംബന്ധിച്ചിടത്തോളം, ഡ്യൂപ്ലിക്കേറ്റ് കോഡ് ഒഴിവാക്കേണ്ടതിന്റെ ആവശ്യകതയും അവരുടെ ജോലിയിൽ അമൂർത്തീകരണം ഉപയോഗിക്കാനുള്ള അവസരവും ഇതിനർത്ഥം.
കോഡിൽ രണ്ട് ആവർത്തിക്കുന്ന വിഭാഗങ്ങൾ ഉണ്ടെങ്കിൽ, അവ ഒരു രീതിയിലേക്ക് കൂട്ടിച്ചേർക്കണം. ഒരു ഹാർഡ്കോഡ് മൂല്യം ഒന്നിലധികം തവണ ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ, അത് ഒരു പൊതു സ്ഥിരാങ്കത്തിലേക്ക് പരിവർത്തനം ചെയ്യുന്നത് മൂല്യവത്താണ്.
കോഡ് ലളിതമാക്കുന്നതിനും പരിപാലിക്കുന്നത് എളുപ്പമാക്കുന്നതിനും ഇത് ആവശ്യമാണ്, ഇത് OOP യുടെ പ്രധാന ലക്ഷ്യമാണ്. ഒരേ കോഡ് OrderId ഉം SSN ഉം ഉപയോഗിച്ച് പരിശോധിച്ചുറപ്പിക്കാത്തതിനാൽ നിങ്ങൾ യൂണിയൻ അമിതമായി ഉപയോഗിക്കരുത്.
എൻക്യാപ്സുലേറ്റിംഗ് മാറ്റങ്ങൾ
മിക്ക കമ്പനികളുടെയും സോഫ്റ്റ്വെയർ ഉൽപ്പന്നങ്ങൾ നിരന്തരം വികസിച്ചുകൊണ്ടിരിക്കുന്നു. ഇതിനർത്ഥം കോഡിൽ മാറ്റങ്ങൾ വരുത്തേണ്ടതുണ്ട്, അത് പിന്തുണയ്ക്കേണ്ടതുണ്ട്. എൻക്യാപ്‌സുലേഷൻ ഉപയോഗിച്ച് നിങ്ങളുടെ ജീവിതം എളുപ്പമാക്കാം. നിങ്ങളുടെ നിലവിലുള്ള കോഡ് ബേസ് കൂടുതൽ കാര്യക്ഷമമായി പരിശോധിക്കാനും പരിപാലിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കും. .
നിങ്ങൾ ജാവയിൽ എഴുതുകയാണെങ്കിൽ, പിന്നെ .
തുറന്ന/അടഞ്ഞ തത്വം
ഇനിപ്പറയുന്ന പ്രസ്താവന വായിച്ചുകൊണ്ട് ഈ തത്ത്വം എളുപ്പത്തിൽ ഓർമ്മിക്കാൻ കഴിയും: "സോഫ്റ്റ്വെയർ എന്റിറ്റികൾ (ക്ലാസുകൾ, മൊഡ്യൂളുകൾ, ഫംഗ്ഷനുകൾ മുതലായവ) വിപുലീകരണത്തിനായി തുറന്നിരിക്കണം, പക്ഷേ പരിഷ്‌ക്കരിക്കുന്നതിന് അടച്ചിരിക്കണം." പ്രായോഗികമായി, സോഴ്സ് കോഡ് മാറ്റാതെ തന്നെ അവരുടെ സ്വഭാവം മാറ്റാൻ അനുവദിക്കാമെന്നാണ് ഇതിനർത്ഥം.
സോഴ്സ് കോഡിലെ മാറ്റങ്ങൾക്ക് കോഡ് റിവിഷൻ, യൂണിറ്റ് ടെസ്റ്റിംഗ്, മറ്റ് നടപടിക്രമങ്ങൾ എന്നിവ ആവശ്യമായി വരുമ്പോൾ തത്വം പ്രധാനമാണ്. ഓപ്പൺ/ക്ലോസ്ഡ് തത്വം പിന്തുടരുന്ന കോഡ് വിപുലീകരിക്കുമ്പോൾ മാറില്ല, അതിനാൽ അതിൽ വളരെ കുറച്ച് പ്രശ്നങ്ങൾ മാത്രമേ ഉണ്ടാകൂ.
ഈ തത്വം ലംഘിക്കുന്ന കോഡിന്റെ ഒരു ഉദാഹരണം ഇതാ.
നിങ്ങൾക്ക് അതിൽ എന്തെങ്കിലും മാറ്റണമെങ്കിൽ, അത് വളരെയധികം സമയമെടുക്കും, കാരണം ആവശ്യമുള്ള ശകലവുമായി ബന്ധമുള്ള കോഡിന്റെ എല്ലാ വിഭാഗങ്ങളും മാറ്റേണ്ടതുണ്ട്.
വഴിയിൽ, ഓപ്പൺനെസ്സ്-ക്ലോസ്ഡ്നെസ് എന്നത് SOLID ന്റെ തത്വങ്ങളിൽ ഒന്നാണ്.
ഏക ഉത്തരവാദിത്ത തത്വം (എസ്ആർപി)
SOLID സെറ്റിൽ നിന്നുള്ള മറ്റൊരു തത്വം. "ക്ലാസ് മാറ്റത്തിന് ഒരു കാരണമേ ഉള്ളൂ" എന്ന് അത് പ്രസ്താവിക്കുന്നു. ക്ലാസ് ഒരു പ്രശ്നം മാത്രം പരിഹരിക്കുന്നു. ഇതിന് നിരവധി രീതികൾ ഉണ്ടായിരിക്കാം, എന്നാൽ അവയിൽ ഓരോന്നും ഒരു സാധാരണ പ്രശ്നം പരിഹരിക്കാൻ മാത്രമാണ് ഉപയോഗിക്കുന്നത്. എല്ലാ രീതികളും ഗുണങ്ങളും ഇത് മാത്രമേ നൽകൂ.
ഈ തത്വത്തിന്റെ മൂല്യം അത് വ്യക്തിഗത സോഫ്റ്റ്വെയർ ഘടകവും കോഡും തമ്മിലുള്ള ബന്ധത്തെ അഴിച്ചുവിടുന്നു എന്നതാണ്. നിങ്ങൾ ഒരു ക്ലാസിലേക്ക് ഒന്നിലധികം ഫംഗ്‌ഷണാലിറ്റികൾ ചേർക്കുകയാണെങ്കിൽ, അത് രണ്ട് ഫംഗ്ഷനുകൾ തമ്മിലുള്ള ബന്ധം അവതരിപ്പിക്കുന്നു. അതിനാൽ, നിങ്ങൾ അവയിലൊന്ന് മാറ്റുകയാണെങ്കിൽ, ആദ്യത്തേതുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന രണ്ടാമത്തേത് നശിപ്പിക്കാനുള്ള ഉയർന്ന സാധ്യതയുണ്ട്. എല്ലാ പ്രശ്നങ്ങളും മുൻകൂട്ടി തിരിച്ചറിയുന്നതിനായി ടെസ്റ്റിംഗ് സൈക്കിളുകൾ വർദ്ധിപ്പിക്കുക എന്നാണ് ഇതിനർത്ഥം.
ആശ്രിതത്വ വിപരീത തത്വം (ഡിഐപി)
AppManager EventLogWriter-നെ ആശ്രയിക്കുന്ന ഒരു കോഡ് ഉദാഹരണമാണ് മുകളിൽ നൽകിയിരിക്കുന്നത്, അത് AppManager-മായി അടുത്ത് ബന്ധപ്പെട്ടിരിക്കുന്നു. ഒരു അറിയിപ്പ് കാണിക്കാൻ നിങ്ങൾക്ക് മറ്റൊരു മാർഗം ആവശ്യമുണ്ടെങ്കിൽ, അത് പുഷ്, SMS അല്ലെങ്കിൽ ഇമെയിൽ ആകട്ടെ, നിങ്ങൾ AppManager ക്ലാസ് മാറ്റേണ്ടതുണ്ട്.
ഡിഐപി ഉപയോഗിച്ച് പ്രശ്നം പരിഹരിക്കാൻ കഴിയും. അതിനാൽ, AppManager-ന് പകരം, ഞങ്ങൾ ഒരു EventLogWriter അഭ്യർത്ഥിക്കുന്നു, അത് ഫ്രെയിംവർക്ക് ഉപയോഗിച്ച് നൽകും.
ഡിപൻഡൻസി മൊഡ്യൂൾ മാറ്റുന്നതിലൂടെ വ്യക്തിഗത മൊഡ്യൂളുകൾ മറ്റുള്ളവരുമായി എളുപ്പത്തിൽ മാറ്റിസ്ഥാപിക്കുന്നത് DIP സാധ്യമാക്കുന്നു. ഒരു മൊഡ്യൂളിനെ മറ്റുള്ളവരെ ബാധിക്കാതെ മാറ്റുന്നത് ഇത് സാധ്യമാക്കുന്നു.
അനന്തരാവകാശത്തിനു പകരം രചന
കോഡ് പുനരുപയോഗിക്കുന്നതിന് രണ്ട് പ്രധാന വഴികളുണ്ട്: പാരമ്പര്യവും ഘടനയും, ഇവ രണ്ടിനും അതിന്റേതായ ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്. സാധാരണയായി രണ്ടാമത്തേത് കൂടുതൽ വഴങ്ങുന്നതിനാൽ മുൻഗണന നൽകുന്നു.
ഒരു ക്ലാസിന്റെ ഗുണവിശേഷതകൾ സജ്ജീകരിച്ച് റൺടൈമിൽ അതിന്റെ സ്വഭാവം മാറ്റാനുള്ള കഴിവ് കോമ്പോസിഷൻ നൽകുന്നു. ഇന്റർഫേസുകൾ നടപ്പിലാക്കുമ്പോൾ, പോളിമോർഫിസം ഉപയോഗിക്കുന്നു, ഇത് കൂടുതൽ വഴക്കമുള്ള നടപ്പാക്കൽ നൽകുന്നു.
ജോഷ്വ ബ്ലോച്ചിന്റെ എഫക്റ്റീവ് ജാവ പോലും പാരമ്പര്യത്തേക്കാൾ കോമ്പോസിഷൻ തിരഞ്ഞെടുക്കാൻ ഉപദേശിക്കുന്നു.
ബാർബറ ലിസ്കോവ് സബ്സ്റ്റിറ്റ്യൂഷൻ തത്വം (LSP)
SOLID ടൂൾകിറ്റിൽ നിന്നുള്ള മറ്റൊരു തത്വം. ഉപവിഭാഗങ്ങൾ സൂപ്പർ ടൈപ്പിന് പകരം വയ്ക്കണമെന്ന് അത് പ്രസ്താവിക്കുന്നു. അതായത്, ഒരു സൂപ്പർക്ലാസ്സിനൊപ്പം പ്രവർത്തിക്കുന്ന രീതികളും പ്രവർത്തനങ്ങളും അതിന്റെ സബ്ക്ലാസ്സുകളിൽ പ്രശ്നങ്ങളില്ലാതെ പ്രവർത്തിക്കാൻ കഴിയണം.
എൽഎസ്പി ഒറ്റ ഉത്തരവാദിത്ത തത്വവും പങ്കിട്ട ഉത്തരവാദിത്ത തത്വവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഒരു ക്ലാസ് ഒരു സബ്ക്ലാസിനേക്കാൾ കൂടുതൽ പ്രവർത്തനക്ഷമത നൽകുന്നുവെങ്കിൽ, രണ്ടാമത്തേത് ഈ തത്വം ലംഘിക്കുന്ന ചില പ്രവർത്തനങ്ങളെ പിന്തുണയ്ക്കില്ല.
എൽഎസ്പിക്ക് വിരുദ്ധമായ ഒരു കോഡ് ഇവിടെയുണ്ട്.
ഏരിയ (ദീർഘചതുരം r) രീതി ഒരു ദീർഘചതുരത്തിന്റെ വിസ്തീർണ്ണം കണക്കാക്കുന്നു. ചതുരം ഇവിടെ ഒരു ദീർഘചതുരം അല്ലാത്തതിനാൽ സ്ക്വയർ എക്സിക്യൂട്ട് ചെയ്ത ശേഷം പ്രോഗ്രാം ക്രാഷ് ആകും. എൽഎസ്പി തത്വമനുസരിച്ച്, അടിസ്ഥാന ക്ലാസുകളിലേക്ക് റഫറൻസുകൾ ഉപയോഗിക്കുന്ന ഫംഗ്ഷനുകൾക്ക് അധിക നിർദ്ദേശങ്ങളില്ലാതെ ഡിറൈവ്ഡ് ക്ലാസുകളുടെ ഒബ്ജക്റ്റുകൾ ഉപയോഗിക്കാൻ കഴിയണം.
ഒരു സബ്‌ടൈപ്പിന്റെ ഒരു പ്രത്യേക നിർവചനമായ ഈ തത്വം, 1987 ലെ "ഡാറ്റ അബ്‌സ്‌ട്രാക്‌ഷനും ശ്രേണിയും" എന്ന തലക്കെട്ടിൽ ബാർബറ ലിസ്കോവ് ഒരു കോൺഫറൻസ് കീനോട്ടിൽ നിർദ്ദേശിച്ചു, അതിനാൽ അതിന്റെ പേര്.
ഇന്റർഫേസ് സ്പ്ലിറ്റ് പ്രിൻസിപ്പിൾ (ISP)
മറ്റൊരു സോളിഡ് തത്വം. അതനുസരിച്ച്, ഉപയോഗിക്കാത്ത ഒരു ഇന്റർഫേസ് നടപ്പിലാക്കാൻ പാടില്ല. ഈ തത്വം പിന്തുടരുന്നത്, ഓപ്പറേറ്റിംഗ് ലോജിക്കിൽ മാറ്റങ്ങൾ വരുത്തുമ്പോൾ, സിസ്റ്റത്തെ അയവുള്ളതും റീഫാക്റ്ററിങ്ങിന് അനുയോജ്യവുമായി നിലനിർത്താൻ സഹായിക്കുന്നു.
മിക്കപ്പോഴും, ഇന്റർഫേസിൽ ഒരേസമയം നിരവധി ഫംഗ്ഷനുകൾ അടങ്ങിയിരിക്കുമ്പോൾ ഈ സാഹചര്യം സംഭവിക്കുന്നു, കൂടാതെ ക്ലയന്റിന് അവയിലൊന്ന് മാത്രമേ ആവശ്യമുള്ളൂ.
ഒരു ഇന്റർഫേസ് എഴുതുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമായതിനാൽ, ഒന്നും തകർക്കാതെ ജോലി പൂർത്തിയാക്കിയ ശേഷം അത് മാറ്റുന്നത് ഒരു വെല്ലുവിളിയാണ്.
ജാവയിലെ ISP തത്വത്തിന്റെ പ്രയോജനം എല്ലാ രീതികളും ആദ്യം നടപ്പിലാക്കണം എന്നതാണ്, അതിനുശേഷം മാത്രമേ അവ ക്ലാസുകൾക്ക് ഉപയോഗിക്കാൻ കഴിയൂ. അതിനാൽ, രീതികളുടെ എണ്ണം കുറയ്ക്കാൻ തത്വം സാധ്യമാക്കുന്നു.
ഇന്റർഫേസിനായുള്ള പ്രോഗ്രാമിംഗ്, നടപ്പാക്കലല്ല
ഇവിടെ എല്ലാം പേരിൽ നിന്ന് വ്യക്തമാണ്. ഈ തത്ത്വം പ്രയോഗിക്കുന്നത് ഇന്റർഫേസിന്റെ ഏത് പുതിയ നിർവ്വഹണത്തിലും പ്രവർത്തിക്കാൻ കഴിയുന്ന ഫ്ലെക്സിബിൾ കോഡ് സൃഷ്ടിക്കുന്നതിലേക്ക് നയിക്കുന്നു.
വേരിയബിളുകൾക്കും റിട്ടേൺ തരങ്ങൾക്കും അല്ലെങ്കിൽ രീതി ആർഗ്യുമെന്റ് തരത്തിനും നിങ്ങൾ ഇന്റർഫേസ് തരം ഉപയോഗിക്കണം. സബ്ക്ലാസ്സിനുപകരം സൂപ്പർക്ലാസ് ഉപയോഗിക്കുന്നതാണ് ഒരു ഉദാഹരണം.
അതാണ്:
ലിസ്റ്റ് നമ്പറുകൾ= getNumbers();
എന്നാൽ അല്ല:
അറേ ലിസ്റ്റ് നമ്പറുകൾ = getNumbers();
മുകളിൽ ചർച്ച ചെയ്ത കാര്യങ്ങളുടെ പ്രായോഗിക നിർവ്വഹണം ഇവിടെയുണ്ട്.
പ്രതിനിധി സംഘത്തിന്റെ തത്വം
ജാവയിലെ സമം(), ഹാഷ്‌കോഡ്() രീതികളാണ് ഒരു പൊതു ഉദാഹരണം. രണ്ട് ഒബ്ജക്റ്റുകൾ താരതമ്യം ചെയ്യേണ്ടത് ആവശ്യമായി വരുമ്പോൾ, ക്ലയന്റ് ഒന്നിന് പകരം ഈ പ്രവർത്തനം അനുബന്ധ ക്ലാസിലേക്ക് നിയോഗിക്കപ്പെടുന്നു.
കോഡിന്റെ തനിപ്പകർപ്പ് ഇല്ല, സ്വഭാവം മാറ്റുന്നത് താരതമ്യേന ലളിതമാണ് എന്നതാണ് തത്വത്തിന്റെ പ്രയോജനം. ഇവന്റ് ഡെലിഗേഷനും ഇത് ബാധകമാണ്.
ഈ തത്ത്വങ്ങളെല്ലാം ഉയർന്ന സംയോജനവും കുറഞ്ഞ കപ്ലിംഗും ഉപയോഗിച്ച് കൂടുതൽ വഴക്കമുള്ളതും മനോഹരവും വിശ്വസനീയവുമായ കോഡ് എഴുതാൻ നിങ്ങളെ അനുവദിക്കുന്നു. തീർച്ചയായും, സിദ്ധാന്തം നല്ലതാണ്, എന്നാൽ ഒരു ഡെവലപ്പർക്ക് യഥാർത്ഥത്തിൽ നേടിയ അറിവ് ഉപയോഗിക്കുന്നതിന്, പരിശീലനം ആവശ്യമാണ്. നിങ്ങൾ OOP തത്ത്വങ്ങൾ പഠിച്ചുകഴിഞ്ഞാൽ, നിങ്ങളുടെ അടുത്ത ഘട്ടം പൊതുവായ സോഫ്റ്റ്വെയർ വികസന പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഡിസൈൻ പാറ്റേണുകൾ പഠിക്കുക എന്നതായിരിക്കാം.
സ്കിൽബോക്സ് ശുപാർശ ചെയ്യുന്നു:
- പ്രായോഗിക കോഴ്സ് .
- ഓൺലൈൻ കോഴ്സിന് അപേക്ഷിച്ചു .
- രണ്ടുവർഷത്തെ പ്രാക്ടിക്കൽ കോഴ്സ് .
അവലംബം: www.habr.com