👷🏻 💲 👩🏿‍🎓 नियंत्रण का उलटा 📝 🖖🏽 🚆

नियंत्रण का उलटा एक सामान्य घटना है जिसे आप फ्रेमवर्क का उपयोग करते समय सामना करेंगे। वास्तव में, इसे अक्सर रूपरेखा की एक परिभाषित विशेषता के रूप में देखा जाता है।

आइए एक साधारण उदाहरण देखें। कल्पना करें कि मैं एक प्रोग्राम लिख रहा हूं जो कमांड लाइन का उपयोग करके उपयोगकर्ता से कुछ जानकारी प्राप्त करता है। मैं इसे कुछ इस तरह से कर सकता था:

#ruby puts 'What is your name?' name = gets process_name(name) puts 'What is your quest?' quest = gets process_quest(quest)

इस स्थिति में, मेरा कोड निष्पादन को नियंत्रित करता है: यह तय करता है कि कब सवाल पूछना है, कब जवाब पढ़ना है, और कब परिणामों को संसाधित करना है।

हालाँकि, अगर मैंने विंडो सिस्टम का उपयोग कुछ इसी तरह से किया है, तो मैं खिड़की के साथ काम करने वाली चीज़ लिखूंगा:

  require 'tk' root = TkRoot.new() name_label = TkLabel.new() {text "What is Your Name?"} name_label.pack name = TkEntry.new(root).pack name.bind("FocusOut") {process_name(name)} quest_label = TkLabel.new() {text "What is Your Quest?"} quest_label.pack quest = TkEntry.new(root).pack quest.bind("FocusOut") {process_quest(quest)} Tk.mainloop()

अब, नियंत्रण प्रवाह में दो कार्यक्रमों के बीच एक बड़ा अंतर है - विशेष रूप से, समय प्रबंधन में जब process_name और process_quest विधियों को बुलाया जाता है। कमांड लाइन उदाहरण में, मैं नियंत्रित करता हूं जब इन तरीकों को बुलाया जाता है, लेकिन उदाहरण में एक विंडो वाले एप्लिकेशन के साथ, नहीं। इसके बजाय, मैं विंडो सिस्टम ( Tk.mainloop कमांड) को नियंत्रित करता हूं। वह तब निर्णय लेती है कि फॉर्म बनाते समय मेरे द्वारा कॉन्फ़िगर किए गए रिश्तों के आधार पर मेरे तरीकों को कॉल करें। प्रबंधन उलटा है - वे मुझे नियंत्रित करते हैं, न कि मैं रूपरेखा को नियंत्रित करता हूं। इस घटना को नियंत्रण का व्युत्क्रम कहा जाता है ( हॉलीवुड सिद्धांत के रूप में भी जाना जाता है - "हमें कॉल न करें, हम आपको वापस बुलाएंगे " - हॉलीवुड सिद्धांत - "हमें कॉल न करें, हम आपको कॉल करेंगे" )।

फ्रेमवर्क की एक महत्वपूर्ण विशेषता यह है कि उपयोगकर्ता द्वारा अपनी आवश्यकताओं के लिए फ्रेमवर्क को अनुकूलित करने के लिए परिभाषित किए गए तरीकों को अक्सर फ्रेमवर्क के अंदर ही बुलाया जाएगा, न कि उपयोगकर्ता के एप्लिकेशन कोड से। रूपरेखा अक्सर अनुप्रयोग के कार्यों के समन्वय और अनुक्रम में मुख्य कार्यक्रम की भूमिका निभाती है। नियंत्रण का यह उलटा फ्रेमवर्क एक एक्स्टेंसिबल एप्लिकेशन कंकाल के रूप में सेवा करने की क्षमता देता है। उपयोगकर्ता द्वारा प्रदान की गई विधियाँ एक विशिष्ट अनुप्रयोग के लिए रूपरेखा द्वारा परिभाषित सामान्य एल्गोरिदम को अनुकूलित करती हैं।

