सॉफ्टवेयर ऑब्जेक्ट्स के बीच नियंत्रण स्थानांतरित करने के तरीके

सॉफ्टवेयर ऑब्जेक्ट OOP से साधारण वर्ग हैं। सॉफ्टवेयर ऑब्जेक्ट्स के इंटरैक्शन से मेरा मतलब एक क्लास से दूसरे क्लास में कंट्रोल ट्रांसफर करना होगा।

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



चूंकि मुझे C # भाषा और .NET फ्रेमवर्क के साथ काम करने की आदत है, इसलिए मैं उन्हें उदाहरण और स्पष्टीकरण में उपयोग करूंगा। यह तुरंत कहने योग्य है कि C # में ईवेंट तंत्र को डेलिगेट्स - पॉइंटर्स के माध्यम से पूर्वनिर्धारित इंटरफ़ेस वाली विधि से लागू किया जाता है। समान उद्देश्यों के लिए, कमांड या ऑब्जर्वर पैटर्न उपयुक्त है। कार्यान्वयन में अंतर के बावजूद, वे अर्थ में समान हैं। दोनों एक कार्य करते हैं - वे एक अज्ञात ग्राहक या ग्राहकों की घटना के बारे में सूचित करते हैं।

मैं ऐसी स्थिति पर विचार करूंगा जहां केवल एक वस्तु दूसरे के बारे में जानती हो। वेरिएंट अभी भी संभव है - दोनों एक-दूसरे के बारे में जानते हैं (कक्षाओं का मजबूत सामंजस्य), या किसी को भी किसी के बारे में नहीं पता है (सार्वभौमिकता, मुखौटा पैटर्न के आवेदन, आदि)।

विवरण

ऑब्जेक्ट विधि का मतलब है कि एक वर्ग (निष्पादक) अपने इंटरफ़ेस के माध्यम से कुछ विधि प्रदान करता है। दूसरा (प्रबंधक), निष्पादक उदाहरण के लिए एक लिंक है, इस पद्धति को कॉल कर सकता है। इस मामले में, नियंत्रण को पहली वस्तु से दूसरे में स्थानांतरित किया जाता है। यहाँ C # में एक उदाहरण दिया गया है (जिन्हें C ++, जावा, मुझे लगता है, वे भी समझेंगे):



//

class Worker {

public void doWork() {

//....

}

}



//

class Boss {

Worker worker1 = new Worker();

Worker worker2 = new Worker();



public void startProject() {

worker1.doWork();

worker2.doWork();

}

}





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





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



//

class Worker {

public Worker(Boss boss) {

boss.projectStarted += new EventHandler(doWork);

}



private void doWork(object sender, EventArgs e) {

//....

}

}



//

class Boss {

public event EventHandler projectStarted;



public void startProject() {

if (projectStarted != null)

projectStarted.Invoke(this, new EventArgs());

}

}







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

आवेदन

मॉडल-व्यू-कंट्रोलर को लागू करते समय उचित दृष्टिकोण को लागू करने की समस्या उत्पन्न हुई। नियंत्रक से नियंत्रण को दृश्य में स्थानांतरित किया जाता है और मुझे यह तय करना था कि किसके बारे में पता होना चाहिए: नियंत्रक के बारे में देखने या देखने के बारे में नियंत्रक?

सबसे पहले, आइए देखें कि यह दूसरों द्वारा कैसे लागू किया जाता है। आइए WinForms लाइब्रेरी से कुछ UI नियंत्रण लें (उदाहरण के लिए, मुझे अन्य UI फ्रेमवर्क के अनुयायियों को माफ़ करें), बटन।

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

बटन वर्ग डिज़ाइन करते समय, हमें एक समस्या होती है - हमें यह नहीं पता होता है कि बटन नियंत्रण को कहां पहुंचा सकता है और इसे कहां से प्राप्त कर सकता है। लेकिन आपको व्यवहार को लागू करने की आवश्यकता है। मुझे एक स्पष्ट निष्कर्ष तैयार करना चाहिए, जो फिर भी हमें सिस्टम डिजाइन की प्रकृति को बेहतर ढंग से समझने की अनुमति देता है। अज्ञात के लिए नियंत्रण पास करना, हम घटना तंत्र का उपयोग करते हैं, अज्ञात से नियंत्रण प्राप्त करते हुए, हम ऑब्जेक्ट तंत्र का उपयोग करते हैं।

बेहतर धारणा के लिए चित्र:





लेकिन यह सबूत केवल "अज्ञात" पर लागू होता है। लेकिन क्या होगा अगर हम दोनों हिस्सों को डिज़ाइन करते हैं और हमारे पास कोई सस्पेंस नहीं है? हमें अज्ञात के साथ आना चाहिए। लेकिन कौन सा दृष्टिकोण चुनना है? मैं इस नतीजे पर पहुंचा कि कोई भी। यह सब उस पर निर्भर करता है जहां हम डिजाइन करना शुरू करते हैं, जो हमारे लिए प्राथमिक है।

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

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

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

क्यों?

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

1. सिस्टम डिवाइस की अपनी समझ में कठिनाई;
2. कक्षाओं को संशोधित करने में कठिनाई;
3. किसी बाहरी व्यक्ति को सिस्टम डिज़ाइन की व्याख्या करने में कठिनाई।

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

इन और अन्य पैटर्नों के बारे में किताब में पाया जा सकता है, “ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के रिसेप्शन। ई। गामा, आर। हेल्म, आर। जॉनसन, जे। विलीसाइड्स द्वारा डिज़ाइन पैटर्न ”। यूएमएल के बारे में, पुस्तक "यूएमएल देखें। उपयोगकर्ता गाइड "ग्रैडी बुच, जेम्स रैम्बो, ऐवर जैकबसन।