Bagaimana Objective-C dibandingkan dengan C #? [Tutup]


87

Saya baru saja membeli Mac dan menggunakannya terutama untuk pengembangan C # di bawah VMWare Fusion. Dengan semua aplikasi Mac yang bagus di sekitar saya, saya mulai memikirkan tentang Xcode yang bersembunyi hanya dengan sekali klik, dan mempelajari Objective-C.

Sintaks antara kedua bahasa terlihat sangat berbeda, mungkin karena Objective-C berasal dari C dan C # berasal dari Java / C ++. Tetapi sintaks yang berbeda dapat dipelajari sehingga tidak masalah.

Perhatian utama saya adalah bekerja dengan bahasa dan jika itu akan membantu menghasilkan kode yang terstruktur dengan baik, dapat dibaca dan elegan. Saya sangat menikmati fitur-fitur seperti LINQ dan var di C # dan bertanya-tanya apakah ada fitur yang setara atau lebih baik / berbeda di Objective-C.

Fitur bahasa apa yang akan saya lewatkan untuk dikembangkan dengan Objective-C? Fitur apa yang akan saya dapatkan?

Sunting: Perbandingan kerangka kerja berguna dan menarik tetapi perbandingan bahasa adalah apa yang sebenarnya ditanyakan oleh pertanyaan ini (sebagian karena kesalahan saya karena awalnya menandai .net). Agaknya, baik Cocoa maupun .NET adalah kerangka kerja yang sangat kaya dan keduanya memiliki tujuan masing-masing, satu menargetkan Mac OS X dan Windows lainnya.

Terima kasih atas pemikiran yang matang dan sudut pandang yang cukup seimbang sejauh ini!


27
Xcode memang tidak sempurna, tetapi tentunya memiliki banyak fitur yang kuat dan berguna. Meremehkan sesuatu sebagai "kejahatan murni" tanpa mendukungnya atau memberikan konteks apa pun untuk perbandingan adalah FUD yang tidak membantu siapa pun. Bagaimanapun, itu tidak relevan dengan pertanyaan itu.
Quinn Taylor

11
Xcode 3.2 mungkin adalah IDE terbaik yang pernah saya gunakan, dengan penanganan breakpoint yang elegan, analisis statis, pesan kesalahan sebaris, dan banyak fitur lainnya. Btw, ini "Xcode" dan bukan "XCode". @Nathan, saya benar-benar tidak mengerti mengapa Anda perlu merendahkan Xcode dengan menyebutnya "kejahatan murni" - tanpa pembenaran apa pun - dalam diskusi tentang bahasa.
Debajit

6
Satu hal besar yang akan Anda peroleh dengan menggunakan Objective-C adalah Anda akan memiliki akses ke kerangka kerja Cocoa. Selain itu, C, C #, Java, dan C ++ semuanya berbagi warisan sintaksis yang sama. Objective-C mendapatkan sintaksnya dari Smalltalk.
Amuk

4
Anda melakukan pekerjaan C # menggunakan fusi VMWare? Cukup gunakan mono dan monodevelop (yang merupakan versi open source dari .NET dan Visual Studio yang bekerja di Mac dan Linux. Menggunakan Mono Anda juga dapat membuat aplikasi Mac dan iPhone menggunakan C # sambil juga menggunakan pustaka .NET, serta Cocoa ...
Robin Heggelund Hansen

5
@ user668039 15 tahun pengalaman menggunakan C #? Itu dirilis pada tahun 2001!
Ian Newson

Jawaban:


89

Tidak ada bahasa yang sempurna untuk semua tugas, dan Objective-C tidak terkecuali, tetapi ada beberapa hal yang sangat spesifik. Seperti menggunakan LINQdan var(yang tidak saya ketahui penggantinya secara langsung), beberapa di antaranya sangat terkait dengan bahasa, dan yang lainnya terkait dengan kerangka kerja.