राल्फ जॉनसन और ब्रायन Foote।

नियंत्रण का उलटना एक रूपरेखा और पुस्तकालय के बीच क्या अंतर है, इसका एक महत्वपूर्ण हिस्सा है। एक पुस्तकालय अनिवार्य रूप से उन कार्यों का एक संग्रह है जिन्हें आप कॉल कर सकते हैं, इन दिनों वे कक्षाओं में व्यवस्थित होते हैं। प्रत्येक कॉल कुछ काम करता है और उपयोगकर्ता को वापस नियंत्रित करता है।

ढांचा अंतर्निहित व्यवहार के साथ कुछ सार डिजाइन का प्रतीक है। इसका उपयोग करने के लिए, आपको अपने कोड को फ्रेमवर्क के विभिन्न स्थानों में जोड़ना होगा, या तो विरासत के माध्यम से, या अपने स्वयं के वर्ग को जोड़कर। फ्रेमवर्क कोड बाद में आपके कोड को कॉल करेगा।

बाद में इसे कॉल करने के लिए अपने कोड को कनेक्ट करने के विभिन्न तरीके हैं। पिछले रूबी उदाहरण में, हम टेक्स्ट फ़ील्ड की बाइंड विधि को कॉल करते हैं , जो इवेंट नाम लेता है और तर्क के रूप में बंद हो जाता है। जब भी किसी पाठ क्षेत्र में किसी घटना के बारे में पता चलता है, तो वह हमारे कोड को एक बंद से बुलाता है। इस तरह के क्लोजर का उपयोग करना बहुत सुविधाजनक है, लेकिन कई भाषाएं उनका समर्थन नहीं करती हैं।

ऐसा करने का एक और तरीका यह है कि इन घटनाओं की सदस्यता के लिए फ्रेमवर्क की घटनाओं और उपयोगकर्ता कोड का पता लगाएं। .NET एक प्लेटफ़ॉर्म का एक अच्छा उदाहरण है जो लोगों को भाषा का उपयोग करके विजेट्स पर अपनी घटनाओं की घोषणा करने की अनुमति देता है। आप डेलिगेट्स का उपयोग करके किसी ईवेंट को विधि असाइन कर सकते हैं।

ऊपर चर्चा किए गए दृष्टिकोण (वे समान हैं) अलग-अलग मामलों में अच्छी तरह से अनुकूल हैं, लेकिन कभी-कभी आपको एक एकल विस्तार इकाई में कुछ निश्चित कॉल को संयोजित करने की आवश्यकता हो सकती है। इस स्थिति में, रूपरेखा इंटरफ़ेस को निर्धारित कर सकती है कि आपके कोड को संबंधित कॉल के लिए लागू करने की आवश्यकता होगी।

EJBs नियंत्रण व्युत्क्रम की इस शैली का एक अच्छा उदाहरण हैं। एक सत्र बीन विकसित करते समय, आप विभिन्न तरीकों को लागू कर सकते हैं जिन्हें EJB कंटेनर द्वारा जीवन चक्र में विभिन्न बिंदुओं / राज्यों पर बुलाया जाता है। उदाहरण के लिए, SessionBean इंटरफ़ेस में ejbRemove , ejbPassivate (सेकेंडरी स्टोरेज में सेव किया गया) और ejbActivate (निष्क्रिय अवस्था से बहाल) तरीके हैं। आप इन विधियों के कॉल को नियंत्रित नहीं कर सकते, केवल वे क्या करते हैं। कंटेनर हमें कहता है, न कि हम इसे कहते हैं।

