Dependency inversion principle
ઓબ્જેક્ટ-ઓરિએન્ટેડ ડિઝાઇનમાં, અવલંબન વ્યુત્ક્રમ સિદ્ધાંત એ ઢીલી રીતે જોડાયેલા સોફ્ટવેર મોડ્યુલો માટેની ચોક્કસ પદ્ધતિ છે. આ સિદ્ધાંતનું પાલન કરતી વખતે, ઉચ્ચ-સ્તરના, નીતિ-સેટિંગ મોડ્યુલોથી લઈને નિમ્ન-સ્તરના, નિર્ભરતા મોડ્યુલો સુધી સ્થાપિત પરંપરાગત નિર્ભરતા સંબંધો ઉલટાવી દેવામાં આવે છે, આમ ઉચ્ચ-સ્તરના મોડ્યુલોને નિમ્ન-સ્તરના મોડ્યુલ અમલીકરણ વિગતોથી સ્વતંત્ર રીતે પ્રસ્તુત કરવામાં આવે છે. સિદ્ધાંત જણાવે છેઃ ઉચ્ચ-સ્તર અને નીચલા-સ્તરની વસ્તુઓ સમાન અમૂર્તતા પર આધારિત હોવી જોઈએ, આ ડિઝાઇન સિદ્ધાંત જે રીતે કેટલાક લોકો ઑબ્જેક્ટ-ઓરિએન્ટેડ પ્રોગ્રામિંગ વિશે વિચારી શકે છે. આ સિદ્ધાંતના બિંદુઓ A અને B પાછળનો વિચાર એ છે કે ઉચ્ચ-સ્તરના મોડ્યુલ અને નિમ્ન-સ્તરના મોડ્યુલ વચ્ચેની ક્રિયાપ્રતિક્રિયાની રચના કરતી વખતે, ક્રિયાપ્રતિક્રિયાને તેમની વચ્ચેની અમૂર્ત ક્રિયાપ્રતિક્રિયા તરીકે વિચારવી જોઈએ. આની અસર માત્ર ઉચ્ચ-સ્તરના મોડ્યુલની રચના પર જ નહીં, પરંતુ નિમ્ન-સ્તરના મોડ્યુલ પર પણ પડે છેઃ નિમ્ન-સ્તરના મોડ્યુલની રચના ક્રિયાપ્રતિક્રિયાને ધ્યાનમાં રાખીને થવી જોઈએ અને તેના ઉપયોગના ઇન્ટરફેસને બદલવાની જરૂર પડી શકે છે. ઘણા કિસ્સાઓમાં, ક્રિયાપ્રતિક્રિયાને એક અમૂર્ત ખ્યાલ તરીકે વિચારવાથી વધારાના કોડિંગ પેટર્ન રજૂ કર્યા વિના ઘટકોના જોડાણને ઘટાડી શકાય છે, જે માત્ર હળવા અને ઓછા અમલીકરણ-આધારિત ક્રિયાપ્રતિક્રિયા યોજનાને મંજૂરી આપે છે. જ્યારે બે મોડ્યુલો વચ્ચે શોધાયેલ અમૂર્ત ક્રિયાપ્રતિક્રિયા યોજના (ઓ) સામાન્ય હોય છે અને સામાન્યીકરણ અર્થપૂર્ણ બને છે, ત્યારે આ ડિઝાઇન સિદ્ધાંત પણ નીચેની નિર્ભરતા વ્યુત્ક્રમ કોડિંગ પેટર્ન તરફ દોરી જાય છે. પરંપરાગત લેયર પેટર્ન પરંપરાગત એપ્લિકેશન આર્કિટેક્ચરમાં, નીચલા-સ્તરના ઘટકો (દા. ત., યુટિલિટી લેયર) ઉચ્ચ-સ્તરના ઘટકો (દા. ત., પોલિસી લેયર) દ્વારા ઉપયોગમાં લેવા માટે ડિઝાઇન કરવામાં આવે છે જે વધુને વધુ જટિલ સિસ્ટમોને બનાવવામાં સક્ષમ બનાવે છે. આ રચનામાં, ઉચ્ચ-સ્તરના ઘટકો અમુક કાર્ય હાંસલ કરવા માટે સીધા નીચલા-સ્તરના ઘટકો પર આધાર રાખે છે. નીચલા સ્તરના ઘટકો પરની આ નિર્ભરતા ઉચ્ચ સ્તરના ઘટકોના પુનઃઉપયોગની તકોને મર્યાદિત કરે છે. ડિપેન્ડન્સી ઇન્વર્ઝન પેટર્નનો ધ્યેય એ અમૂર્ત સ્તરની મધ્યસ્થી સાથે આ ઉચ્ચ જોડીદાર વિતરણને ટાળવાનો અને ઉચ્ચ/નીતિ સ્તરોની પુનઃઉપયોગીતામાં વધારો કરવાનો છે. અવલંબન વ્યુત્ક્રમ પેટર્ન અમૂર્ત સ્તરના ઉમેરા સાથે, ઉચ્ચ અને નીચલા સ્તર બંને પરંપરાગત અવલંબનને ઉપરથી નીચે સુધી ઘટાડે છે. તેમ છતાં, "વ્યુત્ક્રમ" ખ્યાલનો અર્થ એ નથી કે નીચલા સ્તરના સ્તરો સીધા ઉચ્ચ સ્તરના સ્તરો પર આધાર રાખે છે. બંને સ્તરો એબ્સ્ટ્રેક્શન (ઇન્ટરફેસ) પર આધારિત હોવા જોઈએ જે ઉચ્ચ-સ્તરના સ્તરો દ્વારા જરૂરી વર્તનને છતી કરે છે. ડિપેન્ડન્સી ઇન્વર્ઝનના સીધા ઉપયોગમાં, એબ્સ્ટ્રેક્ટ્સ ઉપલા/નીતિ સ્તરોની માલિકીના હોય છે. આ આર્કિટેક્ચર ઉચ્ચ/નીતિ ઘટકો અને એબ્સ્ટ્રેક્શન્સને જૂથબદ્ધ કરે છે જે સમાન પેકેજમાં નીચલી સેવાઓને એકસાથે વ્યાખ્યાયિત કરે છે. નીચલા સ્તરના સ્તરો આ અમૂર્ત વર્ગો અથવા ઇન્ટરફેસના વારસો/અમલીકરણ દ્વારા બનાવવામાં આવે છે. નિર્ભરતા અને માલિકીનું વ્યુત્ક્રમ ઉચ્ચ/નીતિ સ્તરોના પુનઃઉપયોગને પ્રોત્સાહન આપે છે. ઉપલા સ્તરો નીચલી સેવાઓના અન્ય અમલીકરણનો ઉપયોગ કરી શકે છે. જ્યારે નીચલા સ્તરના ઘટકો બંધ હોય અથવા જ્યારે એપ્લિકેશનને હાલની સેવાઓના પુનઃઉપયોગની જરૂર હોય, ત્યારે એ સામાન્ય બાબત છે કે એડેપ્ટર સેવાઓ અને અમૂર્તતા વચ્ચે મધ્યસ્થી કરે છે. અવલંબન વ્યુત્ક્રમ પેટર્ન સામાન્યીકરણ ઘણા પ્રોજેક્ટ્સમાં અવલંબન વ્યુત્ક્રમ સિદ્ધાંત અને પેટર્નને એક જ ખ્યાલ તરીકે ગણવામાં આવે છે જેને સામાન્ય બનાવવું જોઈએ, એટલે કે, સોફ્ટવેર મોડ્યુલો વચ્ચેના તમામ ઇન્ટરફેસો પર લાગુ થવું જોઈએ. તેના માટે ઓછામાં ઓછા બે કારણો છેઃ સારી વિચારસરણીના સિદ્ધાંતને કોડિંગ પેટર્ન તરીકે જોવું સરળ છે. એકવાર એબ્સ્ટ્રેક્ટ ક્લાસ અથવા ઇન્ટરફેસને કોડેડ કરવામાં આવ્યા પછી, પ્રોગ્રામર કહી શકે છેઃ "મેં એબ્સ્ટ્રેક્શનનું કામ કર્યું છે". કારણ કે ઘણા એકમ પરીક્ષણ સાધનો મશ્કરી પૂર્ણ કરવા માટે વારસો પર આધાર રાખે છે, વર્ગો વચ્ચે સામાન્ય ઇન્ટરફેસનો ઉપયોગ (માત્ર મોડ્યુલો વચ્ચે જ નહીં જ્યારે સામાન્યતાનો ઉપયોગ કરવો અર્થપૂર્ણ બને છે) નિયમ બની ગયો. જો વપરાયેલ ઉપહાસ સાધન માત્ર વારસો પર આધાર રાખે છે, તો નિર્ભરતા વ્યુત્ક્રમ પેટર્નને વ્યાપકપણે લાગુ કરવી જરૂરી બની શકે છે. આમાં મોટી ખામીઓ છેઃ ફક્ત વર્ગ પર ઇન્ટરફેસનો અમલ કરવો એ જોડાણ ઘટાડવા માટે પૂરતું નથી; માત્ર ક્રિયાપ્રતિક્રિયાઓના સંભવિત અમૂર્તતા વિશે વિચારવું એ ઓછી જોડીદાર રચના તરફ દોરી શકે છે. પ્રોજેક્ટમાં દરેક જગ્યાએ સામાન્ય ઇન્ટરફેસનો અમલ કરવાથી તેને સમજવું અને જાળવવું મુશ્કેલ બને છે. દરેક તબક્કે વાચક પોતાને પૂછશે કે આ ઇન્ટરફેસના અન્ય અમલીકરણ શું છે અને તેનો જવાબ સામાન્ય રીતે છેઃ માત્ર મજાક. ઇન્ટરફેસ સામાન્યીકરણ માટે વધુ પ્લમ્બિંગ કોડની જરૂર પડે છે, ખાસ કરીને એવા કારખાનાઓમાં કે જે સામાન્ય રીતે નિર્ભરતા-ઇન્જેક્શન માળખા પર આધાર રાખે છે. ઇન્ટરફેસ સામાન્યીકરણ પણ પ્રોગ્રામિંગ ભાષાના ઉપયોગને પ્રતિબંધિત કરે છે. સામાન્યીકરણ પ્રતિબંધો ડિપેન્ડન્સી ઇન્વર્ઝન પેટર્ન (ડી. આઈ. પી.) ને પૂર્ણ કરવા માટે ઇન્ટરફેસોની હાજરી ઑબ્જેક્ટ-ઓરિએન્ટેડ પ્રોગ્રામમાં અન્ય ડિઝાઇન અસરો ધરાવે છેઃ વર્ગમાં તમામ સભ્ય ચલો ઇન્ટરફેસો અથવા અમૂર્ત હોવા જોઈએ. બધા કોંક્રિટ વર્ગ પેકેજોને ફક્ત ઇન્ટરફેસ અથવા અમૂર્ત વર્ગ પેકેજો દ્વારા જોડવા આવશ્યક છે. કોઈ પણ વર્ગ કોંક્રિટ વર્ગમાંથી વ્યુત્પન્ન થવો જોઈએ નહીં. કોઈ પણ પદ્ધતિ અમલમાં મુકાયેલી પદ્ધતિને ઓવરરાઇડ ન કરવી જોઈએ. તમામ ચલ ત્વરિતતા માટે ફેક્ટરી પદ્ધતિ અથવા ફેક્ટરી પેટર્ન જેવી રચનાત્મક પેટર્નના અમલીકરણ અથવા નિર્ભરતા-ઇન્જેક્શન માળખાના ઉપયોગની જરૂર પડે છે. ઇન્ટરફેસ મોકિંગ પ્રતિબંધો વારસો-આધારિત મોકિંગ સાધનોનો ઉપયોગ કરીને પણ પ્રતિબંધો રજૂ કરવામાં આવે છેઃ સ્થિર બાહ્ય રીતે દૃશ્યમાન સભ્યોએ વ્યવસ્થિત રીતે ડિપેન્ડન્સી ઈન્જેક્શન પર આધાર રાખવો જોઈએ જે તેમને અમલમાં મૂકવાનું વધુ મુશ્કેલ બનાવે છે. તમામ ચકાસી શકાય તેવી પદ્ધતિઓ ઇન્ટરફેસ અમલીકરણ અથવા અમૂર્ત વ્યાખ્યાની ઓવરરાઇડ બનવી જોઈએ. ભવિષ્યની દિશાઓ સિદ્ધાંતો વિચારવાની રીતો છે. પેટર્ન એ સમસ્યાઓ ઉકેલવાની સામાન્ય રીતો છે. ખોવાયેલી પ્રોગ્રામિંગ ભાષાની સુવિધાઓ માટે કોડિંગ પેટર્ન અસ્તિત્વમાં હોઈ શકે છે. પ્રોગ્રામિંગ ભાષાઓ ઓછામાં ઓછી બે દિશામાં મજબૂત અને વધુ ચોક્કસ વપરાશ કરાર લાગુ કરવા માટે તેમને મંજૂરી આપવા માટે વિકસિત થતી રહેશેઃ ઉપયોગની શરતો (પૂર્વ, પછી અને અપરિવર્તનશીલ શરતો) અને રાજ્ય આધારિત ઇન્ટરફેસો લાગુ કરવી. આ કદાચ ઘણી પરિસ્થિતિઓમાં નિર્ભરતા વ્યુત્ક્રમ પેટર્નના મજબૂત ઉપયોગને પ્રોત્સાહિત કરશે અને સંભવિત રીતે સરળ બનાવશે. વધુને વધુ ઉપહાસ સાધનો હવે સ્થિર અને બિન-આભાસી સભ્યોને બદલવાની સમસ્યાને ઉકેલવા માટે નિર્ભરતા-ઇન્જેક્શનનો ઉપયોગ કરે છે. પ્રોગ્રામિંગ ભાષાઓ કદાચ મોકિંગ-સુસંગત બાઈટકોડ પેદા કરવા માટે વિકસિત થશે. એક દિશા બિન-વર્ચ્યુઅલ સભ્યોના ઉપયોગને પ્રતિબંધિત કરવાની રહેશે. બીજું, ઓછામાં ઓછું પરીક્ષણની પરિસ્થિતિઓમાં, બિન-વારસો આધારિત મજાકને મંજૂરી આપતા, બાઈટકોડ પેદા કરવાનું રહેશે. અમલીકરણ ડી. આઈ. પી. ના બે સામાન્ય અમલીકરણ સમાન તાર્કિક માળખાનો ઉપયોગ કરે છે પરંતુ તેની વિવિધ અસરો હોય છે. સીધું અમલીકરણ નીતિના વર્ગોને સેવા અમૂર્ત વર્ગો સાથે એક પુસ્તકાલયમાં પેકેજ કરે છે. આ અમલીકરણમાં ઉચ્ચ-સ્તરના ઘટકો અને નિમ્ન-સ્તરના ઘટકોને અલગ પેકેજો/પુસ્તકાલયોમાં વહેંચવામાં આવે છે, જ્યાં ઉચ્ચ-સ્તરના ઘટક દ્વારા જરૂરી વર્તન/સેવાઓને વ્યાખ્યાયિત કરતા ઇન્ટરફેસોની માલિકી હોય છે અને તે ઉચ્ચ-સ્તરના ઘટકના પુસ્તકાલયમાં અસ્તિત્વ ધરાવે છે. નિમ્ન-સ્તરના ઘટક દ્વારા ઉચ્ચ-સ્તરના ઘટકના ઇન્ટરફેસના અમલીકરણ માટે જરૂરી છે કે નિમ્ન-સ્તરનું ઘટક પેકેજ સંકલન માટે ઉચ્ચ-સ્તરના ઘટક પર આધાર રાખે, આમ પરંપરાગત નિર્ભરતા સંબંધને ઉલટાવી દે છે. આકૃતિ 1 અને 2 સમાન કાર્યક્ષમતા સાથે કોડને સમજાવે છે, જો કે આકૃતિ 2 માં, અવલંબનને ઉલટાવવા માટે ઇન્ટરફેસનો ઉપયોગ કરવામાં આવ્યો છે. પોલિસી કોડનો મહત્તમ પુનઃઉપયોગ કરવા અને ચક્રીય નિર્ભરતાને દૂર કરવા માટે નિર્ભરતાની દિશા પસંદ કરી શકાય છે. ડી. આઈ. પી. ના આ સંસ્કરણમાં, ઉચ્ચ-સ્તરના સ્તરોમાં ઇન્ટરફેસો/અમૂર્ત પર નીચલા સ્તરના ઘટકની નિર્ભરતા નીચલા સ્તરના ઘટકોનો ફરીથી ઉપયોગ મુશ્કેલ બનાવે છે. તેના બદલે આ અમલીકરણ પરંપરાગત નિર્ભરતાને ઉપરથી નીચેથી વિરુદ્ધ તરફ, નીચેથી ઉપર સુધી "ઊંધી કરે છે". વધુ લવચીક ઉકેલ અમૂર્ત ઘટકોને પેકેજો/પુસ્તકાલયોના સ્વતંત્ર સમૂહમાં કાઢે છેઃ દરેક સ્તરને તેના પોતાના પેકેજમાં અલગ કરવાથી કોઈપણ સ્તરના પુનઃઉપયોગને પ્રોત્સાહન મળે છે, જે મજબૂતી અને ગતિશીલતા પ્રદાન કરે છે. ઉદાહરણો વંશાવળી મોડ્યુલ વંશાવળી પ્રણાલી લોકો વચ્ચેના સંબંધોને તેમની વચ્ચેના સીધા સંબંધોના આલેખ તરીકે રજૂ કરી શકે છે (પિતા-પુત્ર, પિતા-પુત્રી, માતા-પુત્ર, માતા-પુત્રી, પતિ-પત્ની, પત્ની-પતિ, વગેરે). આ ખૂબ જ કાર્યક્ષમ અને વિસ્તૃત છે, કારણ કે ભૂતપૂર્વ પતિ અથવા કાનૂની વાલીને ઉમેરવાનું સરળ છે. પરંતુ કેટલાક ઉચ્ચ-સ્તરના મોડ્યુલો માટે સિસ્ટમ બ્રાઉઝ કરવા માટે સરળ રીતની જરૂર પડી શકે છેઃ કોઈપણ વ્યક્તિને બાળકો, માતાપિતા, ભાઈ-બહેનો (સાવકા ભાઈઓ અને બહેનો સહિત કે નહીં), દાદા-દાદી, પિતરાઈ ભાઈઓ વગેરે હોઈ શકે છે. વંશાવળી મોડ્યુલના ઉપયોગના આધારે, સામાન્ય સંબંધોને અલગ સીધા ગુણધર્મો (આલેખ છુપાવીને) તરીકે રજૂ કરવાથી ઉચ્ચ-સ્તરના મોડ્યુલ અને વંશાવળી મોડ્યુલ વચ્ચેના જોડાણને વધુ હળવા બનાવશે અને તેનો ઉપયોગ કરતા મોડ્યુલો પર કોઈ અસર કર્યા વિના સીધા સંબંધોની આંતરિક રજૂઆતને સંપૂર્ણપણે બદલવાની મંજૂરી આપશે. તે વંશાવળી મોડ્યુલમાં ભાઈ-બહેનો અથવા કાકાઓની ચોક્કસ વ્યાખ્યાઓને સમાવવાની પણ મંજૂરી આપે છે, આમ એકલ જવાબદારી સિદ્ધાંતને લાગુ કરે છે. છેવટે, જો પ્રથમ એક્સ્ટેન્સિબલ જનરલાઈઝ્ડ ગ્રાફ અભિગમ સૌથી વધુ એક્સ્ટેન્સિબલ લાગે, તો વંશાવળી મોડ્યુલનો ઉપયોગ બતાવી શકે છે કે વધુ વિશિષ્ટ અને સરળ સંબંધ અમલીકરણ એપ્લિકેશન (ઓ) માટે પૂરતું છે અને વધુ કાર્યક્ષમ સિસ્ટમ બનાવવામાં મદદ કરે છે. આ ઉદાહરણમાં, મોડ્યુલો વચ્ચેની ક્રિયાપ્રતિક્રિયાને અમૂર્ત કરવાથી નીચલા સ્તરના મોડ્યુલના સરળ ઇન્ટરફેસ તરફ દોરી જાય છે અને તેના સરળ અમલીકરણ તરફ દોરી શકે છે. દૂરસ્થ ફાઇલ સર્વર ક્લાયન્ટ દૂરસ્થ ફાઇલ સર્વર (એફ. ટી. પી., ક્લાઉડ સ્ટોરેજ.) ક્લાયન્ટને અમૂર્ત ઇન્ટરફેસના સમૂહ તરીકે મોડેલિંગ કરી શકાય છેઃ જોડાણ/ડિસ્કનેક્શન (જોડાણ દ્રઢતા સ્તરની જરૂર પડી શકે છે) ફોલ્ડર/ટેગ્સ બનાવટ/નામ બદલવું/કાઢી નાખવું/સૂચિ ઇન્ટરફેસ ફાઇલ બનાવટ/બદલી/નામ બદલવું/કાઢી નાખવું/ઇન્ટરફેસ વાંચો ફાઇલ શોધે છે. જો સ્થાનિક અને દૂરસ્થ ફાઇલો સમાન અમૂર્ત ઇન્ટરફેસો પ્રદાન કરે છે, તો ઉચ્ચ-સ્તરના મોડ્યુલો કે જે નિર્ભરતા વ્યુત્ક્રમ પેટર્નનો અમલ કરે છે તે તેનો આડેધડ ઉપયોગ કરી શકે છે. એપ્લિકેશન તેના દસ્તાવેજોને સ્થાનિક રીતે અથવા દૂરથી પારદર્શક રીતે સાચવી શકશે. ઉચ્ચ સ્તરના મોડ્યુલો દ્વારા જરૂરી સેવાના સ્તરને ધ્યાનમાં લેવું જોઈએ. મોડ્યુલને અમૂર્ત ઇન્ટરફેસના સમૂહ તરીકે ડિઝાઇન કરવું અને તેમાં અન્ય મોડ્યુલોને અનુકૂળ બનાવવું, ઘણી સિસ્ટમો માટે એક સામાન્ય ઇન્ટરફેસ પ્રદાન કરી શકે છે. મોડલ-વ્યૂ-કંટ્રોલર UI અને એપ્લીકેશનલેયર પેકેજો મુખ્યત્વે કોંક્રિટ વર્ગો ધરાવે છે. નિયંત્રકો એબ્સ્ટ્રેક્ટ/ઇન્ટરફેસ પ્રકારો ધરાવે છે. UIમાં ICustomerHandlerનું ઉદાહરણ છે. બધા પેકેજો ભૌતિક રીતે અલગ કરવામાં આવે છે. એપ્લિકેશનલેયરમાં કસ્ટમરહેન્ડલરનું નક્કર અમલીકરણ છે જેનો ઉપયોગ પેજ ક્લાસ કરશે. iCustomerHandler ઈન્ટરફેસના ઉદાહરણો ફેક્ટરી દ્વારા ગતિશીલ રીતે બનાવવામાં આવે છે (સંભવતઃ તે જ કંટ્રોલર પેકેજમાં). કોંક્રિટ પ્રકારો પેજ અને કસ્ટમરહેન્ડલર ICustomerHandler પર આધાર રાખે છે, એકબીજા પર નહીં. યુઆઈ એપ્લિકેશનલેયર અથવા આઇક્યુસ્ટોમરહેન્ડલરનો અમલ કરતા અન્ય કોઈ નક્કર પેકેજનો સંદર્ભ આપતું નથી, તેથી કસ્ટમરહેન્ડલરના નક્કર અમલીકરણને યુઆઈ વર્ગને બદલ્યા વિના બદલી શકાય છે. ઉપરાંત, પેજ ક્લાસ ઈન્ટરફેસ આઇપેજવ્યૂઅરનો અમલ કરે છે જે આઇક્યુસ્ટોમરહેન્ડલર પદ્ધતિઓ માટે દલીલ તરીકે પસાર થઈ શકે છે, જે ગ્રાહકહેન્ડલરના નક્કર અમલીકરણને નક્કર નિર્ભરતા વિના યુઆઈ સાથે વાતચીત કરવાની મંજૂરી આપે છે. ફરીથી, બંને ઇન્ટરફેસ દ્વારા જોડાયેલા છે. નિર્ભરતા વ્યુત્ક્રમ સિદ્ધાંતને લાગુ પાડતી સંબંધિત પેટર્નને એડેપ્ટર પેટર્નના ઉદાહરણ તરીકે પણ જોઈ શકાય છે. એટલે કે, ઉચ્ચ-સ્તરનો વર્ગ તેના પોતાના એડેપ્ટર ઇન્ટરફેસને વ્યાખ્યાયિત કરે છે જે એબ્સ્ટ્રેક્શન છે જેના પર અન્ય ઉચ્ચ-સ્તરના વર્ગો આધાર રાખે છે. અનુકૂલિત અમલીકરણ પણ આવશ્યકપણે સમાન એડેપ્ટર ઇન્ટરફેસ એબ્સ્ટ્રેક્શન પર આધાર રાખે છે, જ્યારે તે તેના પોતાના નિમ્ન-સ્તરના મોડ્યુલમાંથી કોડનો ઉપયોગ કરીને અમલ કરી શકાય છે. ઉચ્ચ-સ્તરનું મોડ્યુલ નિમ્ન-સ્તરના મોડ્યુલ પર આધાર રાખતું નથી, કારણ કે તે અનુકૂલિત અમલીકરણ અને તેના નિમ્ન-સ્તરના મોડ્યુલ દ્વારા લાગુ કરવામાં આવતી ઇન્ટરફેસમાં બહુરૂપી પદ્ધતિઓનો ઉપયોગ કરીને એડેપ્ટર ઇન્ટરફેસ દ્વારા પરોક્ષ રીતે નિમ્ન-સ્તરની કાર્યક્ષમતાનો ઉપયોગ કરે છે. ઉચ્ચ-સ્તરના ઘટકમાં પસંદ કરેલા નિમ્ન-સ્તરના ઘટક અમલીકરણની રન-ટાઇમ જોગવાઈને સરળ બનાવવા માટે પ્લગઇન, સર્વિસ લોકેટર અથવા ડિપેન્ડન્સી ઈન્જેક્શન જેવી વિવિધ પેટર્નનો ઉપયોગ કરવામાં આવે છે. ઇતિહાસ નિર્ભરતા વ્યુત્ક્રમ સિદ્ધાંત રોબર્ટ સી. માર્ટિન દ્વારા પ્રતિપાદિત કરવામાં આવ્યો હતો અને પેપર ઓબ્જેક્ટ ઓરિએન્ટેડ ડિઝાઇન ક્વોલિટી મેટ્રિક્સ સહિત અનેક પ્રકાશનોમાં તેનું વર્ણન કરવામાં આવ્યું હતુંઃ અવલંબનોનું વિશ્લેષણ, મે 1996માં C + + અહેવાલમાં દેખાતો એક લેખ જેનું શીર્ષક હતું નિર્ભરતા વ્યુત્ક્રમ સિદ્ધાંત, અને પુસ્તકો ચપળ સોફ્ટવેર વિકાસ, સિદ્ધાંતો, પેટર્ન અને વ્યવહારો, અને ચપળ સિદ્ધાંતો, પેટર્ન અને વ્યવહારો C #. એડેપ્ટર પેટર્ન ડિપેન્ડન્સી ઈન્જેક્શન ડિઝાઇન બાય કોન્ટ્રાક્ટ ઇન્ટરફેસ ઇન્વેન્ટરની પેરડોક્સ ઇન્વર્ઝન ઓફ કંટ્રોલ પ્લગ-ઇન (કમ્પ્યુટિંગ) સર્વિસ લોકેટર પેટર્ન સોલિડ-"સોલિડ" માં "ડી" એટલે ડિપેન્ડન્સી ઇન્વર્ઝન સિદ્ધાંત સંદર્ભો ઑબ્જેક્ટ ઓરિએન્ટેડ ડિઝાઇન ક્વોલિટી મેટ્રિક્સઃ ડિપેન્ડન્સીઝનું વિશ્લેષણ રોબર્ટ સી. માર્ટિન, સી + + રિપોર્ટ, સપ્ટેમ્બર/ઓક્ટોબર 1995 ડિપેન્ડન્સી ઇન્વર્ઝન પ્રિન્સિપલ, રોબર્ટ સી. માર્ટિન, સી + + રિપોર્ટ, મે 1996 ડિપેન્ડન્સી ઇન્વર્ઝન પ્રિન્સિપલની તપાસ, ડેરેક ગ્રીર ડીઆઇપીઃ ધ ડિપેન્ડન્સી-ઇન્વર્ઝન પ્રિન્સિપલ ડીઆઇપી ઇન ધ વાઇલ્ડ, બ્રેટ એલ. શુચેર્ટ, મે 2013 ડિપેન્ડન્સી ઇન