🍻 🐤 🗣️ शॉकिंग ऑब्जेक्टिव-सी फॉर जावा प्रोग्रामर्स, पार्ट टू 🤱🏼 🥢 🔜

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

पूर्णता तब नहीं होती है जब जोड़ने के लिए कुछ नहीं होता है, लेकिन जब लेने के लिए कुछ नहीं होता है

जैसा कि पहले भाग में टिप्पणियों में बोबरमैनियाक को सही ढंग से नोट किया गया था - वाक्यविन्यास बहुत महत्वपूर्ण नहीं है, भाषा के मुहावरों को समझना अधिक महत्वपूर्ण है। भाषा निर्माण के सामान्य सिद्धांतों, इसके दर्शन को समझना भी उतना ही महत्वपूर्ण है। थरथराहट अपने आप धूमधाम से आती है।

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

ब्रैड कॉक्स पूरी तरह से नई भाषा बनाए बिना C में स्मॉलटॉक फीचर जोड़ना चाहते थे। वह सफल हुआ और उसने जो ऑब्जेक्टिव-सी बनाया, वह सी भाषा का सुपरसेट है, जो ऑब्जेक्ट एक्सटेंशन में इसके डिजाइन की भावना को संरक्षित करता है। यानी सी भाषा को वैसे ही छोड़ दिया जाता है, वस्तु-उन्मुख नवाचार स्पष्ट रूप से परिभाषित सीमाओं के भीतर किए जाते हैं और उनमें से कई नहीं होते हैं। क्या यह उद्देश्य-सी के असामान्य सिंटैक्स की आंशिक व्याख्या करता है? ये सभी [] और @ वे पीले रिबन हैं जो निर्माण क्षेत्र को घेरते हैं (या पीले रिबन केवल अपराध स्थल पर ही हैं?)। अतिसूक्ष्मवाद का एक विशिष्ट उदाहरण यह है कि ऑब्जेक्टिव-सी में ऑब्जेक्ट बनाने के लिए एक विशेष सिंटैक्स भी नहीं है, जैसे कि एक कंस्ट्रक्टर और डिस्ट्रक्टर को परिभाषित करने के लिए कोई नहीं है। आबंटित, init, new, dealloc के तरीके भाषा का हिस्सा नहीं हैं, बल्कि फ्रेमवर्क का हिस्सा हैं।

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

अब, चलो जावा प्रोग्रामर को सावधानी से देखें और व्यावहारिक मुद्दों पर विचार करें।

क्या आपके पास आई.डी.

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

ऑब्जेक्टिव-सी में एक आईडी प्रकार भी है - किसी भी वर्ग की वस्तु के लिए एक सार्वभौमिक संदर्भ। यदि एक जावा प्रोग्रामर ने सोचा कि यह एक ऑब्जेक्ट के संदर्भ की तरह है, तो वह गलत है। यदि सी प्रोग्रामर ने सोचा कि यह शून्य की तरह है * , तो वह गलत है। संकलक आईडी को किसी भी वर्ग की वस्तु के संदर्भ में ठीक मानता है। आप किसी भी वर्ग के किसी भी पहले से परिभाषित विधि को कॉल कर सकते हैं (लेकिन यदि विधि परिभाषित नहीं है, तो आप नहीं कर सकते हैं), किसी भी वर्ग के ऑब्जेक्ट को बिना कास्टिंग के असाइन करें, आदि। केवल सीमा यह है कि आप वस्तुओं के क्षेत्र तक नहीं पहुँच सकते।

एक बार फिर, मैं पिछले लेख से कक्षाओं की संरचना को याद करता हूं

@interface Profile : NSObject @property (readonly) int version; @end @interface Feature : NSObject - (Profile*) getProfile:(NSString*)name; @end @interface Phone : NSObject + (Phone*) designAndProduce:(NSString*)name; -(Feature*) getFeature:(NSString*)name; @end

