Objective-C की C # से तुलना कैसे होती है? [बन्द है]

Question 1

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

8 साल पहले बंद हुआ ।

मैंने हाल ही में एक मैक खरीदा है और VMWare फ्यूजन के तहत मुख्य रूप से C # विकास के लिए इसका उपयोग करता हूं। सभी अच्छे मैक अनुप्रयोगों के साथ मैंने Xcode के बारे में सोचना शुरू कर दिया है बस एक क्लिक दूर है, और ऑब्जेक्टिव-सी सीख रहा है।

दो भाषाओं के बीच का सिंटैक्स बहुत अलग दिखता है, संभवतः क्योंकि C-C में ऑब्जेक्टिव-सी की उत्पत्ति है और जावा / सी ++ में इसकी उत्पत्ति है। लेकिन अलग-अलग वाक्यविन्यास सीखे जा सकते हैं ताकि ठीक हो।

मेरी मुख्य चिंता भाषा के साथ काम करना है और अगर यह अच्छी तरह से संरचित, पठनीय और सुरुचिपूर्ण कोड का उत्पादन करने में मदद करेगी। मैं वास्तव में C # में LINQ और var जैसी सुविधाओं का आनंद लेता हूं और आश्चर्य करता हूं कि क्या Objective-C में समकक्ष या बेहतर / विभिन्न विशेषताएं हैं।

ऑब्जेक्टिव-सी के साथ मैं कौन सी भाषा सुविधाएँ विकसित करने से चूकूंगा? मुझे क्या सुविधाएँ मिलेंगी?

संपादित करें: ढांचा तुलना उपयोगी और दिलचस्प है लेकिन एक भाषा तुलना यह है कि यह प्रश्न वास्तव में क्या पूछ रहा है (मूल रूप से मेरे साथ टैगिंग के लिए मेरी गलती है .net)। संभवतः कोको और .NET दोनों ही अपने आप में बहुत समृद्ध फ्रेमवर्क हैं और दोनों का उद्देश्य है, एक मैक ओएस एक्स और दूसरा विंडोज को लक्षित करना।

अब तक सुविचारित और यथोचित संतुलित दृष्टिकोण के लिए धन्यवाद!

Question 2

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