( CATATAN: Sama seperti C # yang digabungkan erat dengan .NET, Objective-C terkait erat dengan Cocoa. Oleh karena itu, beberapa poin saya mungkin tampak tidak terkait dengan Objective-C, tetapi Objective-C tanpa Cocoa mirip dengan C # tanpa .NET / WPF / LINQ, berjalan di bawah Mono, dll. Hanya saja, ini bukan cara yang biasa dilakukan.)

Saya tidak akan berpura-pura menguraikan sepenuhnya perbedaan, pro, dan kontra, tetapi berikut adalah beberapa yang terlintas dalam pikiran.

  • Salah satu bagian terbaik dari Objective-C adalah sifatnya yang dinamis - daripada memanggil metode, Anda mengirim pesan, yang dirutekan runtime secara dinamis. Dikombinasikan (dengan bijaksana) dengan pengetikan dinamis, ini dapat membuat banyak pola yang kuat menjadi lebih sederhana atau bahkan sepele untuk diterapkan.

  • Sebagai superset ketat dari C, Objective-C percaya bahwa Anda tahu apa yang Anda lakukan. Tidak seperti pendekatan bahasa yang dikelola dan / atau tidak aman seperti C # dan Java, Objective-C memungkinkan Anda melakukan apa yang Anda inginkan dan mengalami konsekuensinya. Jelas ini kadang-kadang bisa berbahaya, tetapi fakta bahwa bahasa tidak secara aktif mencegah Anda melakukan banyak hal cukup kuat. ( EDIT: Saya harus menjelaskan bahwa C # juga memiliki fitur dan fungsi yang "tidak aman", tetapi perilaku defaultnya adalah kode yang dikelola, yang harus Anda sisihkan secara eksplisit. Sebagai perbandingan, Java hanya mengizinkan kode yang aman untuk mengetik, dan tidak pernah memperlihatkan petunjuk mentah di seperti yang dilakukan C dan lainnya.)

  • Kategori (menambahkan / memodifikasi metode pada kelas tanpa subclass atau memiliki akses ke sumber) adalah pedang bermata dua yang mengagumkan. Ini dapat sangat menyederhanakan hierarki pewarisan dan menghilangkan kode, tetapi jika Anda melakukan sesuatu yang aneh, hasilnya terkadang membingungkan.

  • Cocoa membuat pembuatan aplikasi GUI jauh lebih sederhana dalam banyak hal, tetapi Anda harus memahami paradigma tersebut. Desain MVC tersebar luas di Cocoa, dan pola seperti delegasi, notifikasi, dan aplikasi GUI multi-utas sangat cocok untuk Objective-C.

  • Pengikatan kakao dan pengamatan nilai kunci dapat menghilangkan banyak kode perekat, dan kerangka kerja Kakao memanfaatkannya secara ekstensif. Pengiriman dinamis Objective-C bekerja bahu-membahu dengan ini, jadi jenis objek tidak menjadi masalah asalkan sesuai dengan nilai kuncinya.

  • Anda kemungkinan besar akan merindukan obat generik dan namespace, dan keduanya memiliki manfaatnya, tetapi dalam pola pikir dan paradigma Objective-C, keduanya lebih baik daripada kebutuhan. (Generik adalah tentang keamanan tipe dan menghindari casting, tetapi pengetikan dinamis di Objective-C membuat ini pada dasarnya bukan masalah. Namespaces akan bagus jika dilakukan dengan baik, tetapi cukup sederhana untuk menghindari konflik yang biayanya bisa dibilang lebih besar daripada manfaatnya, terutama untuk kode lama.)

  • Untuk konkurensi, Blok (fitur bahasa baru di Snow Leopard, dan diterapkan di sejumlah API Kakao) sangat berguna. Beberapa baris (sering digabungkan dengan Grand Central Dispatch, yang merupakan bagian dari libsystem pada 10.6) dapat menghilangkan boilerplate signifikan dari fungsi callback, konteks, dll. (Blok juga dapat digunakan dalam C dan C ++, dan tentunya dapat ditambahkan ke C #, yang akan luar biasa.) NSOperationQueue juga merupakan cara yang sangat nyaman untuk menambahkan konkurensi ke kode Anda sendiri, dengan mengirimkan subkelas NSOperation kustom atau blok anonim yang secara otomatis dijalankan oleh GCD pada satu atau beberapa utas berbeda untuk Anda.


7
Secara teknis, C # memiliki semua fitur daya non-tipe-aman yang dilakukan ObjC: pointer mentah, aritmatika pointer, array yang tidak dicentang, unions alloca,. Itu tidak membuatnya mudah diakses - Anda harus ikut serta secara eksplisit.
Pavel Minaev

8
Saya hanya menyebutkan Cocoa karena sebagian besar daya tarik pemrograman di Objective-C adalah karena kerangka kerja Cocoa. Apakah C # akan menarik tanpa .NET dan / atau WPF? Penanya secara khusus menyebutkan LINQ, jadi dia jelas melihat di luar bahasa, ke pengalaman.
Quinn Taylor

7
Itu bagus. Saya tidak mencoba berkelahi dengan C #. Jika saya harus menulis perangkat lunak Windows, itulah yang akan saya gunakan. Saya hanya mencoba menunjukkan persamaan dan perbedaan antara bahasa dan alat terkait. Anda jelas lebih berpengalaman dengan C #, dan saya dengan Objective-C. Saya menghargai klarifikasi Anda, tetapi mungkin jawaban yang lebih konstruktif dan mengurangi rambut berantakan akan sangat berguna.
Quinn Taylor

11
Ini tidak merusak rambut, Quinn. Saya hanya menunjukkan bahwa apa yang dimulai sebagai perbandingan bahasa berubah menjadi diskusi umum tentang bagaimana Kakao itu baik di beberapa titik dalam balasan Anda. Saya masih ingin menunjukkan bahwa poin Anda tentang Kakao bukanlah perbandingan - mereka mengatakan "itu X dengan baik" - dan mungkin memang demikian - tetapi mereka tidak mengatakan "itu X lebih baik / lebih buruk daripada C # + WPF ", yang merupakan pertanyaan umum.
Pavel Minaev

6
+1 jawaban luar biasa Quinn
h4xxr

54

Saya telah memprogram dalam C, C ++ dan C # sekarang selama lebih dari 20 tahun, pertama kali dimulai pada tahun 1990. Saya baru saja memutuskan untuk melihat perkembangan iPhone dan Xcode dan Objective-C. Ya ampun ... semua keluhan tentang Microsoft saya ambil kembali, saya sekarang menyadari betapa buruknya kode hal itu. Objective-C terlalu kompleks dibandingkan dengan apa yang dilakukan C #. Saya telah dimanjakan dengan C # dan sekarang saya menghargai semua kerja keras yang telah dilakukan Microsoft. Hanya membaca Objective-C dengan metode pemanggilan sulit untuk dibaca. C # elegan dalam hal ini. Itu hanya pendapat saya, saya berharap bahasa pengembangan Apple sebagus produk Apple, tetapi saya, mereka harus banyak belajar dari Microsoft. Tidak ada pertanyaan C #. Aplikasi NET. Saya bisa mendapatkan aplikasi dan berjalan berkali-kali lebih cepat daripada XCode Objective-C. Apple tentunya harus mengambil bagian dari buku Microsoft di sini dan kemudian kita akan memiliki lingkungan yang sempurna. :-)


47
Meskipun Anda telah melihat sekilas buku pengembang iPhone, Anda masih dapat membuat aplikasi lebih cepat di platform yang Anda miliki selama 20 tahun? LUAR BIASA
kubi

25
Saya mengalami pengalaman yang sama persis dengan Waz. Saya juga lebih bersyukur atas pekerjaan yang telah dilakukan Microsoft di C # dan alat pengembangan seperti Visual Studio, setelah saya mulai mempelajari Objective C.
René

4
Itu juga pengalaman saya saat belajar objektif-c, terlalu rumit dibandingkan dengan c #. @ alexy13 Apa bagian dari c dan c ++ dari pesan asli yang Anda lewatkan? Memiliki pengalaman puluhan tahun dalam satu rumpun bahasa sangat membantu BANYAK untuk mengevaluasi seberapa sulit melakukan pekerjaan yang sama dengan bahasa lain dari rumpun yang sama.
Anderson Fortaleza

5
bagaimana jawaban teratas ini? ini bukan jawaban yang ringkas, hanya opini yang jelas bias dari beberapa bahasa yang dia pelajari dalam semalam vs bahasa yang telah dia gunakan lebih dari 20 tahun ... jelas Anda tidak akan mahir dalam bahasa baru
Heavy_Bullets

3
"Just reading Objective-C with method invokes is difficult to read"- di sini adalah hanya salah satu yang sangat subjektif argumen bahwa disebutkan di sini sebagai kontra dari obj-C. Semua lainnya hanyalah retorika yang bisa diperdebatkan.
skywinder

46

Tidak ada tinjauan teknis di sini, tapi saya hanya merasa Objective-C kurang bisa dibaca. Diberikan contoh yang diberikan Cinder6:

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)

Objective-C

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

Ini terlihat buruk. Saya bahkan mencoba membaca 2 buku tentang itu, mereka kehilangan saya sejak awal, dan biasanya saya tidak mendapatkannya dengan buku / bahasa pemrograman.

Saya senang kami memiliki Mono untuk Mac OS, karena jika saya harus bergantung pada Apple untuk memberi saya lingkungan pengembangan yang baik ...


17
Mengabaikan fakta bahwa baris pertama harus diakhiri dengan [NSMutableArray array](memori bocor) dan baris ke-4 harus dimulai dengan NSString* xatau id x(kesalahan kompilasi) ... Ya, Objective-C tidak memiliki obat generik (sejujurnya saya tidak melewatkannya), Anda tidak objek indeks dengan sintaks array, dan API umumnya lebih verbose. To-may-to, to-mah-to. Itu benar-benar tergantung pada apa yang ingin Anda lihat. (Anda dapat menulis kode yang sama di C ++ STL dan menurut saya itu mengerikan.) Bagi saya, kode yang dapat dibaca sering kali berarti teks dari kode tersebut memberitahu Anda apa yang dilakukannya, dan dengan demikian kode Objective-C lebih disukai.
Quinn Taylor

18
Saya tidak benar-benar menemukan sesuatu yang salah dengan sintaks seperti itu - alasan utama mengapa ini terasa kurang dapat dibaca adalah karena 1) tidak dikenal semua orang yang berasal dari latar belakang C, dan 2) digunakan di tengah konstruksi C biasa, di mana itu terlihat asing. Di sisi lain, Smalltalkish bernama-parameter-as-part-of-method-name sebenarnya membuat panggilan lebih mudah dipahami sejak awal. Faktanya, contoh kode C # Anda mendemonstrasikan ini dengan baik - itu tidak akan dikompilasi, karena List<T>.Removemengambil string sebagai argumen, dan menghapus kemunculan pertama dari string itu. Untuk menghapus menurut indeks, Anda perlu RemoveAt.
Pavel Minaev

