ഒബ്ജക്റ്റ് ഓറിയന്റഡ് പ്രോഗ്രാമിംഗിന്റെ 5 തത്ത്വങ്ങൾ എന്തൊക്കെയാണെന്ന് സോളിഡ് ചെയ്യുക

ഒബ്ജക്റ്റ് ഓറിയെന്റഡ് ഡിസൈനിന്റെ (OOD അല്ലെങ്കിൽ OOP) അഞ്ച് തത്ത്വങ്ങളെ സൂചിപ്പിക്കുന്ന ചുരുക്കമാണ് SOLID. മാനേജുചെയ്യാനും പരിപാലിക്കാനും വിപുലീകരിക്കാനും എളുപ്പമുള്ള സോഫ്റ്റ്വെയർ സൃഷ്ടിക്കാൻ ഡവലപ്പർമാർക്ക് ഉപയോഗിക്കാൻ കഴിയുന്ന മാർഗ്ഗനിർദ്ദേശങ്ങളാണ് ഇവ. ഈ ആശയങ്ങൾ മനസിലാക്കുന്നത് നിങ്ങളെ ഒരു മികച്ച ഡവലപ്പർ ആക്കുകയും സോഫ്റ്റ്വെയർ മാനേജുമെന്റ് പ്രശ്നങ്ങൾ ഒഴിവാക്കാൻ സഹായിക്കുകയും ചെയ്യും. ഒരു നല്ല പ്രോഗ്രാമർ എന്നതിന്റെ അർത്ഥമെന്താണ്?

സോഫ്റ്റ്വെയർ പ്രോഗ്രാമിംഗിൽ കുറച്ച് പരിചയമുള്ള ആർക്കും മറ്റുള്ളവർ എഴുതിയ സോഫ്റ്റ്വെയർ കോഡിനെ വിഭജിക്കുന്നു, അവരുടെ കരിയർ പാതയെ അടിസ്ഥാനമാക്കി വിധിന്യായങ്ങൾ കണക്കാക്കുന്നു.

എന്റെ പ്രൊഫഷണൽ കരിയറിൽ, എനിക്ക് ധാരാളം ഡവലപ്പർമാരെ അറിയാം, ആയിരക്കണക്കിന് കോഡുകൾ ഞാൻ കണ്ടു, ഒരു ഡവലപ്പറുടെ കഴിവ് വിലയിരുത്തേണ്ടിവരുമ്പോൾ ഞാൻ പ്രധാനമായും രണ്ട് ഘടകങ്ങൾ നോക്കുന്നു:

• കോഡ് വായിക്കുന്നതിലെ ലാളിത്യം;
• കാലക്രമേണ പ്രവർത്തിക്കാനും പരിണമിക്കാനും അവരുടെ കോഡ് എത്രത്തോളം സാധ്യതയുണ്ട്.

ഭാഗ്യവശാൽ, കോഡിംഗിൽ മികച്ചരാകുന്നത് എളുപ്പമാക്കുന്ന ചില അടിസ്ഥാന കാര്യങ്ങളോ തത്വങ്ങളോ ഉണ്ട്.

SOLID എന്നതിന്റെ ചുരുക്കെഴുത്ത് സൂചിപ്പിക്കുന്നത്:
S: ഒരൊറ്റ ഉത്തരവാദിത്തത്തിന്റെ തത്വം
O: തുറന്ന അടച്ച തത്വം
L: ലിസ്‌കോവ് പകരക്കാരന്റെ തത്വം
I: ഇന്റർഫേസ് വേർതിരിക്കലിന്റെ തത്വം
D: ആശ്രിതത്വത്തിന്റെ വിപരീതത്തിന്റെ തത്വം

ആദ്യത്തെ SOLID തത്ത്വം പരിശോധിച്ചുകൊണ്ട് ആരംഭിക്കാം

ഒരൊറ്റ ഉത്തരവാദിത്ത തത്വം

ഒരു ക്ലാസിന് (അല്ലെങ്കിൽ മൊഡ്യൂളിന്) മാറ്റം വരുത്താനും പരിണമിക്കാനും ഒരു കാരണം മാത്രമേ ഉണ്ടാകൂ.

ആശയം തന്നെ വളരെ ലളിതമാണ്, എന്നാൽ ഈ ലാളിത്യം നേടാൻ നടപ്പാക്കൽ പാത വളരെ സങ്കീർണ്ണമാണ്. ഒരു ക്ലാസ് മാറ്റാൻ ഒരു കാരണം മാത്രമേ ഉണ്ടാകൂ.

പക്ഷെ എന്തിന്? 

മാറ്റാൻ ഒരു കാരണം മാത്രം ഉണ്ടായിരിക്കുന്നത് വളരെ പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

ഉദാഹരണത്തിന്, മാറ്റുന്നതിന് രണ്ട് വ്യത്യസ്ത കാരണങ്ങളുണ്ടെങ്കിൽ, രണ്ട് വ്യത്യസ്ത കാരണങ്ങളാൽ രണ്ട് വ്യത്യസ്ത ടീമുകൾക്ക് ഒരേ കോഡിൽ പ്രവർത്തിക്കാൻ കഴിയുമെന്ന് സങ്കൽപ്പിക്കാനാകും. ഓരോരുത്തർക്കും അവരുടേതായ പരിഹാരം നടപ്പിലാക്കേണ്ടിവരും, ഇത് ഒരു സമാഹരിച്ച ഭാഷയുടെ കാര്യത്തിൽ (സി ++, സി # അല്ലെങ്കിൽ ജാവ പോലുള്ളവ) മറ്റ് ടീമുകളുമായോ ആപ്ലിക്കേഷന്റെ മറ്റ് ഭാഗങ്ങളുമായോ പൊരുത്തപ്പെടാത്ത മൊഡ്യൂളുകളിലേക്ക് നയിച്ചേക്കാം.

മറ്റൊരു ഉദാഹരണം, നിങ്ങൾ ഒരു വ്യാഖ്യാന ഭാഷ ഉപയോഗിക്കുകയാണെങ്കിൽ, വ്യത്യസ്ത കാരണങ്ങളാൽ ഒരേ ക്ലാസ് അല്ലെങ്കിൽ മൊഡ്യൂൾ വീണ്ടും പരീക്ഷിക്കേണ്ടതുണ്ട്. ഗുണനിലവാര നിയന്ത്രണത്തിനായി കൂടുതൽ ജോലിയും സമയവും പരിശ്രമവും ഇതിൽ ഉൾപ്പെടുന്നു.

ഒരു ക്ലാസ് അല്ലെങ്കിൽ മൊഡ്യൂളിന് ഉണ്ടായിരിക്കേണ്ട ഒരു സവിശേഷത തിരിച്ചറിയുന്നത് ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് ഒരു ചെക്ക്‌ലിസ്റ്റ് നോക്കുന്നതിനേക്കാൾ വളരെ സങ്കീർണ്ണമാണ്. 

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

മൊഡ്യൂളുകളുടെ ചില ഉദാഹരണങ്ങളും അവയുടെ ഉപയോഗവും:

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

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

ആളുകൾ അല്ലെങ്കിൽ ഉപയോക്താക്കൾ എന്നതിലുപരി റോളുകൾ തിരിച്ചറിയുന്നത് കൂടുതൽ ന്യായമാണെന്ന് തോന്നുന്നു.

അതുകൊണ്ടു:

• സോഫ്റ്റ്വെയർ സിസ്റ്റത്തിന്റെ ഉപയോക്താവ് മാറ്റത്തിന്റെ കാരണങ്ങൾ നിർവചിക്കുന്നു;
• ഒരു പ്രത്യേക അഭിനേതാവിന്റെ, അതായത് സിസ്റ്റത്തിന്റെ ഉപയോക്താവിന്റെ ആവശ്യങ്ങൾ നിറവേറ്റുന്ന പ്രവർത്തനങ്ങളുടെ ഒരു കുടുംബമാണ് ഉത്തരവാദിത്തം;
• അഭിനേതാക്കൾ, ഉപയോക്താവിന്റെ ആവശ്യകത നിറവേറ്റുന്ന പ്രവർത്തനങ്ങളുടെ കുടുംബത്തിന് ഉപയോക്താവ് മാറ്റത്തിന്റെ ഉറവിടമായി മാറുന്നു;
• ഉപയോക്തൃ ആവശ്യങ്ങളുടെ പരിണാമം, പ്രവർത്തനത്തിന്റെ പരിണാമത്തെ നയിക്കുന്നു;

ചില ഉദാഹരണങ്ങൾ നോക്കാം

ഒരു പുസ്തകത്തിന്റെ ആശയത്തെയും അതിന്റെ പ്രവർത്തനത്തെയും ഉൾക്കൊള്ളുന്ന ഒരു പുസ്തക ക്ലാസ് നമുക്കുണ്ടെന്ന് കരുതുക.

ക്ലാസ് പുസ്തകം {

    getTitle () ഫംഗ്ഷൻ

        “ഒരു വലിയ പുസ്തകം” മടങ്ങുക;

    }

    getAuthor () ഫംഗ്ഷൻ

        മടങ്ങുക “അലസ്സാൻഡ്രോ ബാരിക്കോ”;

    }

    അടുത്ത പേജ് () ഫംഗ്ഷൻ ചെയ്യുക

        // അടുത്ത പേജ്

    }

    ഫംഗ്ഷൻ printCurrentPage () {

        എക്കോ “നിലവിലെ പേജിന്റെ ഉള്ളടക്കം”;

    }

}

ഇത് വളരെ സാധാരണ ക്ലാസാണ്. ഞങ്ങൾക്ക് ഒരു പുസ്തകമുണ്ട്, ക്ലാസിന് ഞങ്ങൾക്ക് ശീർഷകം നൽകാം, അവർക്ക് രചയിതാവിനെ നൽകാം, അവർക്ക് മുന്നോട്ട് പോകാനും കഴിയും. അവസാനമായി, നിലവിലെ പേജ് സ്ക്രീനിൽ അച്ചടിക്കാനും ഇത് പ്രാപ്തമാണ്. 

എന്നിരുന്നാലും, ഒരു ചെറിയ പ്രശ്നമുണ്ട്. 

പുസ്തക വസ്‌തുവിന്റെ നടത്തിപ്പിൽ ഏർപ്പെട്ടിരിക്കുന്ന അഭിനേതാക്കളെക്കുറിച്ച് ചിന്തിക്കുമ്പോൾ, അവർ ആരായിരിക്കും? 

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

അതിനാൽ ഞങ്ങൾക്ക് ക്ലാസുമായി വളരെ വ്യത്യസ്തമായ രണ്ട് അഭിനേതാക്കൾ ഉണ്ട്.

ചുരുക്കത്തിൽ, ഈ ക്ലാസ് ഇവ തമ്മിൽ ഇടകലർന്നിരിക്കുന്നു:

• ബിസിനസ്സ് ലോജിക്ക് 
• അവതരണം 

ഇത് ഒരു പ്രശ്‌നമാകാം, കാരണം ഇത് സിംഗിൾ ബാധ്യതാ തത്വത്തെ (SRP) ലംഘിക്കുന്നു. 

നമുക്ക് എങ്ങനെ മാറ്റാനാകും, ഒരൊറ്റ ഉത്തരവാദിത്തത്തിന്റെ തത്വത്തെ മാനിക്കാൻ ഈ കോഡ് എങ്ങനെ മെച്ചപ്പെടുത്താം?

ഇനിപ്പറയുന്ന കോഡ് പരിശോധിക്കുക:

ക്ലാസ് പുസ്തകം {

    getTitle () ഫംഗ്ഷൻ

        മടങ്ങുക “ഓഷ്യാനോ മാരെ”;

    }

    getAuthor () ഫംഗ്ഷൻ

        മടങ്ങുക “അലസ്സാൻഡ്രോ ബാരിക്കോ”;

    }

    ഫംഗ്ഷൻ ടേൺ പേജ് () {

        // അടുത്ത പേജ്

    }

    getCurrentPage () ഫംഗ്ഷൻ

        എക്കോ “നിലവിലെ പേജിന്റെ ഉള്ളടക്കം”;

    }

}

ഇന്റർഫേസ് പ്രിന്റർ {

    ഫംഗ്ഷൻ പ്രിന്റ് പേജ് ($ പേജ്);

}

ക്ലാസ് സ്റ്റാമ്പലിബ്രോ പ്രിന്റർ നടപ്പിലാക്കുന്നു {

    ഫംഗ്ഷൻ പ്രിന്റ് പേജുകൾ ($ പേജ്) {

        എക്കോ $ പേജ്;

    }

}

ക്ലാസ് HtmlPrinter പ്രിന്റർ നടപ്പിലാക്കുന്നു {

    ഫംഗ്ഷൻ പ്രിന്റ് പേജുകൾ ($ പേജ്) {

        എക്കോ ' '. $ പേജ്. ' ';

    }

}

ഈ ലളിതമായ ഉദാഹരണം ബിസിനസ്സ് ലോജിക്കിൽ നിന്ന് അവതരണത്തെ എങ്ങനെ വേർതിരിക്കാമെന്ന് കാണിക്കുന്നു, കൂടാതെ SRP- ന് അനുസൃതമായി ഇത് ഞങ്ങളുടെ പ്രോജക്റ്റിന്റെ വഴക്കത്തിൽ വലിയ നേട്ടങ്ങൾ നൽകുന്നു.

മറ്റൊരു ഉദാഹരണം നോക്കാം:

ഒരു വസ്തുവിന് അവതരണത്തിൽ നിന്ന് സ്വയം സംരക്ഷിക്കാനും വീണ്ടെടുക്കാനും കഴിയുമ്പോഴാണ് മുകളിലുള്ളതിന് സമാനമായ ഒരു ഉദാഹരണം.

ക്ലാസ് പുസ്തകം {

    getTitle () ഫംഗ്ഷൻ

        മടങ്ങുക “ഓഷ്യാനോ മാരെ”;

    }

    getAuthor () ഫംഗ്ഷൻ

        മടങ്ങുക “അലസ്സാൻഡ്രോ ബാരിക്കോ”;

    }

    ഫംഗ്ഷൻ ടേൺ പേജ് () {

        // അടുത്ത പേജ്

    }

    getCurrentPage () ഫംഗ്ഷൻ

        "നിലവിലെ പേജിന്റെ ഉള്ളടക്കം" നൽകുക;

    }

    ഫംഗ്ഷൻ സേവ് () {

        $ filename = '/ പ്രമാണങ്ങൾ /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ ഫയൽ നാമം, സീരിയലൈസ് ചെയ്യുക ($ ഇത്));

    }

}

മുമ്പത്തെപ്പോലെ, ഇവിടെയും വ്യത്യസ്ത അഭിനേതാക്കളെ തിരിച്ചറിയാൻ കഴിയും പുസ്തക മാനേജുമെന്റ് (ആയി ലൈബ്രേറിയൻ) ഇ സ്ഥിരോത്സാഹം. പേജിൽ നിന്ന് പേജിലേക്ക് പോകുന്ന വഴി മാറ്റാൻ ആഗ്രഹിക്കുമ്പോഴെല്ലാം, ഞങ്ങൾ ഈ ക്ലാസ് മാറ്റേണ്ടതുണ്ട്. മാറ്റത്തിന് നമുക്ക് നിരവധി കാരണങ്ങളുണ്ട്.

ക്ലാസ് പുസ്തകം {

    getTitle () ഫംഗ്ഷൻ

        മടങ്ങുക “ഓഷ്യാനോ മാരെ”;

    }

    getAuthor () ഫംഗ്ഷൻ

        മടങ്ങുക “അലസ്സാൻഡ്രോ ബാരിക്കോ”;

    }

    ഫംഗ്ഷൻ ടേൺ പേജ് () {

        // അടുത്ത പേജ്

    }

    getCurrentPage () ഫംഗ്ഷൻ

        "നിലവിലെ പേജിന്റെ ഉള്ളടക്കം" നൽകുക;

    }

}

ക്ലാസ് SimpleFilePersistence {

    ഫംഗ്ഷൻ സേവ് (ബുക്ക് $ ബുക്ക്) {

        $ filename = '/ പ്രമാണങ്ങൾ /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ ഫയൽ നാമം, സീരിയലൈസ് ചെയ്യുക ($ പുസ്തകം));

    }

}

പെർസിസ്റ്റൻസ് ഓപ്പറേഷൻ മറ്റൊരു ക്ലാസിലേക്ക് മാറ്റുന്നത് ഉത്തരവാദിത്തങ്ങളെ വ്യക്തമായി വേർതിരിക്കുകയും ഞങ്ങളുടെ ബുക്ക് ക്ലാസിനെ ബാധിക്കാതെ സ്ഥിരമായ രീതികൾ കൈമാറാൻ ഞങ്ങൾക്ക് സ്വാതന്ത്ര്യമുണ്ടാകും. ഉദാഹരണത്തിന്, ഒരു ഡാറ്റാബേസ് പെർസിസ്റ്റൻസ് ക്ലാസ് നടപ്പിലാക്കുന്നത് തുച്ഛമാണ്, മാത്രമല്ല പുസ്തക പ്രവർത്തനങ്ങളെ ചുറ്റിപ്പറ്റിയുള്ള ഞങ്ങളുടെ ബിസിനസ്സ് യുക്തിയും മാറില്ല.

രണ്ടാമത്തെ തത്വം വായിക്കുന്നത് തുടരുക ഓപ്പൺ / ക്ലോസ്ഡ് ->