अब आईडी का उपयोग करने के कुछ उदाहरण:

 //   id idPtr = [Phone designAndProduce:@"iphone5"]; //    Phone* anotherPhone = idPtr; //    (     ) Feature* badFeature = idPtr; //   -  ,   getFeture      Feature* anotherBadFeature = [idPtr getFeture:@"bt"]; //    Feature* btFeature = [idPtr getFeature:@"bt"]; //   ,  ,   ,   Profile* profile = [idPtr getProfile:@"a2dp"];

बाद के मामले में, जब प्रोग्राम शुरू करते हैं, तो हमें एक त्रुटि संदेश मिलता है: बिना किसी अपवाद के SI NSInvalidArgumentException ’अपवाद के कारण ऐप समाप्त करना, कारण:’ - [फोन getProfile:]: re 0x100114510 ’उदाहरण के लिए भेजा गया अज्ञात पहचानकर्ता
और संदेश भेजने के काम को समझने की थोड़ी बेहतर शुरुआत करें।

प्लास्टिक या कागज?

अमेरिकी सुपरमार्केट में कैशियर से एक और अच्छा सवाल। वे पूछते हैं कि कौन सा पैकेज देना है, लेकिन पहली बार बहुत कम लोग अनुमान लगाते हैं।

तो, संकुल के बारे में। जावा प्रोग्रामर के लिए बुरी खबर - पैकेज यहां नहीं हैं। कोई नामस्थान प्रबंधन तंत्र नहीं हैं। आप केवल यह चुन सकते हैं कि कौन सी हेडर फ़ाइलों को शामिल करना है और कौन सी नहीं। C के न्यूनतावाद और उद्देश्य-C के लेखकों के रूढ़िवाद को धन्यवाद कहें। नाम संघर्ष से बचने के लिए, उपसर्गों की सिफारिश की जाती है। उदाहरण के लिए, NSObject वर्ग नाम में NS, NeXT के नेक्स्टस्टेप OS के लिए विकसित की गई कक्षाओं का एक उपसर्ग है। बाद में स्टीव जॉब्स द्वारा Apple में काम करने और Apple में काम करने के बीच अंतराल में स्थापित किया गया था।

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

आधे उपाय कभी-कभी उपयोगी होते हैं - @क्लास निर्देश आपको इसे परिभाषित किए बिना एक वर्ग घोषित करने की अनुमति देता है।

 @class Profile @interface Feature : NSObject - (Profile*) getProfile:(NSString*)name; @end

इस मामले में, हम संकलक को आश्वस्त करते हैं कि ऐसी कक्षा मौजूद है और यह हमारे कोड को संकलित करने के लिए सहमत है। क्योंकि संकलक को अभी भी कक्षा की संरचना के बारे में कुछ नहीं पता है, इस वर्ग की वस्तुओं को संदेश भेजने से संकलन त्रुटि हो जाएगी। लेकिन यह आमतौर पर आवश्यक नहीं है, क्योंकि आमतौर पर हेडर फ़ाइलों में निर्देश का उपयोग किया जाता है। सवाल उठता है - अगर आपको #import के साथ मिल सकता है तो इसकी आवश्यकता क्यों है? आमतौर पर बड़ी परियोजनाओं में संकलन का अनुकूलन करने के लिए, जैसा कि आयात कोड की मात्रा को बढ़ा सकता है और, तदनुसार, संकलन समय। दूसरा कारण वर्गों के बीच चक्रीय संदर्भ है।

निष्कर्ष

मुझे आशा है कि पढ़ने के बाद एकमात्र प्रश्न बचा है कि अमेरिकी सुपरमार्केट को इसके साथ क्या करना है? मुझे नहीं पता, बस इस तरह की अधीनताएं निकलीं।

शॉकिंग ऑब्जेक्टिव-सी फॉर जावा प्रोग्रामर्स, पार्ट टू

पूर्णता तब नहीं होती है जब जोड़ने के लिए कुछ नहीं होता है, लेकिन जब लेने के लिए कुछ नहीं होता है

क्या आपके पास आई.डी.

प्लास्टिक या कागज?

निष्कर्ष

More articles: