10 ઑબ્જેક્ટ ઓરિએન્ટેડ પ્રોગ્રામિંગ સિદ્ધાંતો દરેક વિકાસકર્તાને જાણવું જોઈએ

ઘણી વાર હું એવા વિકાસકર્તાઓને મળું છું જેમણે SOLID સિદ્ધાંતો વિશે સાંભળ્યું નથી (અમે અહીં તેમના વિશે વિગતવાર વાત કરી. — અનુવાદ.) અથવા ઑબ્જેક્ટ-ઓરિએન્ટેડ પ્રોગ્રામિંગ (OOP), અથવા તેમના વિશે સાંભળ્યું છે, પરંતુ વ્યવહારમાં તેનો ઉપયોગ કરશો નહીં. આ લેખ OOP સિદ્ધાંતોના ફાયદાઓનું વર્ણન કરે છે જે વિકાસકર્તાને તેના દૈનિક કાર્યમાં મદદ કરે છે. તેમાંના કેટલાક જાણીતા છે, અન્ય એટલા બધા નથી, તેથી લેખ નવા નિશાળીયા અને અનુભવી પ્રોગ્રામરો બંને માટે ઉપયોગી થશે.

અમે યાદ કરાવીએ છીએ: Habrના તમામ વાચકો માટે - Habr પ્રમોશનલ કોડનો ઉપયોગ કરીને કોઈપણ સ્કિલબોક્સ કોર્સમાં નોંધણી કરતી વખતે 10 રુબલ ડિસ્કાઉન્ટ.

સ્કિલબોક્સ ભલામણ કરે છે: શૈક્ષણિક ઓનલાઈન કોર્સ "જાવા ડેવલપર".

સુકા (તમારી જાતને પુનરાવર્તિત કરશો નહીં)

એકદમ સરળ સિદ્ધાંત, જેનો સાર નામથી સ્પષ્ટ છે: "તમારી જાતને પુનરાવર્તન કરશો નહીં." પ્રોગ્રામર માટે, આનો અર્થ એ છે કે ડુપ્લિકેટ કોડને ટાળવાની જરૂરિયાત, તેમજ તેમના કાર્યમાં એબ્સ્ટ્રેક્શનનો ઉપયોગ કરવાની તક.

જો કોડમાં બે પુનરાવર્તિત વિભાગો હોય, તો તેઓને એક પદ્ધતિમાં જોડવા જોઈએ. જો હાર્ડકોડેડ મૂલ્યનો ઉપયોગ એક કરતા વધુ વખત કરવામાં આવે છે, તો તે તેને સાર્વજનિક સ્થિરાંકમાં રૂપાંતરિત કરવા યોગ્ય છે.

કોડને સરળ બનાવવા અને તેને જાળવવાનું સરળ બનાવવા માટે આ જરૂરી છે, જે OOP નો મુખ્ય ધ્યેય છે. તમારે યુનિયનનો વધુ પડતો ઉપયોગ પણ ન કરવો જોઈએ, કારણ કે સમાન કોડ OrderId અને SSN બંને સાથે ચકાસણી પસાર કરશે નહીં.

એન્કેપ્સ્યુલેટીંગ ફેરફારો

મોટાભાગની કંપનીઓની સોફ્ટવેર પ્રોડક્ટ્સ સતત વિકસિત થઈ રહી છે. આનો અર્થ એ છે કે કોડમાં ફેરફારો કરવાની જરૂર છે, તેને સપોર્ટ કરવાની જરૂર છે. તમે એન્કેપ્સ્યુલેશનનો ઉપયોગ કરીને તમારું જીવન સરળ બનાવી શકો છો. આ તમને તમારા હાલના કોડ બેઝને વધુ અસરકારક રીતે પરીક્ષણ અને જાળવવાની મંજૂરી આપશે. અહીં એક ઉદાહરણ છે.

જો તમે જાવામાં લખો છો, તો પછી મૂળભૂત રીતે ખાનગી પદ્ધતિઓ અને ચલો સોંપો.

ખુલ્લા/બંધ સિદ્ધાંત