अनुवाद नोट, उदाहरण:

 public class EjbExample implements SessionBean { public void ejbActivate() throws EJBException, RemoteException { // do some processing on session object became active } public void ejbPassivate() throws EJBException, RemoteException { // do some processing on session object became passive } public void ejbRemove() throws EJBException, RemoteException { // do some processing before the end of life of session object } public void setSessionContext(SessionContext sessionContext) throws EJBException, RemoteException { // interface dependency injection } }

ये नियंत्रण के उलट होने के जटिल मामले हैं, लेकिन आप बहुत सरल स्थितियों में इस पर आ जाएंगे। टेम्प्लेट विधि एक अच्छा उदाहरण है: एक सुपरक्लास एक नियंत्रण प्रवाह को परिभाषित करता है, इससे उप-वर्ग इनहेरिट करते हैं, यह तरीकों को ओवरराइड करने या अमूर्त विधियों को लागू करने से होता है। उदाहरण के लिए, JUnit में, फ्रेमवर्क कोड आपके परीक्षण को बनाने और साफ़ करने के लिए सेटअप और टियरडाउन तरीकों को कहता है। एक कॉल है, आपका कोड प्रतिक्रिया करता है - यह फिर से नियंत्रण का उलटा है।

अनुवाद नोट, उदाहरण:

 public class SomeTest extends TestCase { protected void setUp() throws Exception { super.setUp(); // make some preparation for the test, eg setup database connection } public void testSomeLogic() { // test some functionality } protected void tearDown() throws Exception { // cleanup after test has finished super.tearDown(); } }

आजकल, IoC कंटेनरों की संख्या में वृद्धि के कारण, नियंत्रण उलटा के अर्थ के साथ कुछ भ्रम है। कुछ लोग विशिष्ट नियंत्रण उलटा शैलियों (जैसे निर्भरता इंजेक्शन ) के साथ सामान्य सिद्धांत को भ्रमित करते हैं जो इन कंटेनरों का उपयोग करते हैं। यह सब थोड़ा भ्रमित (और विडंबनापूर्ण) है, क्योंकि IoC कंटेनरों को आमतौर पर EJBs के लिए एक प्रतियोगी के रूप में देखा जाता है, लेकिन EJBs उलटा नियंत्रण का उपयोग करते हैं।

व्युत्पत्ति विज्ञान: जहां तक मैं बता सकता हूं, 1988 में जर्नल ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में प्रकाशित जॉनसन एंड फुट डिजाइनिंग रेसेबल क्लासेस के काम में पहली बार नियंत्रण शब्द उलट आया। काम उन लोगों में से एक है जो उम्र में अच्छे हैं - इसे पंद्रह साल बाद भी पढ़ा जा सकता है। उनका मानना है कि उन्होंने यह शब्द कहीं और से लिया है, लेकिन उन्हें याद नहीं है कि यह कहाँ से आया है। यह शब्द तब ऑब्जेक्ट-ओरिएंटेड समुदाय में रगड़ गया और गैंग ऑफ़ फोर में फिर से प्रकट हुआ। अधिक सुंदर पर्यायवाची "हॉलीवुड सिद्धांत" 1983 में मेसा में रिचर्ड स्वीट के काम से उत्पन्न हुआ है । विकास लक्ष्यों की सूची में, वह लिखते हैं: हमें कॉल न करें, हम आपको वापस बुला लेंगे (हॉलीवुड कानून): टूल को ताहो के लिए व्यवस्था करनी होगी, जब उपयोगकर्ता मॉडल को किसी कमांड के लिए पूछने के बजाय उपयोगकर्ता को उपकरण में कुछ ईवेंट संचारित करना चाहता है, तो उसे भेजें। और इसे निष्पादित करें । " जॉन वलिसाइड्स सी ++ पर एक कॉलम लिखते हैं जो कि द हॉलीवुड प्रिंसिपल नामक अवधारणा का एक अच्छा विवरण करता है। (व्युत्पत्ति के लिए उनकी मदद के लिए ब्रायन Foote और राल्फ जॉनसन के लिए धन्यवाद)।

UPD: उदाहरण जोड़े गए।

नियंत्रण का उलटा

More articles: