2012-07-02 21 views
8

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

त्वरित और व्यापक उत्तरों के लिए धन्यवाद! वे सभी बेहद सहायक थे।

उत्तर

4

का लाभ प्रतिनिधि पैटर्न प्रतिनिधि वस्तु और उसके प्रतिनिधि के बीच ढीला युग्मन है। लूज युग्मन अन्य संदर्भों में कक्षा की पुन: प्रयोज्यता में सुधार करता है।

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

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

3

देखें this चर्चा

एक प्रतिनिधि एक वस्तु किसी अन्य वस्तु को संदेश भेजने के लिए जब एक घटना होता है की अनुमति देता है।

पेशेवरों

  • बहुत सख्त वाक्य रचना। सभी घटनाओं को सुनने के लिए प्रतिनिधि प्रोटोकॉल में स्पष्ट रूप से परिभाषित किया गया है।

  • संकलन समय चेतावनी/त्रुटियां अगर कोई विधि लागू नहीं की जाती है क्योंकि यह एक प्रतिनिधि द्वारा होना चाहिए।

  • प्रोटोकॉल केवल नियंत्रक के दायरे में परिभाषित किया गया।

  • बहुत ही पता लगाने योग्य, और एक आवेदन के भीतर नियंत्रण के प्रवाह की पहचान करना आसान है।

  • एकाधिक प्रोटोकॉल को एक नियंत्रक परिभाषित करने की क्षमता, प्रत्येक अलग-अलग प्रतिनिधियों के साथ।

  • संचार प्रक्रिया को बनाए रखने/निगरानी करने के लिए कोई तृतीय पक्ष वस्तु आवश्यक नहीं है।

  • किसी ज्ञात प्रोटोकॉल विधि से लौटाए गए मूल्य प्राप्त करने की क्षमता। इसका मतलब है कि एक प्रतिनिधि एक नियंत्रक को जानकारी प्रदान करने में मदद कर सकता है।

विपक्ष

  • कोड से कई लाइनों को परिभाषित करने के लिए आवश्यक हैं: 1. प्रोटोकॉल परिभाषा, नियंत्रक में 2. प्रतिनिधि संपत्ति, और 3. प्रतिनिधि विधि परिभाषाओं के कार्यान्वयन प्रतिनिधि के भीतर ही।

  • ऑब्जेक्ट डिलीओशन पर सही ढंग से प्रतिनिधियों को सेट करने के लिए सावधान रहने की आवश्यकता है, ऐसा करने में विफलता डिलीओटेड ऑब्जेक्ट्स पर विधियों को कॉल करके स्मृति क्रैश का कारण बन सकती है। हालांकि संभव

  • , यह मुश्किल हो सकता है और पैटर्न वास्तव में खुद को उधार नहीं करता है एक नियंत्रक में एक ही प्रोटोकॉल के कई प्रतिनिधियों के लिए (एक ही घटना के बारे में एक से अधिक ऑब्जेक्ट कह)

2

प्रतिनिधिमंडल के लिए "उपयोग केस" विरासत के लिए काफी समान है, अर्थात् एक पॉलिमॉर्फिक तरीके से कक्षा व्यवहार को विस्तारित करना।

यह वह जगह है wikipedia कैसे परिभाषित करता प्रतिनिधिमंडल:

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

वहाँ कर रहे हैं, जाहिर है, प्रतिनिधिमंडल और विरासत, लेकिन सबसे बड़ा एक है कई अंतर हैं, IMO, कि विरासत एक निश्चित (उर्फ, संकलन समय) दो वर्गों के बीच संबंध है, प्रतिनिधिमंडल रन पर परिभाषित किया जा सकता है, जबकि समय (भाषाओं का समर्थन करने वाले भाषाओं में)। दूसरी ओर, विरासत polymorphism के लिए बेहतर समर्थन प्रदान करता है।

प्रतिनिधिमंडल एक बड़ा विषय है (विरासत है), और आप इसके बारे में बहुत कुछ पढ़ सकते हैं। अंत में, यह तय करने के लिए कि क्या आप "एक-ए" या "है-ए" रिश्ते चाहते हैं, यह तय करने के लिए प्रतिनिधिमंडल या विरासत का उपयोग करना है, इसलिए इसे चुनने के लिए दिशानिर्देशों को सूचीबद्ध करना इतना आसान नहीं है।

  1. मेरे कोड (सजातीय व्यवहार का एक सेट सजातीय यहाँ मतलब यह है कि एक आम "प्रकृति होने के रूप में पहचाना जा सकता है प्रस्तुत करता है:

    मेरे लिए, मूल रूप से, एक प्रतिनिधि बनाने के लिए निर्णय अवलोकन है कि से आता है ");

  2. उन व्यवहारों को विशेष मामलों (जैसे वैकल्पिक व्यवहारों द्वारा प्रतिस्थापित) के लिए "अनुकूलित" किया जा सकता है।

यह मेरा व्यक्तिगत दृश्य है और जिस तरह से मुझे "प्रतिनिधिमंडल" पैटर्न की पहचान करने का तरीका बताया गया है। इस तथ्य के साथ शायद यह बहुत कुछ करना है कि मेरे प्रोग्रामिंग अनुशासन को रिफैक्टरिंग के सिद्धांत द्वारा दृढ़ता से सूचित किया जाता है।

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

उम्मीद है कि इससे मदद मिलती है।

संबंधित मुद्दे