નીચેના વિધાનને વાંચીને આ સિદ્ધાંત સરળતાથી યાદ રાખી શકાય છે: "સોફ્ટવેર એન્ટિટી (વર્ગો, મોડ્યુલો, કાર્યો, વગેરે) એક્સ્ટેંશન માટે ખુલ્લી હોવી જોઈએ, પરંતુ ફેરફાર માટે બંધ હોવી જોઈએ." વ્યવહારમાં, આનો અર્થ એ છે કે તેઓ સ્રોત કોડ બદલ્યા વિના તેમના વર્તનને બદલવાની મંજૂરી આપી શકે છે.

જ્યારે સ્રોત કોડમાં ફેરફાર માટે કોડ રિવિઝન, યુનિટ ટેસ્ટિંગ અને અન્ય પ્રક્રિયાઓની જરૂર પડે ત્યારે સિદ્ધાંત મહત્વપૂર્ણ છે. કોડ કે જે ઓપન/ક્લોઝ્ડ સિદ્ધાંતને અનુસરે છે જ્યારે વિસ્તૃત કરવામાં આવે ત્યારે તે બદલાતો નથી, તેથી તેની સાથે ઘણી ઓછી સમસ્યાઓ છે.

અહીં કોડનું ઉદાહરણ છે જે આ સિદ્ધાંતનું ઉલ્લંઘન કરે છે.

જો તમારે તેમાં કંઈક બદલવાની જરૂર હોય, તો તે ઘણો સમય લેશે, કારણ કે કોડના તમામ વિભાગો કે જે ઇચ્છિત ટુકડા સાથે જોડાણ ધરાવે છે તે બદલવા પડશે.

માર્ગ દ્વારા, નિખાલસતા-બંધ એ SOLID ના સિદ્ધાંતોમાંથી એક છે.

સિંગલ રિસ્પોન્સિબિલિટી પ્રિન્સિપલ (SRP)

SOLID સેટમાંથી બીજો સિદ્ધાંત. તે જણાવે છે કે "ત્યાં એક જ કારણ છે જે વર્ગમાં ફેરફારનું કારણ બને છે." વર્ગ માત્ર એક સમસ્યા હલ કરે છે. તેમાં ઘણી પદ્ધતિઓ હોઈ શકે છે, પરંતુ તેમાંથી દરેકનો ઉપયોગ ફક્ત સામાન્ય સમસ્યાને ઉકેલવા માટે થાય છે. બધી પદ્ધતિઓ અને ગુણધર્મો ફક્ત આ જ સેવા આપવી જોઈએ.

આ સિદ્ધાંતનું મૂલ્ય એ છે કે તે વ્યક્તિગત સોફ્ટવેર ઘટક અને કોડ વચ્ચેના જોડાણને ઢીલું કરે છે. જો તમે વર્ગમાં એક કરતાં વધુ કાર્યક્ષમતા ઉમેરો છો, તો તે બે કાર્યો વચ્ચેનો સંબંધ રજૂ કરે છે. આમ, જો તમે તેમાંના એકને બદલો છો, તો બીજાને બરબાદ કરવાની ઉચ્ચ સંભાવના છે, જે પ્રથમ સાથે જોડાયેલ છે. અને આનો અર્થ એ છે કે તમામ સમસ્યાઓને અગાઉથી ઓળખવા માટે પરીક્ષણ ચક્રમાં વધારો કરવો.

અવલંબન વ્યુત્ક્રમ સિદ્ધાંત (DIP)

ઉપર એક કોડ ઉદાહરણ છે જ્યાં AppManager EventLogWriter પર આધાર રાખે છે, જે બદલામાં AppManager સાથે નજીકથી જોડાયેલું છે. જો તમને સૂચના બતાવવા માટે કોઈ અલગ રીતની જરૂર હોય, પછી તે પુશ, SMS અથવા ઇમેઇલ હોય, તમારે AppManager વર્ગ બદલવાની જરૂર છે.

DIP નો ઉપયોગ કરીને સમસ્યા હલ કરી શકાય છે. તેથી, AppManager ને બદલે, અમે એક EventLogWriterની વિનંતી કરીએ છીએ, જે ફ્રેમવર્કનો ઉપયોગ કરીને દાખલ કરવામાં આવશે.

