दृश्य नियंत्रकों के बीच संवाद करने का सबसे अच्छा तरीका क्या है?


165

सामान्य रूप से उद्देश्य-सी, कोको और आईफोन देव के लिए नया होने के नाते, मुझे भाषा और रूपरेखा से सबसे अधिक पाने की तीव्र इच्छा है।

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

क्लास वेबसाइट:
http://www.stanford.edu/class/cs193p/cgi-bin/index.php

Lecture 08 एक UINavigationController आधारित ऐप को बनाने के लिए एक असाइनमेंट से संबंधित है जिसमें कई UIViewControllers हैं जो UINavigationController स्टैक पर धकेल दिए गए हैं। यह है कि कैसे UINavigationController काम करता है। यह तार्किक है। हालाँकि, आपके UIViewControllers के बीच संचार करने के बारे में स्लाइड में कुछ कड़ी चेतावनी दी गई है।

मैं इस गंभीर स्लाइड से उद्धरण देने जा रहा हूं:
http://cs193p.stanford.edu/downloads/08-NavigationTabBarControllers.pdf

पृष्ठ 16/51:

डेटा साझा करने के लिए कैसे नहीं

  • वैश्विक चर या एकल
    • इसमें आपका एप्लिकेशन प्रतिनिधि शामिल है
  • प्रत्यक्ष निर्भरताएं आपके कोड को कम पुन: प्रयोज्य बनाती हैं
    • और डिबग और परीक्षण करने के लिए और अधिक कठिन है

ठीक। मैं उसके साथ नीचे हूँ। अपने सभी तरीकों को नेत्रहीन रूप से टॉस न करें जो कि आपके ऐप प्रतिनिधि में व्यूकंट्रोलर के बीच संचार के लिए उपयोग किए जाएंगे और ऐप प्रतिनिधि विधियों में व्यूकंट्रोलर इंस्टेंस को संदर्भित करेंगे। फेयर 'नफ।

थोड़ा आगे बढ़ने पर हमें यह स्लाइड मिलती है कि हमें क्या करना चाहिए

पृष्ठ 18/51:

डेटा प्रवाह के लिए सर्वोत्तम अभ्यास

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

इस स्लाइड को उसके बाद एक जगह धारक स्लाइड के रूप में दिखाई देता है जहां व्याख्याता तब स्पष्ट रूप से UIImagePickerController के साथ एक उदाहरण का उपयोग करके सर्वोत्तम प्रथाओं का प्रदर्शन करता है। काश वीडियो उपलब्ध होते! :(

ठीक है, तो ... मुझे डर है कि मेरा ओब्जेक्ट-फू इतना मजबूत नहीं है। मैं भी उपरोक्त पंक्ति में अंतिम पंक्ति से थोड़ा भ्रमित हूँ। मैं इस बारे में गुगली करने की अपनी उचित हिस्सेदारी कर रहा हूं और मैंने पाया कि एक अच्छा लेख प्रतीत होता है जिसमें अवलोकन / अधिसूचना तकनीकों के विभिन्न तरीकों के बारे में बात की गई है:
http://cocoawithlove.com/2008/06/five-approaches-to -listening-observing.html

विधि # 5 भी एक विधि के रूप में प्रतिनिधियों को इंगित करता है! सिवाय .... वस्तुओं के एक समय में केवल एक प्रतिनिधि सेट कर सकते हैं। इसलिए जब मेरे पास कई दृश्य संचारक हैं, तो मुझे क्या करना है?

ठीक है, यह सेट अप गिरोह है। मुझे पता है कि मैं आसानी से अपने प्रतिनिधि के संदर्भ में कई व्यू कॉन्ट्रैक्टर के संदर्भ में ऐप प्रतिनिधि में अपनी संचार विधियों को आसानी से कर सकता हूं लेकिन मैं इस तरह की चीज़ को सही तरीके से करना चाहता हूं ।

कृपया निम्नलिखित प्रश्नों के उत्तर देकर "सही कार्य" करने में मेरी मदद करें:

  1. जब मैं UINavigationController स्टैक पर एक नया व्यू-कंट्रोलर पुश करने की कोशिश कर रहा हूं, तो यह पुश कौन करना चाहिए। मेरे कोड में कौन सी कक्षा / फ़ाइल सही जगह है?
  2. जब मैं अपने UIViewControllers में से किसी एक में डेटा के एक टुकड़े (एक iVar के मूल्य) को प्रभावित करना चाहता हूं, जब मैं एक अलग UIViewController में हूं , तो ऐसा करने का "सही" तरीका क्या है?
  3. यह दें कि हमारे पास एक समय में केवल एक प्रतिनिधि सेट किया जा सकता है, जब लेक्चरर "पर्यवेक्षकों (प्रतिनिधिमंडल की तरह) के लिए एक सामान्य इंटरफ़ेस को परिभाषित करता है" तो कार्यान्वयन कैसा दिखेगा । यदि संभव हो तो छद्मकोड उदाहरण यहां मददगार होगा।

इसमें से कुछ को Apple के इस लेख में संबोधित किया गया है - developer.apple.com/library/ios/#featuredarticles/…
जेम्स मूर

बस एक त्वरित टिप्पणी: स्टैनफोर्ड CS193P वर्ग के लिए वीडियो अब iTunes यू के माध्यम से उपलब्ध है। नवीनतम (2012-13) itunes.apple.com/us/course/coding-tately-developing/… पर देखा जा सकता है और मुझे उम्मीद है भविष्य के वीडियो और स्लाइड की घोषणा cs193p.stanford.edu
थॉमस वाटसन

जवाबों:


224

ये अच्छे प्रश्न हैं, और यह देखने के लिए बहुत अच्छा है कि आप इस शोध को कर रहे हैं और यह सीखने के साथ चिंतित हैं कि इसे केवल एक साथ हैक करने के बजाय "इसे सही कैसे करें"।

सबसे पहले , मैं पिछले उत्तरों से सहमत हूं जो उचित (एमवीसी डिजाइन पैटर्न के अनुसार) मॉडल ऑब्जेक्ट्स में डेटा डालने के महत्व पर ध्यान केंद्रित करते हैं। आमतौर पर आप एक नियंत्रक के अंदर राज्य की जानकारी डालने से बचना चाहते हैं, जब तक कि यह डेटा "कड़ाई से" प्रस्तुति न हो।

दूसरा , प्रोग्राम कंट्रोलर पर नेविगेशन कंट्रोलर को प्रोग्रामेटिकली कैसे पुश करें, इसके उदाहरण के लिए स्टैनफोर्ड प्रेजेंटेशन के पेज 10 देखें। इंटरफ़ेस बिल्डर का उपयोग करके यह "नेत्रहीन" कैसे किया जाए, इस उदाहरण के लिए, इस ट्यूटोरियल पर एक नज़र डालें।

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

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

यह मेरी प्रतिक्रिया का सार है। यदि यह सहायक है तो नीचे दिए गए नियंत्रक के साथ निर्भरता इंजेक्शन पैटर्न का उपयोग करने का एक उदाहरण मैं इसमें शामिल करूँगा।

एक दृश्य नियंत्रक के साथ निर्भरता इंजेक्शन का उपयोग करने का उदाहरण

मान लीजिए कि आप एक स्क्रीन बना रहे हैं जिसमें कई किताबें सूचीबद्ध हैं। उपयोगकर्ता उन पुस्तकों को चुन सकता है जिन्हें वह खरीदना चाहता है, और फिर चेकआउट स्क्रीन पर जाने के लिए "चेकआउट" बटन पर टैप करें।

इसे बनाने के लिए, आप एक BookPickerViewController क्लास बना सकते हैं जो GUI / व्यू ऑब्जेक्ट्स को नियंत्रित और प्रदर्शित करता है। यह सभी पुस्तक डेटा कहां मिलेगा? मान लें कि यह उसके लिए बुकवेयरहाउस ऑब्जेक्ट पर निर्भर करता है। तो अब आपका नियंत्रक मूल रूप से एक मॉडल ऑब्जेक्ट (बुकवेयरहाउस) और जीयूआई / दृश्य वस्तुओं के बीच डेटा ब्रोकिंग कर रहा है। दूसरे शब्दों में, BookWarehouse ऑब्जेक्ट पर BookPickerViewController DEPENDS।

ऐसा न करें:

@implementation BookPickerViewController

-(void) doSomething {
   // I need to do something with the BookWarehouse so I'm going to look it up
   // using the BookWarehouse class method (comparable to a global variable)
   BookWarehouse *warehouse = [BookWarehouse getSingleton];
   ...
}

इसके बजाय, निर्भरताओं को इस तरह इंजेक्ट किया जाना चाहिए:

@implementation BookPickerViewController

-(void) initWithWarehouse: (BookWarehouse*)warehouse {
   // myBookWarehouse is an instance variable
   myBookWarehouse = warehouse;
   [myBookWarehouse retain];
}

-(void) doSomething {
   // I need to do something with the BookWarehouse object which was 
   // injected for me
   [myBookWarehouse listBooks];
   ...
}

जब एप्पल के लोग "पदानुक्रम को वापस संवाद करने के लिए" प्रतिनिधि पैटर्न का उपयोग करने के बारे में बात कर रहे हैं, तो वे अभी भी निर्भरता इंजेक्शन के बारे में बात कर रहे हैं। इस उदाहरण में, उपयोगकर्ता को अपनी पुस्तकों को चुनने के बाद BookPickerViewController क्या करना चाहिए और इसकी जांच करने के लिए तैयार है? खैर, यह वास्तव में अपना काम नहीं है। यह उस काम को किसी अन्य वस्तु से हटा देना चाहिए, जिसका अर्थ है कि यह किसी अन्य वस्तु पर निर्भर करता है। इसलिए हम अपनी BookPickerViewController init विधि को निम्नानुसार संशोधित कर सकते हैं:

@implementation BookPickerViewController

-(void) initWithWarehouse:    (BookWarehouse*)warehouse 
        andCheckoutController:(CheckoutController*)checkoutController 
{
   myBookWarehouse = warehouse;
   myCheckoutController = checkoutController;
}

-(void) handleCheckout {
   // We've collected the user's book picks in a "bookPicks" variable
   [myCheckoutController handleCheckout: bookPicks];
   ...
}

इन सबका शुद्ध परिणाम यह है कि आप मुझे अपना BookPickerViewController क्लास (और संबंधित GUI / व्यू ऑब्जेक्ट्स) दे सकते हैं और मैं आसानी से इसे अपने आवेदन में इस्तेमाल कर सकता हूं, यह मानते हुए BookWarehouse और CheckoutController जेनरेटर इंटरफेस हैं (यानी, प्रोटोकॉल) जो मैं लागू कर सकता हूं :

@interface MyBookWarehouse : NSObject <BookWarehouse> { ... } @end
@implementation MyBookWarehouse { ... } @end

@interface MyCheckoutController : NSObject <CheckoutController> { ... } @end
@implementation MyCheckoutController { ... } @end

...

-(void) applicationDidFinishLoading {
   MyBookWarehouse *myWarehouse = [[MyBookWarehouse alloc]init];
   MyCheckoutController *myCheckout = [[MyCheckoutController alloc]init];

   BookPickerViewController *bookPicker = [[BookPickerViewController alloc] 
                                         initWithWarehouse:myWarehouse 
                                         andCheckoutController:myCheckout];
   ...
   [window addSubview:[bookPicker view]];
   [window makeKeyAndVisible];
}

अंत में, न केवल आपका BookPickerController पुन: प्रयोज्य है, बल्कि परीक्षण करने में भी आसान है।

-(void) testBookPickerController {
   MockBookWarehouse *myWarehouse = [[MockBookWarehouse alloc]init];
   MockCheckoutController *myCheckout = [[MockCheckoutController alloc]init];

   BookPickerViewController *bookPicker = [[BookPickerViewController alloc] initWithWarehouse:myWarehouse andCheckoutController:myCheckout];
   ...
   [bookPicker handleCheckout];

   // Do stuff to verify that BookPickerViewController correctly called
   // MockCheckoutController's handleCheckout: method and passed it a valid
   // list of books
   ...
}

19
जब मैं इस तरह के प्रश्नों के साथ (और उत्तर) देखता हूं, तो मुझे इस तरह की देखभाल करनी चाहिए, लेकिन मैं मदद नहीं कर सकता। हमारे निडर प्रश्नकर्ता और आप के लिए अच्छी तरह से योग्य यश !! इस बीच, मैं उस आसान invasivecode.com लिंक के लिए एक अद्यतन लिंक आपके दूसरे बिंदु में संदर्भित करना चाहता था: invasivecode.com/2009/09/… - अपनी अंतर्दृष्टि और सर्वोत्तम प्रथाओं को साझा करने के लिए फिर से धन्यवाद, साथ ही इसे उदाहरणों के साथ समर्थन करना चाहता हूं !
जो

मैं सहमत हूँ। सवाल अच्छी तरह से बना था, और जवाब बस शानदार था। इसके बजाय बस एक तकनीकी जवाब है कि यह भी कैसे / क्यों यह DI का उपयोग कर लागू किया गया है के पीछे कुछ मनोविज्ञान शामिल थे। धन्यवाद! +1 ऊपर।
केविन इलियट

क्या होगा अगर आप भी इच्छा सूची के लिए किताब चुनने के लिए BookPickerController का उपयोग करना चाहते हैं, या कई संभावित बुकिंग कारणों में से एक है। क्या आप अभी भी CheckoutController इंटरफ़ेस दृष्टिकोण (शायद BookSelectionController जैसी किसी चीज़ का नाम बदला है) का उपयोग करेंगे या शायद NSNotificationCenter का उपयोग करें?
Les

यह अभी भी बहुत कसकर युग्मित है। एक केंद्रीकृत जगह से घटनाओं को उठाना और उपभोग करना शिथिल होगा।
नील मैकगिन

1
बिंदु 2 में संदर्भित लिंक फिर से बदल गया लगता है - यहाँ काम कर रहा लिंक invasivecode.com/blog/archives/322
vikmalhotra

15

इस तरह की चीज हमेशा स्वाद की बात होती है।

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

उदाहरण के लिए, मान लीजिए कि मेरे पास एक खाता है जिसमें लेन-देन और लेनदेन हैं। मेरे पास एक AccountListController, एक AccountController (जो "सभी लेनदेन दिखाएं" बटन के साथ एक खाता सारांश प्रदर्शित करता है), एक TransactionListController, और एक TransContController। खाता सूची नियंत्रक सभी खातों की सूची लोड करता है और उन्हें प्रदर्शित करता है। जब आप किसी सूची आइटम पर टैप करते हैं, तो यह अपने खाता नियंत्रक की .count संपत्ति सेट करता है और खाता नियंत्रक को स्टैक पर धकेलता है। जब आप "सभी लेनदेन दिखाएं" बटन पर टैप करते हैं, तो खाता सूची नियंत्रक लेनदेन सूची को लोड करता है, इसे अपनी TransactionListontontroller -transactions संपत्ति में डालता है, और स्टैक पर TransactionListController को धक्का देता है, और इसी तरह।

यदि, कहते हैं, TransactionController लेनदेन को संपादित करता है, तो यह अपने लेनदेन ऑब्जेक्ट में परिवर्तन करता है और फिर अपनी 'सेव' विधि को कॉल करता है। 'save' एक TransactionChangedNotification भेजता है। किसी भी अन्य नियंत्रक को जब लेन-देन में बदलाव करने की आवश्यकता होती है तो वह अधिसूचना को देखता है और खुद को अपडेट करता है। TransactionListController संभवतः; AccountController और AccountListController क्या वे करने की कोशिश कर रहे थे पर निर्भर करता है।

# 1 के लिए, मेरे शुरुआती ऐप्स में मेरे पास किसी प्रकार का डिस्प्लेमॉडल था: withNavigationController: बच्चा नियंत्रक में विधि जो चीजों को सेट करेगी और नियंत्रक को स्टैक पर धक्का देगी। लेकिन जैसा कि मैंने एसडीके के साथ अधिक सहज हो गया है, मैं उससे दूर हो गया हूं, और अब मैं आमतौर पर माता-पिता को बच्चे को धक्का देता हूं।

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

@class Editor;
@protocol EditorDelegate
// called when you're finished.  updated = YES for 'save' button, NO for 'cancel'
- (void)editor:(Editor*)editor finishedEditingModel:(id)model updated:(BOOL)updated;  
@end

// this is an abstract class
@interface Editor : UIViewController {
    id model;
    id <EditorDelegate> delegate;
}
@property (retain) Model * model;
@property (assign) id <EditorDelegate> delegate;

...define methods here...
@end

@interface AmountEditor : Editor
...define interface here...
@end

@interface TextEditor : Editor
...define interface here...
@end

// TransactionController shows the transaction's details in a table view
@interface TransactionController : UITableViewController <EditorDelegate> {
    AmountEditor * amountEditor;
    TextEditor * textEditor;
    Transaction * transaction;
}
...properties and methods here...
@end

और अब TransactionController से कुछ तरीके:

- (void)viewDidLoad {
    amountEditor.delegate = self;
    textEditor.delegate = self;
}

- (void)editAmount {
    amountEditor.model = self.transaction;
    [self.navigationController pushViewController:amountEditor animated:YES];
}

- (void)editNote {
    textEditor.model = self.transaction;
    [self.navigationController pushViewController:textEditor animated:YES];
}

- (void)editor:(Editor*)editor finishedEditingModel:(id)model updated:(BOOL)updated {
    if(updated) {
        [self.tableView reloadData];
    }

    [self.navigationController popViewControllerAnimated:YES];
}

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


1
क्या यह काम करना है? मुझे Editor.delegateसदस्य से परेशानी हो रही है । मेरी viewDidLoadविधि में, मुझे मिल रहा है Property 'delegate' not found...। मुझे यकीन नहीं हो रहा है कि मैंने कुछ और किया है। या अगर यह संक्षिप्तता के लिए निरस्त किया जाता है।
जेफ

यह अब बहुत पुराना कोड है, जो पुरानी परंपराओं के साथ पुरानी शैली में लिखा गया है। मैं इसे सीधे आपके प्रोजेक्ट पर कॉपी और पेस्ट नहीं करूंगा; मैं सिर्फ पैटर्न से सीखने की कोशिश करूँगा।
ब्रेंट रॉयल-गॉर्डन

पकड़ लिया। वह वही है जो मैं जानना चाहता था। मुझे यह कुछ संशोधनों के साथ काम कर रहा था, लेकिन मैं थोड़ा चिंतित था कि यह शब्दशः मेल नहीं खा रहा था।
जेफ

0

मैं तुम्हारी समस्या को देखता हूँ ।।

क्या हुआ है कि किसी ने एमवीसी वास्तुकला के बारे में भ्रमित किया है।

एमवीसी के तीन भाग होते हैं .. मॉडल, विचार और नियंत्रक .. कहा गया समस्या बिना किसी अच्छे कारण के दो संयुक्त है। विचार और नियंत्रक तर्क के अलग टुकड़े हैं।

इसलिए ... आप कई व्यू-कंट्रोलर नहीं रखना चाहते हैं।

आप कई विचार करना चाहते हैं, और एक नियंत्रक जो उनके बीच चयन करता है। (यदि आपके पास कई अनुप्रयोग हैं, तो आपके पास कई नियंत्रक भी हो सकते हैं)

विचार निर्णय नहीं लेने चाहिए। नियंत्रक (ओं) को ऐसा करना चाहिए। इसलिए कार्यों का विभाजन, और तर्क, और आपके जीवन को आसान बनाने के तरीके।

तो .. सुनिश्चित करें कि आपका दृष्टिकोण बस यही करता है, डेटा का एक अच्छा veiv डालता है। अपने नियंत्रक को यह तय करने दें कि डेटा का क्या करना है, और कौन सा उपयोग करना है।

(और जब हम डेटा के बारे में बात करते हैं, तो हम मॉडल के बारे में बात कर रहे हैं ... एक अच्छा मानक तरीका है स्टोर किया गया, एक्सेस किया गया, संशोधित किया गया। तर्क का एक और अलग टुकड़ा जिसे हम दूर कर सकते हैं और भूल सकते हैं)


0

मान लीजिए कि दो वर्ग A और B हैं।

कक्षा ए का उदाहरण है

एक आभामंडल;

वर्ग A बनाता है और वर्ग B का उदाहरण, जैसा है

बी bInstance;

और कक्षा बी के अपने तर्क में, कहीं न कहीं आपको कक्षा ए की विधि को संप्रेषित करने या ट्रिगर करने की आवश्यकता होती है।

1) गलत तरीके से

आप इनस्टॉल को bInstance पास कर सकते हैं। अब वांछित स्थान की कॉल को [इनस्टेंस मेथडनाम] को bInstance में वांछित स्थान से रखें।

इससे आपका उद्देश्य पूरा हो जाता, लेकिन रिलीज के समय एक मेमोरी बंद हो जाती और मुक्त नहीं होती।

कैसे?

जब आपने bInstance के लिए aInstance पास किया, तो हमने anInstance के 1. को बढ़ा दिया। जब bInstance को डील करते हैं, तो हम मेमोरी को ब्लॉक कर देंगे, क्योंकि anInstance को b के लिए 0 में कभी नहीं लाया जा सकता है। bststance का कारण है कि bInstance अपने आप में एक Instance का ऑब्जेक्ट है।

इसके अलावा, Instance के अटक जाने के कारण, bInstance की मेमोरी भी अटक जाएगी (लीक हो जाएगी)। इसलिए जब कभी भी इसका समय बाद में आने पर एनस्टांस से निपटने के बाद भी, इसकी मेमोरी भी अवरुद्ध हो जाएगी क्योंकि BInstance कठबोली को मुक्त किया जा सकता है और BInstance, InInstance का एक वर्ग चर है।

२) सही तरीका

InInstance को bInstance के प्रतिनिधि के रूप में परिभाषित करने से, किसी भी बदलाव को या InInstance के मेमोरी उलझाव को नहीं बदला जाएगा।

bInstance स्वतंत्र रूप से InInance में पड़े प्रतिनिधि तरीकों को लागू करने में सक्षम होगा। BInstance के डिक्लोकेशन पर, सभी वैरिएबल अपने स्वयं के बनाए जाएंगे और इसे InInstance के डिक्लोकेशन पर जारी किया जाएगा, क्योंकि bInstance में किसी Instance का कोई उलझाव नहीं है, इसे साफ़-सुथरा रिलीज़ किया जाएगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.