12
... sedangkan versi ObjC dengan removeObjectAtIndex:, meski lebih bertele-tele, juga tidak ambigu tentang apa yang dilakukannya.
Pavel Minaev

6
Poin bagus, Pavel. Juga, ketidakkonsistenan antara strings[0]dan strings.RemoveAt(0)mengurangi kejelasan, setidaknya bagi saya. (Juga, itu selalu mengganggu saya ketika nama metode dimulai dengan huruf kapital ... Saya tahu itu adalah hal kecil, tapi itu hanya aneh.)
Quinn Taylor

4
Dalam kasus saya, seperti bagi banyak orang, keterbacaan "alat" memengaruhi produktivitas saya. Saya merasa nyaman dan produktif dengan banyak bahasa Objective-C bagaimanapun, tidak pernah menjadi salah satunya dan itu bukan karena kurang mencoba. Tetapi sekali lagi, pada akhirnya, itu semua tentang preferensi pribadi. Tidak seperti 20 tahun lalu, Anda tidak dipaksa untuk menggunakan bahasa X untuk menargetkan platform Y. Anda memilih yang paling sesuai untuk Anda.
TimothyP

17

Manajemen memori manual adalah sesuatu yang pemula dalam Objective-C tampaknya memiliki masalah paling besar, sebagian besar karena mereka pikir itu lebih kompleks daripada yang sebenarnya.

