Objective-C, C # ile nasıl karşılaştırılır? [kapalı]

Yakın zamanda bir Mac satın aldım ve bunu öncelikle VMWare Fusion altında C # geliştirme için kullanıyorum. Etrafımdaki tüm güzel Mac uygulamalarıyla, Xcode'un yalnızca bir yükleme tıklaması ötede gizlendiğini ve Objective-C'yi öğrenmeyi düşünmeye başladım.

İki dil arasındaki sözdizimi çok farklı görünüyor, çünkü muhtemelen Objective-C'nin kökenleri C'ye ve C #'nin kökenleri Java / C ++ 'dır. Ancak farklı sözdizimleri öğrenilebilir, bu yüzden sorun olmaz.

Asıl endişem, dille çalışmak ve iyi yapılandırılmış, okunabilir ve zarif bir kod üretmeye yardımcı olup olmayacağıdır. LINQ ve C # 'da var gibi özelliklerden gerçekten keyif alıyorum ve Objective-C'de eşdeğer veya daha iyi / farklı özellikler olup olmadığını merak ediyorum.

Objective-C ile hangi dil özelliklerini geliştirmeyi özleyeceğim? Hangi özellikleri kazanacağım?

Düzenleme: Çerçeve karşılaştırmaları yararlı ve ilgi çekicidir, ancak bir dil karşılaştırması bu sorunun gerçekten sorduğu şeydir (kısmen, başlangıçta etiketleme konusunda benim hatam .net). Muhtemelen hem Cocoa hem de .NET, kendi başlarına çok zengin çerçevelerdir ve her ikisinin de amacı vardır, biri Mac OS X'i ve diğerini Windows'u hedeflemektedir.

Şimdiye kadarki iyi düşünülmüş ve makul ölçüde dengeli bakış açıları için teşekkür ederiz!

Hiçbir dil tüm görevler için mükemmel değildir ve Objective-C bir istisna değildir, ancak bazı çok özel nitelikler vardır. Kullanmak gibi LINQve var(bunun için doğrudan değiştirildiğini bilmiyorum), bunlardan bazıları kesinlikle dil ile ilgili, diğerleri ise çerçeveyle ilgilidir.

( NOT: C # .NET ile sıkı bir şekilde birleştirildiği gibi, Objective-C de Cocoa ile sıkı bir şekilde birleştirilir. Bu nedenle, bazı noktalarım Objective-C ile ilgisiz görünebilir, ancak Cocoa'sız Objective-C, .NET olmadan C # ile benzerdir / WPF / LINQ, Mono altında çalışıyor vb. İşler genellikle böyle yapılmaz.)

Farklılıkları, artıları ve eksileri tam olarak detaylandırıyormuş gibi yapmayacağım, ama işte akla gelen bazı şeyler.

• Objective-C'nin en iyi bölümlerinden biri dinamik doğasıdır - yöntemleri çağırmak yerine, çalışma zamanının dinamik olarak yönlendirdiği mesajlar gönderirsiniz. Dinamik yazımla (mantıklı bir şekilde) birleştirildiğinde, bu birçok güçlü kalıbı daha basit ve hatta uygulanması önemsiz hale getirebilir.

• C'nin katı bir üst kümesi olan Objective-C, ne yaptığınızı bildiğinize güveniyor. C # ve Java gibi dillerin yönetilen ve / veya dizgi güvenli yaklaşımının aksine, Objective-C, istediğinizi yapmanıza ve sonuçlarını deneyimlemenize izin verir. Açıkçası bu bazen tehlikeli olabilir, ancak dilin çoğu şeyi yapmanıza aktif olarak engel olmaması gerçeği oldukça güçlüdür. ( DÜZENLEME: C # 'ın "güvenli olmayan" özelliklere ve işlevlere de sahip olduğunu açıklığa kavuşturmalıyım, ancak bunların varsayılan davranışı, açıkça devre dışı bırakmanız gereken yönetilen koddur. Karşılaştırıldığında, Java yalnızca tür güvenli koda izin verir ve ham işaretçileri hiçbir zaman C ve diğerlerinin yaptığı gibi.)