( नोट: जिस प्रकार C # को कसकर .NET से जोड़ दिया जाता है, Objective-C को कोको से कसकर जोड़ दिया जाता है। इसलिए, मेरे कुछ बिंदु ऑब्जेक्टिव-C से असंबंधित लग सकते हैं, लेकिन Coco के बिना Objective-C, .NET के बिना C # के समान है। WPF / LINQ, मोनो के तहत चल रहा है, आदि। यह सिर्फ चीजें नहीं हैं जिस तरह से आमतौर पर किया जाता है।)

मैं मतभेदों, पेशेवरों और विपक्षों को पूरी तरह से विस्तृत करने का नाटक नहीं करूंगा, लेकिन यहां कुछ ऐसे हैं जो दिमाग में आते हैं।

ऑब्जेक्टिव-सी के सबसे अच्छे हिस्सों में से एक गतिशील प्रकृति है - कॉलिंग के तरीकों के बजाय, आप संदेश भेजते हैं, जो रनटाइम को गतिशील रूप से रूट करता है। संयुक्त (विवेकपूर्ण) गतिशील टाइपिंग के साथ, यह बहुत सारे शक्तिशाली पैटर्न को सरल या लागू करने के लिए तुच्छ बना सकता है।
C के एक सख्त सुपरसेट के रूप में, Objective-C भरोसा करता है कि आप जानते हैं कि आप क्या कर रहे हैं। C # और Java जैसी भाषाओं के प्रबंधित और / या प्रकार के दृष्टिकोण के विपरीत, Objective-C आपको वह करने देता है जो आप चाहते हैं और परिणाम अनुभव करते हैं। जाहिर है कि यह कई बार खतरनाक हो सकता है, लेकिन यह तथ्य कि भाषा सक्रिय रूप से आपको ज्यादातर चीजें करने से नहीं रोकती है, काफी शक्तिशाली है। ( EDIT: मुझे स्पष्ट करना चाहिए कि C # में "असुरक्षित" विशेषताएं और कार्यक्षमता भी हैं, लेकिन वे डिफ़ॉल्ट व्यवहार प्रबंधित कोड हैं, जिन्हें आपको स्पष्ट रूप से चुनना होगा। तुलनात्मक रूप से, जावा केवल प्रकार कोड के लिए अनुमति देता है, और कभी भी कच्चे पॉइंटर्स को उजागर नहीं करता है। जिस तरह से C और अन्य करते हैं।)
श्रेणियाँ (उपवर्ग या स्रोत तक पहुंच के बिना एक वर्ग पर तरीकों को जोड़ना / संशोधित करना) एक भयानक दोधारी तलवार है। यह वंशानुगत पदानुक्रम को काफी हद तक सरल कर सकता है और कोड को समाप्त कर सकता है, लेकिन यदि आप कुछ अजीब करते हैं, तो परिणाम कभी-कभी चकरा देने वाले हो सकते हैं।
कोको कई तरह से GUI ऐप बनाता है, लेकिन आपको अपने सिर को प्रतिमान के चारों ओर लपेटना होगा। MVC डिज़ाइन कोको में व्यापक है, और प्रतिनिधि, सूचना और मल्टी-थ्रेडेड GUI ऐप्स जैसे पैटर्न, उद्देश्य-सी के लिए अच्छी तरह से अनुकूल हैं।
कोको बाइंडिंग और की-वैल्यू ऑब्ज़र्विंग टन को गोंद कोड को खत्म कर सकता है, और कोको फ्रेमवर्क इस बड़े पैमाने पर लाभ उठाते हैं। ऑब्जेक्टिव-सी का डायनेमिक डिस्पैच इसके साथ हाथ से काम करता है, इसलिए ऑब्जेक्ट का प्रकार तब तक मायने नहीं रखता है जब तक कि यह कुंजी-मूल्य के अनुरूप हो।
आप संभवतः जेनेरिक और नेमस्पेस को याद करेंगे, और उनके पास उनके लाभ होंगे, लेकिन ऑब्जेक्टिव-सी मानसिकता और प्रतिमान में, वे आवश्यकता के बजाय उपनाम होंगे। (जेनरिक सभी प्रकार की सुरक्षा के बारे में हैं और कास्टिंग से परहेज करते हैं, लेकिन ऑब्जेक्टिव-सी में डायनेमिक टाइपिंग इसे अनिवार्य रूप से गैर-मुद्दा बना देता है। यदि अच्छा किया जाए तो नाम स्थान अच्छा होगा, लेकिन संघर्षों से बचने के लिए यह काफी सरल है कि लागत यकीनन लाभ को बढ़ा देती है। विरासत कोड के लिए।)
संगामिति के लिए, ब्लॉक (स्नो लेपर्ड में एक नई भाषा की सुविधा, और कोको एपीआई के स्कोर में लागू) बेहद उपयोगी हैं। कुछ पंक्तियों (अक्सर ग्रैंड सेंट्रल डिस्पैच के साथ युग्मित, जो 10.6 पर लिबास सिस्टम का हिस्सा है) कॉलबैक फ़ंक्शंस, संदर्भ आदि की महत्वपूर्ण बॉयलरप्लेट को समाप्त कर सकता है (ब्लॉक को सी और सी ++ में भी इस्तेमाल किया जा सकता है, और निश्चित रूप से सी # में जोड़ा जा सकता है) जो भयानक होगा।) NSOperationQueue भी कस्टम कोड NSOperation उपवर्ग या अनाम ब्लॉक, जो GCD आपके लिए एक या एक से अधिक अलग-अलग धागे पर स्वचालित रूप से निष्पादित करता है, को भेजकर अपने स्वयं के कोड को जोड़ने के लिए एक बहुत ही सुविधाजनक तरीका है।

Question 3

मैं C, C ++ और C # में 20 से अधिक वर्षों से प्रोग्रामिंग कर रहा हूं, पहली बार 1990 में शुरू हुआ था। मैंने अभी iPhone विकास और Xcode और ऑब्जेक्टिव-सी पर एक नजर डालने का फैसला किया है। ओह माय गुडनेस ... माइक्रोसॉफ्ट के बारे में सभी शिकायतें मैं वापस लेता हूं, मुझे अब महसूस होता है कि कोड कितना खराब है। सी # क्या करता है की तुलना में उद्देश्य-सी जटिल है। मुझे C # के साथ खराब कर दिया गया है और अब मैं उन सभी कड़ी मेहनत की सराहना करता हूं जो Microsoft ने लगाई हैं। बस विधि इनवेसिव-सी को विधि इनवोकस के साथ पढ़ना मुश्किल है। इसमें C # सुरुचिपूर्ण है। यह सिर्फ मेरी राय है, मुझे आशा थी कि Apple विकास भाषा Apple उत्पादों के रूप में अच्छी थी, लेकिन प्रिय मुझे, उन्हें Microsoft से बहुत कुछ सीखना है। कोई सवाल नहीं है C # .NET एप्लिकेशन मैं XCode ऑब्जेक्टिव-सी की तुलना में कई गुना तेजी से एक आवेदन प्राप्त कर सकता है। Apple को निश्चित रूप से यहाँ Microsoft की पुस्तक से एक पत्ता निकालना चाहिए और फिर हमारे पास सही वातावरण होगा। :-)

Question 4

यहां कोई तकनीकी समीक्षा नहीं है, लेकिन मुझे सिर्फ ऑब्जेक्टिव-सी बहुत कम पढ़ने योग्य लगता है। Cinder6 ने आपको जो उदाहरण दिया है, उसे देखते हुए:

सी#

List<string> strings = new List<string>();
strings.Add("xyzzy");                  // takes only strings
strings.Add(15);                       // compiler error
string x = strings[0];                 // guaranteed to be a string
strings.RemoveAt(0);                   // or non-existant (yielding an exception)

उद्देश्य सी

NSMutableArray *strings = [NSMutableArray array];
[strings addObject:@"xyzzy"];
[strings addObject:@15];
NSString *x = strings[0];
[strings removeObjectAtIndex:0];

यह भयानक लग रहा है। मैंने इस पर 2 किताबें पढ़ने की भी कोशिश की, उन्होंने मुझे जल्दी खो दिया, और आम तौर पर मुझे प्रोग्रामिंग किताबें / भाषाएं नहीं मिलतीं।

मुझे खुशी है कि हमारे पास मैक ओएस के लिए मोनो है, क्योंकि अगर मुझे एक अच्छा विकास वातावरण देने के लिए Apple पर भरोसा करना पड़ता ...

Question 5

मैनुअल मेमोरी मैनेजमेंट कुछ शुरुआती है जिसका उद्देश्य ऑब्जेक्टिव-सी के साथ सबसे अधिक समस्या है, ज्यादातर इसलिए क्योंकि उन्हें लगता है कि यह इसके मुकाबले अधिक जटिल है।

उद्देश्य-सी और कोकोआ विस्तार द्वारा प्रवर्तन पर निर्भरता पर निर्भर करता है; नियमों का एक बहुत छोटा सेट को जानें और उसका पालन करें और बदले में गतिशील रन-टाइम द्वारा आपको मुफ्त में बहुत कुछ मिलता है।

100% सही नियम नहीं, बल्कि हर रोज़ के लिए पर्याप्त है:

हर कॉल को वर्तमान स्कोप के अंत में allocमेल खाना चाहिए release।
यदि आपकी विधि के लिए रिटर्न वैल्यू allocतब तक प्राप्त कर ली गई है, तो उसे return [value autorelease];ए से मैच होने के बजाय वापस कर देना चाहिए release।
गुणों का उपयोग करें, और कोई नियम तीन नहीं है।

लंबी व्याख्या इस प्रकार है।

स्मृति प्रबंधन स्वामित्व पर आधारित है; केवल एक वस्तु उदाहरण के मालिक कभी वस्तु जारी करना चाहिए, हर कोई किसी और हमेशा कुछ भी नहीं करना चाहिए। इसका मतलब यह है कि 95% सभी कोड में आप ऑब्जेक्टिव-सी का इलाज करते हैं जैसे कि यह कचरा एकत्र किया गया हो।

तो अन्य 5% के बारे में क्या? आपके पास देखने के लिए तीन विधियाँ हैं, इन विधियों से प्राप्त किसी भी वस्तु का उदाहरण वर्तमान विधि क्षेत्र के स्वामित्व में है :

alloc
नए शब्द से शुरू होने वाली कोई भी विधि , जैसे कि newया newService।
किसी भी तरीके की शब्द प्रति, जैसे कि copyऔर mutableCopy।

इस विधि के तीन संभावित विकल्प हैं जैसे कि इसके बाहर निकलने से पहले इसके स्वामित्व वाली वस्तु के साथ क्या करना है:

releaseअगर जरूरत नहीं है तो इसका इस्तेमाल करके इसे रिलीज करें ।
किसी क्षेत्र (उदाहरण चर) , या बस इसे असाइन करके एक वैश्विक चर का स्वामित्व दें ।
स्वामित्व को त्यागें, लेकिन उदाहरण के लिए कॉल करने से पहले किसी और को स्वामित्व लेने का मौका दें autorelease।

तो आपको सक्रिय रूप से कॉल करके स्वामित्व कब लेना चाहिए retain? दो मामले:

अपने इनिशियलाइज़र में फ़ील्ड असाइन करते समय।
जब मैन्युअल रूप से सेटर विधि को लागू करना।

Question 6

निश्चित रूप से, यदि आपने अपने जीवन में जो कुछ भी देखा है वह वस्तुनिष्ठ सी है, तो इसका सिंटैक्स एकमात्र संभव जैसा दिखता है। हम आपको "प्रोग्रामिंग वर्जिन" कह सकते हैं।

लेकिन चूंकि बहुत से कोड C, C ++, Java, जावास्क्रिप्ट, पास्कल और अन्य भाषाओं में लिखे गए हैं, आप देखेंगे कि ObjectiveC उन सभी से अलग है, लेकिन अच्छे तरीके से नहीं। क्या उनके पास इसका कोई कारण था? आइए देखें अन्य लोकप्रिय भाषाएँ:

C ++ ने C में बहुत अधिक अतिरिक्त जोड़े, लेकिन इसने मूल सिंटैक्स को केवल आवश्यकतानुसार बदल दिया।

C # ने C ++ की तुलना में बहुत अधिक एक्सट्रैस जोड़े लेकिन यह केवल उन चीजों को बदल दिया जो C ++ में बदसूरत थे (जैसे इंटरफ़ेस से "::" को निकालना)।

जावा ने बहुत सी चीजों को बदल दिया, लेकिन इसमें उन हिस्सों को छोड़कर परिचित सिंटैक्स रखा गया जहां परिवर्तन की आवश्यकता थी।

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

Visual Basic, ObjectiveC की तरह ही पैरामीटर को क्रम से बाहर कर सकता है। आप मापदंडों को नाम दे सकते हैं, लेकिन आप उन्हें नियमित रूप से भी पारित कर सकते हैं। जो भी आप उपयोग करते हैं, वह सामान्य अल्पविराम-सीमांकित तरीका है जिसे हर कोई समझता है। केवल प्रोग्रामिंग भाषाओं में ही नहीं, बल्कि पुस्तकों, समाचार पत्रों और सामान्य रूप से लिखित भाषा में कोमा सामान्य परिसीमन है।

ऑब्जेक्ट पास्कल में C की तुलना में एक अलग सिंटैक्स है, लेकिन इसका सिंटैक्स वास्तव में प्रोग्रामर के लिए पढ़ने के लिए आसान है (शायद कंप्यूटर के लिए नहीं, लेकिन जो कंप्यूटर को लगता है कि परवाह करता है)। इसलिए शायद वे पचा गए, लेकिन कम से कम उनका परिणाम बेहतर है।

पायथन में एक अलग वाक्यविन्यास है, जो पास्कल की तुलना में (मनुष्यों के लिए) पढ़ना आसान है। इसलिए जब उन्होंने इसे बदल दिया, तो इसे अलग बना दिया, कम से कम उन्होंने इसे हमारे प्रोग्रामर के लिए बेहतर बना दिया।

और फिर हमारे पास ObjectiveC है। C में कुछ सुधार जोड़ रहे हैं, लेकिन अपने स्वयं के इंटरफ़ेस सिंटैक्स, विधि कॉलिंग, पैरामीटर पासिंग और क्या नहीं का आविष्कार कर रहे हैं। मुझे आश्चर्य है कि उन्होंने + और - को स्वैप क्यों नहीं किया ताकि प्लस दो संख्याओं को घटाए। यह और भी अच्छा होता।

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

मुझे यकीन है कि iPhone के लिए और भी अधिक ऐप होंगे अगर उसने iOS और लेखन पुस्तकालयों को ObjectiveC के अलावा किसी अन्य भाषा में लिखने का फैसला किया। डाई-हार्ड प्रशंसकों, वर्जिन प्रोग्रामर और स्टीव जॉब्स को छोड़कर सभी के लिए, ObjectiveC हास्यास्पद, बदसूरत और प्रतिकारक दिखता है।

Question 7

एक चीज जो मुझे ऑब्जेक्टिव-सी के बारे में पसंद है, वह यह है कि ऑब्जेक्ट सिस्टम संदेशों पर आधारित है, यह आपको वास्तव में अच्छी चीजें करने देता है जो आप C # में नहीं कर सकते (कम से कम तब तक नहीं जब तक वे डायनामिक कीवर्ड का समर्थन नहीं करते!)।

कोको एप्लिकेशन लिखने के बारे में एक और बड़ी बात इंटरफ़ेस बिल्डर है, यह विज़ुअल स्टूडियो में फॉर्म डिजाइनर की तुलना में बहुत अच्छा है।

ओब्ज-सी के बारे में चीजें जो मुझे परेशान करती हैं (एक सी # डेवलपर के रूप में) यह तथ्य है कि आपको अपनी खुद की मेमोरी का प्रबंधन करना होगा (इसमें कचरा संग्रह है, लेकिन यह आईफोन पर काम नहीं करता है) और यह बहुत क्रिया हो सकती है क्योंकि चयनकर्ता वाक्य रचना और सभी []।

Question 8

एक प्रोग्रामर के रूप में सिर्फ iPhone के लिए ऑब्जेक्टिव-सी के साथ शुरुआत करना, C # 4.0 से आना, मुझे लैम्ब्डा एक्सप्रेशन याद आ रहे हैं, और विशेष रूप से, लिनक-टू-एक्सएमएल। लैम्ब्डा के भाव C # -स्पेशल हैं, जबकि Linq-to-XML वास्तव में .NET बनाम कोको कंट्रास्ट से अधिक है। एक नमूना एप्लिकेशन में मैं लिख रहा था, मेरे पास एक स्ट्रिंग में कुछ एक्सएमएल था। मैं वस्तुओं के संग्रह में उस XML के तत्वों को पार्स करना चाहता था।

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

इसके विपरीत, यहाँ C # में कोड है:

using System.Linq.Xml;
XDocument doc = XDocument.Load(xmlString);
IEnumerable<MyCustomObject> objects = doc.Descendants().Select(
         d => new MyCustomObject{ Name = d.Value});

और यह बात है, आपको XML से खींची गई कस्टम ऑब्जेक्ट्स का एक संग्रह मिला है। यदि आप उन तत्वों को मान से फ़िल्टर करना चाहते हैं, या केवल उन लोगों के लिए जो एक विशिष्ट विशेषता रखते हैं, या यदि आप पहले 5 चाहते थे, या पहले 1 को छोड़ दें और अगले 3 को प्राप्त करें, या बस पता करें कि क्या कोई तत्व वापस आ गए थे ... BAM, कोड की एक ही पंक्ति में सब ठीक है।

कई ओपन-सोर्स क्लासेस हैं जो इस प्रोसेसिंग को ऑब्जेक्टिव-सी में बहुत आसान बनाते हैं, जिससे भारी लिफ्टिंग होती है। यह सिर्फ इस में निर्मित नहीं है।

* नोट: मैं वास्तव में ऊपर दिए गए कोड को संकलित नहीं करता था, यह सिर्फ C # के लिए आवश्यक क्रियात्मकता के सापेक्ष अभाव को स्पष्ट करने के लिए एक उदाहरण के रूप में है।

Question 9

संभवतः सबसे महत्वपूर्ण अंतर मेमोरी प्रबंधन है। C # के साथ आपको कचरा संग्रह मिलता है, इसके आधार पर यह CLR आधारित भाषा है। ऑब्जेक्टिव-सी के साथ आपको खुद मेमोरी को मैनेज करना होगा।

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

Question 10

यहाँ दो भाषाओं की तुलना करने वाला एक बहुत अच्छा लेख है: http://www.coderetard.com/2008/03/16/c-vs-objects-c/

Question 11

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

जहाँ तक संरचित, पठनीय संहिता का संबंध है, वहाँ का अधिकांश भार प्रोग्रामर के पास होता है, जैसा कि किसी अन्य भाषा में होता है। हालांकि, मुझे पता है कि प्रतिमान पारित होने वाला संदेश पढ़ने योग्य कोड के लिए अच्छी तरह से उधार देता है, बशर्ते आप अपने कार्यों / विधियों को उचित रूप से नाम दें (फिर से, किसी अन्य भाषा की तरह)।

मैं पहली बार मानता हूँ कि मैं C # या .NET से बहुत परिचित नहीं हूँ। लेकिन जिन कारणों से क्विन ऊपर सूचीबद्ध किया गया है, वे कुछ कारण हैं जो मुझे ऐसा बनने की परवाह नहीं है।

Question 12

ओबज-सी में प्रयुक्त विधि कॉल आसानी से पढ़ने के लिए कोड बनाते हैं, मेरी राय में सी # की तुलना में बहुत अधिक सुरुचिपूर्ण है और ओज-सी ग के शीर्ष पर बनाया गया है, इसलिए सभी सी कोड को ओबज-सी में ठीक काम करना चाहिए। मेरे लिए बड़ा विक्रेता हालांकि यह है कि obj-c एक खुला मानक है जिससे आप किसी भी सिस्टम के लिए कंपाइलर पा सकते हैं।