Objective-C dan Cocoa dengan ekstensi bergantung pada konvensi daripada penegakan; mengetahui dan mengikuti seperangkat aturan yang sangat kecil dan Anda mendapatkan banyak secara gratis dengan menjalankan-waktu dinamis sebagai imbalan.

Aturan yang tidak 100% benar, tetapi cukup baik untuk sehari-hari adalah:

  • Setiap panggilan ke allocharus dicocokkan dengan releasedi akhir lingkup saat ini.
  • Jika nilai kembalian untuk metode Anda telah diperoleh, allocmaka itu harus dikembalikan oleh return [value autorelease];alih-alih dicocokkan dengan release.
  • Gunakan properti, dan tidak ada aturan tiga.

Penjelasan yang lebih panjang mengikuti.

Manajemen memori didasarkan pada kepemilikan; hanya pemilik contoh objek yang boleh melepaskan objek, orang lain harus selalu tidak melakukan apa pun. Ini berarti bahwa 95% dari semua kode Anda memperlakukan Objective-C seolah-olah itu sampah yang dikumpulkan.

Lalu bagaimana dengan 5% lainnya? Anda memiliki tiga metode untuk diperhatikan, setiap instance objek yang diterima dari metode ini dimiliki oleh lingkup metode saat ini :

  • alloc
  • Metode apa pun yang diawali dengan kata baru , seperti newatau newService.
  • Metode apa pun yang mengandung kata copy, seperti copydan mutableCopy.

Metode ini memiliki tiga opsi yang mungkin tentang apa yang harus dilakukan dengan instance objek yang dimilikinya sebelum keluar:

  • Lepaskan menggunakan releasejika tidak diperlukan lagi.
  • Berikan kepemilikan ke bidang (variabel contoh) , atau variabel global hanya dengan menetapkannya.
  • Lepaskan kepemilikan tetapi beri orang lain kesempatan untuk mengambil alih kepemilikan sebelum instans hilang dengan menelepon autorelease.

Jadi, kapan Anda harus secara proaktif mengambil alih kepemilikan dengan menelepon retain? Dua kasus:

  • Saat menetapkan bidang di penginisialisasi Anda.
  • Saat menerapkan metode penyetel secara manual.

2
+1 Ringkasan yang bagus. Kedengarannya sangat mirip dengan saat saya belajar C tahun lalu.
Alex Angas

4
Hanya untuk memperjelas, pengumpulan sampah didukung penuh untuk Objective-C di Mac, dan tidak perlu melakukan manajemen memori manual. Manajemen memori manual hanya diperlukan di iOS.
Debajit

3
Tetap saja, ada baiknya mempelajari dasar-dasar manajemen memori, jika hanya untuk meningkatkan kinerja saat Anda membutuhkannya (tidak harus menjalankan pengumpulan sampah).
FeifanZ

3
iOS 5 memperkenalkan ARC, menghilangkan kebutuhan untuk secara manual merilis objek yang dialokasikan. Tapi masih belum semudah C #. Anda harus ingat bahwa Objective-C telah berusia lebih dari 20 tahun, dan beberapa persyaratan bahasa di masa itu telah dipertahankan: yaitu mengetahui kapan harus mengalokasikan dan kapan harus membebaskan / melepaskan memori. C # telah menghapus semua ini untuk Anda. Karena itu, Cocoa memiliki banyak API yang belum dapat diakses di Windows Phone. Seperti gerakan, lebih banyak kontrol ketika datang ke acara UI dll ...
jyavenard

10

Tentu, jika semua yang Anda lihat dalam hidup Anda adalah Tujuan C, maka sintaksnya tampak seperti satu-satunya yang mungkin. Kami bisa menyebut Anda "perawan pemrograman".

Tetapi karena banyak kode ditulis dalam C, C ++, Java, JavaScript, Pascal, dan bahasa lain, Anda akan melihat bahwa ObjectiveC berbeda dari semuanya, tetapi tidak dengan cara yang baik. Apakah mereka punya alasan untuk ini? Mari kita lihat bahasa populer lainnya:

C ++ menambahkan banyak tambahan ke C, tetapi itu mengubah sintaks asli hanya sebanyak yang diperlukan.

C # menambahkan banyak tambahan dibandingkan dengan C ++ tetapi hanya mengubah hal-hal yang jelek di C ++ (seperti menghapus "::" dari antarmuka).

Java mengubah banyak hal, tetapi tetap menggunakan sintaks yang familier kecuali di bagian yang memerlukan perubahan.

JavaScript adalah bahasa yang benar-benar dinamis yang dapat melakukan banyak hal yang tidak bisa dilakukan ObjectiveC. Namun, penciptanya tidak menemukan cara baru untuk memanggil metode dan mengirimkan parameter hanya agar berbeda dari negara lain.

Visual Basic dapat melewatkan parameter yang rusak, seperti ObjectiveC. Anda dapat memberi nama parameter, tetapi Anda juga dapat meneruskannya dengan cara biasa. Apa pun yang Anda gunakan, itu adalah cara normal yang dipisahkan koma yang dipahami semua orang. Koma merupakan pembatas biasa, tidak hanya dalam bahasa pemrograman, tetapi di buku, koran, dan bahasa tertulis pada umumnya.

Object Pascal memiliki sintaks yang berbeda dari C, tetapi sintaksnya sebenarnya LEBIH MUDAH dibaca oleh programmer (mungkin bukan ke komputer, tapi siapa yang peduli apa yang dipikirkan komputer). Jadi mungkin mereka menyimpang, tapi setidaknya hasilnya lebih baik.

Python memiliki sintaks yang berbeda, yang bahkan lebih mudah dibaca (untuk manusia) daripada Pascal. Jadi ketika mereka mengubahnya, membuatnya berbeda, setidaknya mereka membuatnya lebih baik untuk kita para programmer.

Dan kemudian kami memiliki ObjectiveC. Menambahkan beberapa perbaikan pada C, tetapi menciptakan sintaks antarmukanya sendiri, pemanggilan metode, pengoperan parameter dan apa yang tidak. Saya bertanya-tanya mengapa mereka tidak menukar + dan - sehingga plus mengurangi dua angka. Akan lebih keren.

Steve Jobs gagal dengan mendukung ObjectiveC. Tentu saja dia tidak dapat mendukung C #, yang lebih baik, tetapi milik pesaing terburuknya. Jadi ini keputusan politik, bukan keputusan praktis. Teknologi selalu menderita ketika keputusan teknologi dibuat karena alasan politik. Dia harus memimpin perusahaan, yang dia lakukan dengan baik, dan menyerahkan masalah pemrograman kepada ahlinya.

Saya yakin akan ada lebih banyak aplikasi untuk iPhone jika dia memutuskan untuk menulis iOS dan mendukung perpustakaan dalam bahasa lain selain ObjectiveC. Bagi semua orang kecuali penggemar berat, programmer perawan, dan Steve Jobs, ObjectiveC terlihat konyol, jelek, dan menjijikkan.


3
2 paragraf terakhir menjumlahkan semuanya
Zakos

Oh ya, tentu saja sintaksnya terlihat konyol tetapi permata dari bahasa Objective-C adalah bahwa ia memiliki refleksi yang paling mudah untuk digunakan dari semua bahasa dan beberapa fitur runtime yang sangat brilian yang membuat beberapa paradigma hampir sepele untuk diterapkan. Misalnya ketika menggunakan Objective-C saya tidak perlu memikirkan tabel linier mana yang akan digunakan - daftar tertaut atau vektor atau apa pun itu - hanya NSArraydan itu menangani pemilihan algoritma terbaik berdasarkan mesin dan sifat datanya.
Maxthon Chan

Saya memasuki pekerjaan pertama saya sebagai programmer (perawan) yang menerapkan antarmuka pengguna iOS-App di Objective-C. Yang saya inginkan untuk saat ini (setelah 3 tahun) adalah keluar dari 'pulau' yang sepi itu dan mempelajari sesuatu yang lebih tidak bergantung pada platform dan karena itu lebih penting. Juga untuk mempelajari apakah kerangka kerja lain juga diperbarui dengan sangat cepat - dan bermasalah. Hei! Fitur baru! - Crash ... Berharap pusat kerja (Jerman) menghabiskan sejumlah uang untuk saya untuk tutorial di Java dan / atau C ++ / C # karena saya tidak lagi ingin mengembangkan Apple sh * t.
anneblue

5

Satu hal yang saya suka tentang objektif-c adalah bahwa sistem objek didasarkan pada pesan, ini memungkinkan Anda melakukan hal-hal baik yang tidak dapat Anda lakukan di C # (setidaknya tidak sampai mereka mendukung kata kunci dinamis!).

Hal hebat lainnya tentang menulis aplikasi kakao adalah Interface Builder, jauh lebih bagus daripada desainer formulir di Visual Studio.

Hal-hal tentang obj-c yang mengganggu saya (sebagai pengembang C #) adalah kenyataan bahwa Anda harus mengelola memori Anda sendiri (ada pengumpulan sampah, tetapi itu tidak berfungsi di iPhone) dan itu bisa sangat bertele-tele karena sintaks pemilih dan semua [].


2
dynamichanya akan membuat Anda setengah jalan - mengimplementasikan objek dinamis sejati, bahkan dengan hal-hal sepele seperti pendelegasian pesan, membosankan bahkan dalam C # 4.0. Di sisi lain, harga untuk fleksibilitas pesan dinamis sejati melalui ObjC adalah kehilangan keamanan tipe.
Pavel Minaev

3
Perlu diketahui bahwa Objective-C memungkinkan pengetikan statis keikutsertaan, yang memang memberikan tingkat keamanan jenis yang jauh lebih tinggi. Beberapa orang lebih suka pemeriksaan waktu kompilasi, yang lain lebih suka pemeriksaan waktu proses. Hal yang menyenangkan (dalam kedua bahasa) adalah pilihannya tidak harus mutlak.
Quinn Taylor

3
Desainer Windows Forms tidak begitu hebat, tetapi jika Anda dapat menggunakan WPF (mulai .NET 3.0) Expression Blend sulit dikalahkan ...
Nate

Anda dapat melakukan banyak hal ini dengan System.Reflectiondikombinasikan dengan ekstensi di C # 3.0, Anda dapat memanggil metode apa pun yang Anda temukan, tetapi bukan pesan yang benar, itu akan terlihat seperti obj.PassMessage("function_name", params object[] args);pesan yang lebih baik yang diintegrasikan ke dalam bahasa, metode yang tidak dapat dipanggil pada objek normal adalah dibutuhkan.
Filip Kunc

4

Sebagai seorang programmer yang baru saja memulai Objective-C untuk iPhone, berasal dari C # 4.0, saya kehilangan ekspresi lambda, dan khususnya, Linq-to-XML. Ekspresi lambda adalah C # -specific, sedangkan Linq-to-XML lebih merupakan kontras .NET vs. Cocoa. Dalam aplikasi contoh yang saya tulis, saya memiliki beberapa XML dalam sebuah string. Saya ingin mengurai elemen XML itu ke dalam kumpulan objek.

Untuk mencapai ini di Objective-C / Cocoa, saya harus menggunakan kelas NSXmlParser . Kelas ini bergantung pada objek lain yang mengimplementasikan protokol NSXMLParserDelegate dengan metode yang dipanggil (baca: pesan terkirim) saat tag terbuka elemen dibaca, saat beberapa data dibaca (biasanya di dalam elemen), dan saat beberapa tag akhir elemen dibaca . Anda harus melacak status dan status penguraian. Dan sejujurnya saya tidak tahu apa yang terjadi jika XML tidak valid. Sangat bagus untuk mendapatkan detail dan mengoptimalkan kinerja, tapi oh man, itu banyak sekali kode.

Sebaliknya, inilah kode di C #:

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

Dan itu saja, Anda punya koleksi objek khusus yang diambil dari XML. Jika Anda ingin memfilter elemen tersebut berdasarkan nilai, atau hanya elemen yang berisi atribut tertentu, atau jika Anda hanya menginginkan 5 elemen pertama, atau melewati 1 pertama dan mendapatkan 3 berikutnya, atau hanya mencari tahu apakah ada elemen yang dikembalikan ... BAM, semua ada di baris kode yang sama.

Ada banyak kelas sumber terbuka yang membuat pemrosesan ini jauh lebih mudah di Objective-C, sehingga melakukan banyak pekerjaan berat. Hanya saja bukan ini bawaannya.

* CATATAN: Saya tidak benar-benar mengkompilasi kode di atas, itu hanya dimaksudkan sebagai contoh untuk menggambarkan kurangnya verbositas relatif yang dibutuhkan oleh C #.


Penting untuk tidak di sini, bahwa tidak ada begitu banyak "kurangnya verbositas" pada bagian C # dalam perbandingan ini, hanya verbositas yang terkandung dalam kelas framework .net yang Anda gunakan untuk mengurai XML Anda. Jika Anda memeriksa kode di dalamnya, Anda cenderung menemukan lebih banyak kode C #, bahkan mungkin lebih bertele-tele.
XIVSolutions

3

Mungkin perbedaan yang paling penting adalah manajemen memori. Dengan C # Anda mendapatkan pengumpulan sampah, berdasarkan itu menjadi bahasa berbasis CLR. Dengan Objective-C Anda perlu mengelola memori sendiri.

Jika Anda berasal dari latar belakang C # (atau bahasa modern lainnya), pindah ke bahasa tanpa manajemen memori otomatis akan sangat menyakitkan, karena Anda akan menghabiskan banyak waktu pengkodean untuk mengelola memori dengan benar (dan men-debug sebagai baik).


6
ObjC telah melacak pengumpulan sampah hari ini. Di sisi lain, C # memungkinkan Anda mengelola memori sendiri jika Anda mau (berkat petunjuk mentah).
Pavel Minaev

3
Saya tidak menemukan manajemen memori manual di Objective-C (dalam konteks kerangka Apple) menjadi banyak beban: siklus pertahankan / rilis / rilis otomatis jauh lebih praktis daripada manajemen memori "tradisional" di C dan C ++.
mipadi

5
Ini bukan DSO yang sebenarnya - bahkan pada lingkungan non-pengumpulan sampah seperti iPhone, hal-hal yang mempertahankan / melepaskan dan melepaskan otomatis membutuhkan waktu sekitar 10 menit untuk dipelajari dan kemudian tidak ada masalah. Saya telah menemukan banyak C # -ers yang suka melebih-lebihkan tantangan manajemen memori. Ini hampir seperti mereka takut mereka akan mulai menyukai obj-c jika tidak ...;)
h4xxr

4
Dasar-dasar manajemen memori manual tidaklah sulit. Tapi ini bisa menjadi sangat rumit dengan sangat cepat ketika Anda mulai melewatkan objek yang dialokasikan dan perlu berurusan dengan grafik objek yang kompleks, karena Anda perlu mengikuti aturan dengan cermat seperti siapa yang bertanggung jawab untuk membebaskan dan kapan. Implementasi penghitungan referensi membuatnya lebih mudah, kecuali Anda perlu berurusan dengan siklus dalam grafik objek ... dibandingkan dengan C #, semua IMO ini adalah perbedaan besar.
DSO

1

Berikut artikel yang cukup bagus yang membandingkan kedua bahasa tersebut: http://www.coderetard.com/2008/03/16/c-vs-objective-c/


Sayangnya halaman tersebut mengklaim berada di UTF-8 tetapi memiliki semua jenis pengganti yang buruk untuk apostrof dan tanda kutip. Saya pikir teksnya menggunakan tanda kutip "melengkung", tetapi mereka pasti mengacaukan kode ...
Quinn Taylor

mereka tampaknya telah mencuri intro utuh mereka, tetapi bahkan artikel sumber memiliki kode mereka. juga bukan artikel yang bagus.
dnord

-2

Selain perbedaan paradigma antara kedua bahasa tersebut, tidak banyak perbedaannya. Meskipun saya benci mengatakannya, Anda dapat melakukan hal yang sama (mungkin tidak semudah) dengan .NET dan C # seperti yang Anda bisa dengan Objective-C dan Cocoa. Pada Leopard, Objective-C 2.0 memiliki pengumpulan sampah, jadi Anda tidak perlu mengelola memori sendiri kecuali Anda ingin (kompatibilitas kode dengan aplikasi Mac dan iPhone yang lebih lama adalah 2 alasan untuk menginginkannya).

Sejauh menyangkut terstruktur, kode yang dapat dibaca, banyak beban yang ada pada programmer, seperti halnya dengan bahasa lain. Namun, saya menemukan bahwa pesan yang melewati paradigma cocok untuk kode yang dapat dibaca asalkan Anda memberi nama fungsi / metode Anda dengan tepat (sekali lagi, sama seperti bahasa lain).

Saya akan menjadi orang pertama yang mengakui bahwa saya tidak terlalu familiar dengan C # atau .NET. Tetapi alasan Quinn yang tercantum di atas adalah beberapa alasan mengapa saya tidak peduli untuk menjadi seperti itu.


-3

Panggilan metode yang digunakan dalam obj-c membuat kode mudah dibaca, menurut pendapat saya jauh lebih elegan daripada c # dan obj-c dibangun di atas c sehingga semua kode c harus berfungsi dengan baik di obj-c. Penjual besar bagi saya adalah bahwa obj-c adalah standar terbuka sehingga Anda dapat menemukan kompiler untuk sistem apa pun.


2
ISO C # juga merupakan standar terbuka. Juga, sejauh yang saya tahu, satu-satunya compiler ObjC yang ada adalah gcc.
Pavel Minaev

@Pavel: Ada juga Portable Object Compiler ( users.telenet.be/stes/compiler.html ) dan clang.
mipadi

1
Sebenarnya, GCC bukan lagi satu-satunya kompiler - Clang dan LLVM adalah sepasang teknologi yang dirancang dan dikembangkan untuk menggantikan GCC dan melakukan hal-hal yang tidak pernah bisa dilakukan, termasuk kompilasi JIT. Ini adalah inti dari OpenCL di Snow Leopard. Mereka juga dapat dikembangkan ke bahasa lain, dan patut untuk dicoba.
Quinn Taylor

2
Sejujurnya saya tidak akan menganggap portabilitas sebagai pro Objective-C. Sebaliknya, kekuatannya lebih banyak di sepanjang garis perkembangan cepat dan pengurangan volume kode untuk menyelesaikan tugas yang sama.
Quinn Taylor

Terima kasih telah memperbaiki kesalahan saya pada ketersediaan kompiler. Yah, portabilitas secara teknis ada di sana - saya dapat menggunakan MinGW / ObjC di Win32 dengan baik, misalnya - dalam arti itu portabel seperti gcc itu sendiri. Tentu saja, perpustakaan tidak akan ada (meskipun ... apakah ada GnuStep / Win32?), Tetapi situasi ini tidak jauh lebih buruk daripada yang kita miliki dengan Mono; jadi secara keseluruhan, menurut saya portabilitas bukanlah poin kuat untuk kedua sisi.
Pavel Minaev
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.