• Kategoriler (alt sınıflara girmeden veya kaynağa erişmeden bir sınıfa yöntemler eklemek / değiştirmek) harika bir iki ucu keskin kılıçtır. Devralma hiyerarşilerini büyük ölçüde basitleştirebilir ve kodu ortadan kaldırabilir, ancak tuhaf bir şey yaparsanız, sonuçlar bazen şaşırtıcı olabilir.

• Cocoa, GUI uygulamaları oluşturmayı birçok yönden çok daha basit hale getirir, ancak kafanızı paradigmanın etrafına sarmanız gerekir. MVC tasarımı Cocoa'da yaygındır ve temsilciler, bildirimler ve çok iş parçacıklı GUI uygulamaları gibi modeller Objective-C'ye çok uygundur.

• Kakao bağlamaları ve anahtar-değer gözlemi tonlarca yapıştırıcı kodunu ortadan kaldırabilir ve Cocoa çerçeveleri bunu kapsamlı bir şekilde kullanır. Objective-C'nin dinamik gönderimi bununla birlikte çalışır, bu nedenle anahtar-değer uyumlu olduğu sürece nesnenin türü önemli değildir.

• Muhtemelen jenerikleri ve ad alanlarını özleyeceksiniz ve bunların faydaları var, ancak Objective-C zihniyetinde ve paradigmasında, bunlar gerekliliklerden ziyade kibarlık olacaktır. (Jenerikler tamamen tip güvenliği ve çevrimden kaçınmakla ilgilidir, ancak Objective-C'de dinamik yazım bunu esasen bir sorun haline getirmez. Ad alanları iyi yapılırsa güzel olurdu, ancak maliyetin, özellikle avantajlardan daha ağır bastığı anlaşmazlıkları önlemek için yeterince basittir. eski kod için.)

• Eşzamanlılık için, Bloklar (Snow Leopard'da yeni bir dil özelliği ve Cocoa API'lerinin puanlarında uygulanan) son derece kullanışlıdır. Birkaç satır (genellikle 10.6'da libsystem'in bir parçası olan Grand Central Dispatch ile birleştirilir), geri arama işlevlerinin, bağlamın vb. Önemli standartlarını ortadan kaldırabilir (Bloklar ayrıca C ve C ++ 'da kullanılabilir ve kesinlikle C #' a eklenebilir, Bu harika olurdu.) NSOperationQueue, GCD'nin sizin için otomatik olarak bir veya daha fazla iş parçacığı üzerinde yürüttüğü özel NSOperation alt sınıflarını veya anonim blokları göndererek kendi kodunuza eşzamanlılık eklemenin de çok uygun bir yoludur.

Şu anda 20 yılı aşkın süredir C, C ++ ve C # ile programlama yapıyorum, ilk olarak 1990'da başladım. İPhone geliştirmesine ve Xcode ve Objective-C'ye bir göz atmaya karar verdim. Aman Tanrım ... Microsoft ile ilgili tüm şikayetleri geri alıyorum, kodun ne kadar kötü olduğunu şimdi anlıyorum. Objective-C, C # 'nın yaptığına kıyasla çok karmaşıktır. C # ile şımartıldım ve şimdi Microsoft'un ortaya koyduğu tüm sıkı çalışmaları takdir ediyorum. Sadece Objective-C'yi metot çağrılarıyla okumak zor. C # bunda zariftir. Bu sadece benim fikrim, Apple geliştirme dilinin Apple ürünleri kadar iyi olduğunu umuyordum, ama canım, Microsoft'tan öğrenecek çok şeyi var. Hiç şüphe yok C # .NET uygulaması Bir uygulamayı XCode Objective-C'den birçok kez daha hızlı çalıştırabilirim. Apple, Microsoft'un kitabından kesinlikle bir sayfa çıkarmalı ve o zaman mükemmel bir ortama sahip oluruz. :-)

Burada teknik inceleme yok, ancak Objective-C'yi çok daha az okunaklı buluyorum. Cinder6'nın size verdiği örnek göz önüne alındığında:

C #

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)

Amaç-C

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

Korkunç görünüyor. Hatta üzerine 2 kitap okumayı denedim, beni erken kaybettiler ve normalde bunu programlama kitapları / dilleri ile anlamıyorum.

Mac OS için Mono'ya sahip olduğumuz için memnunum çünkü bana iyi bir geliştirme ortamı sağlamak için Apple'a güvenmek zorunda kalsaydım ...

Manuel bellek yönetimi, Objective-C'ye yeni başlayanlar için en çok sorun yaşadığı bir şeydir, çünkü çoğunlukla olduğundan daha karmaşık olduğunu düşünürler.

Amaç-C ve Kakao, uzantı gereği uygulama yerine konvansiyonlara dayanır; çok küçük bir dizi kuralı bilir ve bunlara uyarsanız, karşılığında dinamik çalışma süresi ile ücretsiz olarak çok şey alırsınız.

% 100 doğru değil, ancak her gün için yeterince iyi:

• Her çağrı , mevcut kapsamın sonunda allocbir ile eşleştirilmelidir release.
• Yönteminizin dönüş değeri tarafından elde edilmişse, bir ile eşleştirilmek yerine allocile döndürülmelidir .return [value autorelease];release
• Özellikleri kullanın ve üçüncü kural yoktur.

Daha uzun açıklama aşağıdadır.

Bellek yönetimi sahipliğe bağlıdır; yalnızca bir nesne örneğinin sahibi nesneyi bırakmalı, diğer herkes her zaman hiçbir şey yapmamalıdır. Bu, tüm kodun% 95'inde Objective-C'yi çöp toplanmış gibi ele aldığınız anlamına gelir.

Peki diğer% 5 ne olacak? Dikkat etmeniz gereken üç yönteminiz var, bu yöntemden alınan herhangi bir nesne örneği, geçerli yöntem kapsamına aittir :

• alloc
• Veya gibi yeni kelimesiyle başlayan herhangi bir yöntem .newnewService
• Sözcüğünü içeren herhangi bir yöntem gibi, kopyalama copyve mutableCopy.

Yöntemin, çıkmadan önce sahip olduğu nesne örnekleriyle ne yapılacağına dair üç olası seçeneği vardır:

• releaseArtık gerekmiyorsa kullanarak bırakın .
• Bir alana (örnek değişkeni) veya genel bir değişkene, onu atayarak sahiplik verin .
• Sahiplikten vazgeçin, ancak çağrı yaparak örnek kaybolmadan önce başka birine sahipliği alma şansı verin autorelease.

Öyleyse, arayarak ne zaman proaktif olarak mülkiyeti almalısınız retain? İki durum:

• Başlatıcılarınıza alanlar atarken.
• Ayarlayıcı yöntemini manuel olarak uygularken.

Elbette, hayatınızda gördüğünüz her şey Hedef C ise, sözdizimi mümkün olan tek şey gibi görünür. Size "programlama bakiresi" diyebiliriz.

Ancak C, C ++, Java, JavaScript, Pascal ve diğer dillerde çok sayıda kod yazıldığından, ObjectiveC'nin hepsinden farklı olduğunu, ancak iyi bir şekilde olmadığını göreceksiniz. Bunun için bir nedenleri var mıydı? Diğer popüler dilleri görelim:

C ++, C'ye birçok ekstra ekledi, ancak orijinal sözdizimini yalnızca gerektiği kadar değiştirdi.

C #, C ++ 'ya kıyasla çok fazla ekstra ekledi, ancak yalnızca C ++' da çirkin olan şeyleri değiştirdi (arayüzden "::" yi kaldırmak gibi).

Java birçok şeyi değiştirdi, ancak değişikliğin gerekli olduğu kısımlar dışında tanıdık sözdizimini korudu.

JavaScript, ObjectiveC'nin yapamadığı birçok şeyi yapabilen tamamen dinamik bir dildir. Yine de yaratıcıları, dünyanın geri kalanından farklı olmak için yeni bir yöntem çağırma ve parametre geçirme yolu icat etmediler.

Visual Basic, tıpkı ObjectiveC gibi parametreleri sırayla aktarabilir. Parametreleri adlandırabilirsiniz, ancak bunları normal yolla da iletebilirsiniz. Ne kullanırsanız kullanın, herkesin anlayacağı normal virgülle ayrılmış bir yöntemdir. Virgül, yalnızca programlama dillerinde değil, kitaplarda, gazetelerde ve genel olarak yazı dilinde de olağan sınırlayıcıdır.

Nesne Pascal'ın C'den farklı bir sözdizimi vardır, ancak sözdizimi aslında programcı için okumak KOLAYDIR (belki bilgisayar için değil, ancak bilgisayarın ne düşündüğü kimin umurunda). Yani belki konuya girdiler, ama en azından sonuçları daha iyi.

Python'un farklı bir sözdizimi vardır ve okuması (insanlar için) Pascal'dan daha kolaydır. Yani onu değiştirdiklerinde, farklı hale getirdiklerinde, en azından biz programcılar için daha iyi hale getirdiler.

Ve sonra ObjectiveC'ye sahibiz. C'ye bazı iyileştirmeler eklemek, ancak kendi arayüz sözdizimini, yöntem çağrısını, parametre geçişini ve ne olmadığını icat etmek. Merak ediyorum neden + ve - değiştirmediler ki bu artı iki sayıyı çıkarır. Daha da havalı olurdu.

Steve Jobs, ObjectiveC'yi destekleyerek batırdı. Elbette daha iyi olan ancak en kötü rakibine ait olan C # 'ı destekleyemez. Yani bu politik bir karar, pratik değil. Politik nedenlerle teknik kararlar alındığında teknoloji her zaman zarar görür. İyi yaptığı şirketi yönetmeli ve programlama konularını gerçek uzmanlara bırakmalıdır.

Eminim iOS yazmaya ve kitaplıkları ObjectiveC dışında herhangi bir dilde desteklemeye karar verirse iPhone için daha da fazla uygulama olurdu. Sıkı hayranlar, bakire programcılar ve Steve Jobs dışında herkese ObjectiveC gülünç, çirkin ve iğrenç görünüyor.

Object-c ile ilgili sevdiğim bir şey, nesne sisteminin mesajlara dayanıyor olması, C # ile yapamayacağınız gerçekten güzel şeyler yapmanıza izin vermesi (en azından dinamik anahtar kelimeyi destekleyene kadar!).

Kakao uygulamaları yazmanın bir başka harika yanı da Arayüz Oluşturucu, Visual Studio'daki form tasarımcısından çok daha iyi.