ડીઆઈપી ડિપેન્ડન્સી મોડ્યુલને બદલીને વ્યક્તિગત મોડ્યુલને અન્ય લોકો સાથે સરળતાથી બદલવાનું શક્ય બનાવે છે. આ અન્યને અસર કર્યા વિના એક મોડ્યુલને બદલવાનું શક્ય બનાવે છે.

વારસાને બદલે રચના

કોડનો પુનઃઉપયોગ કરવાની બે મુખ્ય રીતો છે: વારસો અને રચના, જે બંનેના પોતાના ફાયદા અને ગેરફાયદા છે. સામાન્ય રીતે બીજો પસંદ કરવામાં આવે છે કારણ કે તે વધુ લવચીક છે.

કમ્પોઝિશન તમને ક્લાસના પ્રોપર્ટીઝ સેટ કરીને રનટાઇમ પર તેની વર્તણૂક બદલવાની ક્ષમતા આપે છે. ઇન્ટરફેસનો અમલ કરતી વખતે, પોલિમોર્ફિઝમનો ઉપયોગ થાય છે, જે વધુ લવચીક અમલીકરણ આપે છે.

જોશુઆ બ્લોચ દ્વારા પણ અસરકારક જાવા વારસા પર કમ્પોઝિશન પસંદ કરવાની સલાહ આપે છે.

બાર્બરા લિસ્કોવ અવેજી સિદ્ધાંત (LSP)

SOLID ટૂલકીટનો બીજો સિદ્ધાંત. તે જણાવે છે કે સબટાઈપ સુપરટાઈપ માટે અવેજીપાત્ર હોવા જોઈએ. એટલે કે, સુપરક્લાસ સાથે કામ કરતી પદ્ધતિઓ અને ફંક્શન્સ તેના પેટાક્લાસ સાથે સમસ્યા વિના કામ કરવા સક્ષમ હોવા જોઈએ.

LSP એકલ જવાબદારી સિદ્ધાંત અને વહેંચાયેલ જવાબદારી સિદ્ધાંત બંને સાથે સંકળાયેલું છે. જો કોઈ વર્ગ સબક્લાસ કરતાં વધુ કાર્યક્ષમતા પ્રદાન કરે છે, તો બાદમાં આ સિદ્ધાંતનું ઉલ્લંઘન કરીને કેટલીક કાર્યક્ષમતાને સમર્થન આપશે નહીં.

અહીં કોડનો એક ભાગ છે જે LSP નો વિરોધાભાસ કરે છે.

વિસ્તાર(રેક્ટેંગલ આર) પદ્ધતિ લંબચોરસના ક્ષેત્રફળની ગણતરી કરે છે. સ્ક્વેરને એક્ઝિક્યુટ કર્યા પછી પ્રોગ્રામ ક્રેશ થશે કારણ કે સ્ક્વેર અહીં લંબચોરસ નથી. LSP સિદ્ધાંત અનુસાર, ફંક્શન કે જે બેઝ ક્લાસના સંદર્ભોનો ઉપયોગ કરે છે તે વધારાના સૂચનો વિના વ્યુત્પન્ન વર્ગોની વસ્તુઓનો ઉપયોગ કરવા સક્ષમ હોવા જોઈએ.

આ સિદ્ધાંત, જે પેટાપ્રકારની ચોક્કસ વ્યાખ્યા છે, બાર્બરા લિસ્કોવ દ્વારા "ડેટા એબ્સ્ટ્રેક્શન અને હાયરાર્કી" શીર્ષકવાળી 1987 કોન્ફરન્સ કીનોટમાં પ્રસ્તાવિત કરવામાં આવ્યો હતો, તેથી તેનું નામ.

ઇન્ટરફેસ સ્પ્લિટ સિદ્ધાંત (ISP)

અન્ય નક્કર સિદ્ધાંત. તેના અનુસાર, જે ઇન્ટરફેસનો ઉપયોગ ન થતો હોય તેને અમલમાં મૂકવો જોઈએ નહીં. આ સિદ્ધાંતને અનુસરવાથી જ્યારે ઓપરેટિંગ લોજિકમાં ફેરફાર કરવામાં આવે ત્યારે સિસ્ટમને લવચીક અને રિફૅક્ટરિંગ માટે યોગ્ય રહેવામાં મદદ મળે છે.

મોટેભાગે, આ પરિસ્થિતિ ત્યારે થાય છે જ્યારે ઇન્ટરફેસમાં એક સાથે અનેક કાર્યો હોય છે, અને ક્લાયંટને તેમાંથી ફક્ત એકની જરૂર હોય છે.

ઈન્ટરફેસ લખવાનું મુશ્કેલ કાર્ય હોવાથી, કંઈપણ તોડ્યા વિના કાર્ય પૂર્ણ થયા પછી તેને બદલવું એક પડકાર બની રહેશે.

જાવામાં ISP સિદ્ધાંતનો ફાયદો એ છે કે તમામ પદ્ધતિઓનો પ્રથમ અમલ થવો જોઈએ, અને તે પછી જ તેનો વર્ગો દ્વારા ઉપયોગ કરી શકાય છે. તેથી, સિદ્ધાંત પદ્ધતિઓની સંખ્યા ઘટાડવાનું શક્ય બનાવે છે.

ઇન્ટરફેસ માટે પ્રોગ્રામિંગ, અમલીકરણ માટે નહીં

અહીં બધું શીર્ષક પરથી સ્પષ્ટ છે. આ સિદ્ધાંતને લાગુ કરવાથી લવચીક કોડની રચના થાય છે જે ઇન્ટરફેસના કોઈપણ નવા અમલીકરણ સાથે કામ કરી શકે છે.

તમારે ચલો, રીટર્ન પ્રકારો અથવા પદ્ધતિ દલીલ પ્રકાર માટે ઇન્ટરફેસ પ્રકારનો ઉપયોગ કરવો જોઈએ. સબક્લાસને બદલે સુપરક્લાસનો ઉપયોગ કરવાનું ઉદાહરણ છે.

તે જ:

યાદી નંબરો = getNumbers();

પણ નહીં:

એરેલિસ્ટ નંબર્સ = getNumbers();

ઉપર જે ચર્ચા કરવામાં આવી છે તેનું વ્યવહારુ અમલીકરણ અહીં છે.

પ્રતિનિધિમંડળનો સિદ્ધાંત

એક સામાન્ય ઉદાહરણ Java માં equals() અને hashCode() પદ્ધતિઓ છે. જ્યારે બે ઑબ્જેક્ટ્સની તુલના કરવી જરૂરી હોય, ત્યારે આ ક્રિયા ક્લાયંટ એકને બદલે સંબંધિત વર્ગને સોંપવામાં આવે છે.

સિદ્ધાંતનો ફાયદો એ છે કે કોડનું કોઈ ડુપ્લિકેશન નથી અને વર્તન બદલવું તે પ્રમાણમાં સરળ છે. તે ઇવેન્ટ ડેલિગેશનને પણ લાગુ પડે છે.

આ બધા સિદ્ધાંતો તમને ઉચ્ચ સુસંગતતા અને ઓછા જોડાણ સાથે વધુ લવચીક, સુંદર અને વિશ્વસનીય કોડ લખવાની મંજૂરી આપે છે. અલબત્ત, થિયરી સારી છે, પરંતુ વિકાસકર્તાને પ્રાપ્ત જ્ઞાનનો વાસ્તવમાં ઉપયોગ કરવા માટે, પ્રેક્ટિસની જરૂર છે. એકવાર તમે OOP સિદ્ધાંતોમાં નિપુણતા મેળવી લો તે પછી, તમારું આગલું પગલું સામાન્ય સોફ્ટવેર ડેવલપમેન્ટ સમસ્યાઓ ઉકેલવા માટે ડિઝાઇન પેટર્ન શીખવાનું હોઈ શકે છે.

સ્કિલબોક્સ ભલામણ કરે છે:

• પ્રેક્ટિકલ કોર્સ "મોબાઇલ ડેવલપર પ્રો".
• ઓનલાઈન કોર્સ લાગુ કર્યો "પાયથોનમાં ડેટા વિશ્લેષક".
• બે વર્ષનો પ્રેક્ટિકલ કોર્સ "હું વેબ ડેવલપર પ્રો છું".

સોર્સ: www.habr.com