Obj-c ile ilgili beni rahatsız eden şeyler (bir C # geliştiricisi olarak), kendi hafızanızı yönetmeniz gerektiği gerçeğidir (çöp toplama vardır, ancak bu iPhone'da çalışmaz) ve bu nedenle çok ayrıntılı olabilir seçici sözdizimi ve tümü [].

C # 4.0'dan gelen iPhone için Objective-C ile yeni başlayan bir programcı olarak lambda ifadelerini ve özellikle de Linq-to-XML'i kaçırıyorum. Lambda ifadeleri C # -özeldir, Linq-to-XML ise gerçekten daha çok .NET ve Cocoa kontrastıdır. Yazdığım örnek bir uygulamada, bir dizede biraz XML vardı. Bu XML'nin öğelerini bir nesneler koleksiyonuna ayrıştırmak istedim.

Bunu Objective-C / Cocoa'da başarmak için NSXmlParser sınıfını kullanmam gerekiyordu . Bu sınıf, NSXMLParserDelegate protokolünü, bir öğe açık etiketi okunduğunda, bazı veriler okunduğunda (genellikle öğenin içinde) okunduğunda ve bazı öğe son etiketi okunduğunda çağrılan yöntemlerle (oku: mesajlar gönderildi) uygulayan başka bir nesneye dayanır. . Ayrıştırma durumunu ve durumunu takip etmelisiniz. Ve dürüst olmak gerekirse, XML geçersizse ne olacağı hakkında hiçbir fikrim yok. Ayrıntılara inmek ve performansı optimize etmek için harika, ama dostum, bu çok fazla kod.

Buna karşılık, burada C # kodudur:

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

İşte bu kadar, XML'den çizilmiş bir özel nesneler koleksiyonunuz var. Bu öğeleri değere göre veya yalnızca belirli bir özniteliği içerenlere göre filtrelemek istiyorsanız veya yalnızca ilk 5'i istiyorsanız veya ilk 1'i atlayıp sonraki 3'ü elde etmek veya herhangi bir öğenin döndürülüp döndürülmediğini öğrenmek istiyorsanız ... BAM, hepsi aynı kod satırında.

Bu işlemeyi Objective-C'de çok daha kolay hale getiren birçok açık kaynaklı sınıf vardır, bu yüzden ağır işlerin çoğunu yapar. Sadece bu yerleşik değil.

* NOT: Yukarıdaki kodu aslında derlemedim, sadece C # tarafından gerekli görülen göreli ayrıntı eksikliğini göstermek için bir örnek olması amaçlanmıştır.

Muhtemelen en önemli fark bellek yönetimidir. C # ile CLR tabanlı bir dil olması sayesinde çöp toplama elde edersiniz. Objective-C ile belleği kendiniz yönetmeniz gerekir.

C # arka planından (veya bu konuda herhangi bir modern dilden) geliyorsanız, otomatik bellek yönetimi olmayan bir dile geçmek gerçekten zahmetli olacaktır çünkü kodlama zamanınızın çoğunu belleği düzgün bir şekilde yönetmek (ve hata ayıklamak için) için harcayacaksınız. iyi).

İşte iki dili karşılaştıran oldukça güzel bir makale: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

2 dil arasındaki paradigma farkı dışında çok fazla fark yok. Söylemekten nefret etsem de, Objective-C ve Cocoa ile yapabildiğiniz gibi, .NET ve C # ile aynı tür şeyleri (muhtemelen o kadar kolay değil) yapabilirsiniz. Eğer kalmamak Leopard itibariyle Objective-C 2.0, çöp koleksiyonuna sahiptir var sen (eski Mac'ler ile kod uyumluluğu ve iPhone uygulamaları istediğiniz 2 nedeni vardır) istemedikçe belleği kendiniz yönetmek için.

Yapılandırılmış, okunabilir kod söz konusu olduğunda, buradaki yükün çoğu, diğer dillerde olduğu gibi programcıya aittir. Bununla birlikte, mesaj geçiş paradigmasının, işlevlerinizi / yöntemlerinizi uygun şekilde adlandırmanız koşuluyla (yine, diğer diller gibi) okunabilir koda uygun olduğunu görüyorum.

C # veya .NET ile pek aşina olmadığımı ilk kabul eden ben olacağım. Ancak Quinn'in yukarıda sıralanan nedenleri, benim öyle olmasını umursamadığım birkaç nedenden ötürü.

Obj-c'de kullanılan yöntem çağrıları, bence c # 'dan çok daha zarif ve obj-c c'nin üzerine inşa edilmiştir, bu nedenle tüm c kodu obj-c'de düzgün çalışmalıdır. Benim için en büyük satıcı, obj-c'nin açık bir standart olması, böylece herhangi bir sistem için derleyiciler bulabilmeniz.