Як Objective-C порівнюється з C #? [зачинено]

Нещодавно я придбав Mac і використовую його в основному для розробки C # під VMWare Fusion. З усіма приємними додатками для Mac навколо, я почав думати про те, щоб Xcode причаївся лише за клацанням миші та вивчив Objective-C.

Синтаксис між двома мовами виглядає дуже по-різному, мабуть, тому, що Objective-C бере свій початок з C, а C # - у Java / C ++. Але можна вивчити різні синтаксиси, так що це повинно бути нормально.

Моє головне занепокоєння - робота з мовою, і якщо це допоможе створити добре структурований, читабельний та елегантний код. Мені дуже подобаються такі функції, як LINQ та var у C #, і цікаво, чи є еквіваленти чи кращі / різні функції в Objective-C.

Які мовні особливості я буду скучати за розробкою з Objective-C? Які функції я отримаю?

Редагувати: Порівняння фреймворків є корисними та цікавими, але мовне порівняння - це те, що насправді задає це питання (частково моя вина за те, що спочатку він мітив теги .net). Імовірно, і Cocoa, і .NET самі по собі є дуже багатими фреймворками, і обидва мають своє призначення, одна націлена на Mac OS X, а інша Windows.

Дякуємо за добре продумані та обґрунтовано збалансовані точки зору на сьогодні!

Жодна мова не ідеально підходить для всіх завдань, і Objective-C не є винятком, але є кілька дуже специфічних приємностей. Як і використання LINQта var(для якого я не знаю прямої заміни), деякі з них суворо пов'язані з мовою, а інші - з фреймворком.

( ПРИМІТКА: Так само, як C # тісно пов'язаний з .NET, Objective-C тісно пов'язаний з какао. Отже, деякі мої зауваження можуть здатися не пов'язаними з Objective-C, але Objective-C без какао схожий на C # без .NET / WPF / LINQ, працює під Mono тощо. Це просто не так, як зазвичай це робиться.)

Я не буду робити вигляд, що повністю обговорюю відмінності, плюси та мінуси, але ось деякі з них нагадують мені.

• Однією з найкращих частин Objective-C є динамічний характер - замість виклику методів ви надсилаєте повідомлення, які середовище виконання динамічно спрямовує. Поєднуючись (розумно) з динамічним набором тексту, це може зробити багато потужних шаблонів простішими або навіть тривіальними у реалізації.

• Як сувора набір C, Objective-C довіряє, що ви знаєте, що робите. На відміну від керованого та / або безпечного для підходів мов, таких як C # та Java, Objective-C дозволяє робити те, що хочеш, і відчувати наслідки. Очевидно, що це може бути часом небезпечним, але той факт, що мова не активно заважає вам робити більшість справ, є досить потужним. ( РЕДАКТУВАТИ: я повинен пояснити, що C # також має "небезпечні" функції та функціональність, але їх поведінкою за замовчуванням є керований код, який вам потрібно явно відмовитись. Для порівняння, Java дозволяє лише безпечний код типу і ніколи не виставляє необроблені вказівники так, як це роблять С та інші.)

• Категорії (додавання / модифікація методів у класі без підкласу чи доступу до джерела) - це приголомшливий двосічний меч. Це може значно спростити ієрархію успадкування та усунути код, але якщо ви робите щось дивне, результати іноді можуть бути незрозумілими.

• Какао робить створення графічних програм набагато простішим у багатьох відношеннях, але вам доведеться обернутися головою навколо парадигми. Дизайн MVC широко поширений у Cocoa, і такі шаблони, як делегати, сповіщення та багатопотокові графічні програми, добре підходять для Objective-C.

• Какао-пов’язки та спостереження за ключовими значеннями можуть усунути тонни клейового коду, і основи какао широко використовують це. Динамічне відправлення Objective-C працює паралельно з цим, тому тип об’єкта не має значення, якщо він відповідає ключовим значенням.

• Швидше за все, ви будете сумувати за дженериками та просторами імен, і вони мають свої переваги, але в мисленні та парадигмі Objective-C вони будуть скоріше приємними, ніж необхідними. (Загальні принципи - це безпека типу та уникнення кастингу, але динамічне введення тексту в Objective-C робить це по суті не проблемою. Простори імен було б непогано, якщо зробити їх якісно, ​​але це досить просто, щоб уникнути конфліктів, оскільки вартість, безперечно, перевищує переваги, для застарілого коду.)

• Для одночасності надзвичайно корисними є Blocks (нова мовна функція в Snow Leopard, яка впроваджена в десятках API какао). Кілька рядків (часто в поєднанні з Grand Central Dispatch, який є частиною libsystem на 10.6) може усунути значні зразки функцій зворотного виклику, контексту тощо (Блоки також можуть використовуватися в C і C ++, і, безумовно, можуть бути додані до C #, що було б приголомшливо.) NSOperationQueue - це також дуже зручний спосіб додати паралельність до власного коду, надіславши або спеціальні підкласи NSOperation, або анонімні блоки, які GCD автоматично виконує для одного або декількох різних потоків.

Я програмую на C, C ++ та C # зараз більше 20 років, вперше розпочавшись у 1990 році. Я щойно вирішив поглянути на розробку iPhone та Xcode та Objective-C. Боже мій ... всі скарги на Microsoft, які я беру назад, я тепер усвідомлюю, наскільки поганим був код. Objective-C надто складний порівняно з тим, що робить C #. Я був розпещений C #, і тепер я ціную всю важку роботу, яку вклала Microsoft. Просто читання Objective-C з викликами методів важко прочитати. C # в цьому елегантний. Це лише моя думка, я сподівався, що мова розробки Apple була такою ж, як і продукти Apple, але дорога мені, у Microsoft є чому повчитися. Немає сумнівів у програмі C # .NET. Я можу запустити програму і запускати її в рази швидше, ніж XCode Objective-C. Apple, звичайно, повинна взяти тут аркуш книги Microsoft, і тоді у нас буде ідеальне середовище. :-)

Тут немає технічного огляду, але я просто вважаю Objective-C набагато менш читабельним. Враховуючи приклад, 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)

Завдання-C

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

Це виглядає жахливо. Я навіть спробував прочитати 2 книги на ньому, вони рано мене загубили, і зазвичай я не розумію цього з програмуванням книг / мов.

Я радий, що у нас є Mono для Mac OS, бо якби мені довелося покластися на Apple, щоб дати мені хороше середовище для розробки ...

Ручне управління пам’яттю - це те, з чим у початківців у Objective-C найбільше проблем, здебільшого тому, що вони вважають, що воно складніше, ніж є.

Objective-C та Cocoa поширюються на домовленості щодо забезпечення; знати і дотримуватися дуже невеликий набір правил, і ви отримаєте багато безкоштовно завдяки динамічному часу виконання у відповідь.

Не 100% істинним правилом, але достатньо хорошим для повсякденності є:

• Кожен виклик до allocмає відповідати значенню a releaseв кінці поточної області дії.
• Якщо повернене значення для вашого методу було отримано до allocцього часу, воно повинно бути повернуто до, return [value autorelease];а не збігатися з release.
• Використовуйте властивості, і немає правила три.

Далі йде довше пояснення.

Управління пам’яттю базується на володінні; тільки власник екземпляра об'єкта повинен коли-небудь звільняти об'єкт, а всі інші завжди нічого не повинні робити. Це означає, що в 95% всього коду ви ставитесь до Objective-C так, ніби це зібране сміття.

То як щодо інших 5%? У вас є три методи, на які слід звернути увагу, будь-який екземпляр об’єкта, отриманий від цього методу, належить поточній області застосування методу :

• alloc
• Будь-який метод, що починається зі слова new , наприклад newабо newService.
• Будь-який метод, що містить слово копія, такий як copyі mutableCopy.

Метод має три можливі варіанти щодо того, що робити з екземплярами об’єкта, що йому належить, до його виходу:

• Звільніть його, releaseякщо це більше не потрібно.
• Надайте право власності на поле (змінну екземпляра) або глобальну змінну, просто призначивши його.
• Позбавтесь права власності, але дайте шанс комусь іншому отримати право власності до того, як екземпляр зникне, зателефонувавши autorelease.

Тож коли слід активно брати участь у власності, телефонуючи retain? Два випадки:

• При призначенні полів у ваших ініціалізаторах.
• При ручному впровадженні методу сетера.

Звичайно, якщо все, що ви бачили у своєму житті, є ціллю C, то її синтаксис виглядає єдино можливим. Ми можемо назвати вас "незайманою програмісткою".

Але оскільки багато коду написано на C, C ++, Java, JavaScript, Pascal та інших мовах, ви побачите, що ObjectiveC відрізняється від усіх, але не в хорошому сенсі. Чи мали для цього причину? Давайте подивимось інші популярні мови:

С ++ додав багато додаткових можливостей до С, але він змінив початковий синтаксис лише настільки, наскільки це було потрібно.

C # додав багато додаткових функцій порівняно з C ++, але змінив лише те, що було потворно в C ++ (наприклад, видалення "::" з інтерфейсу).

Java багато що змінила, але вона зберегла звичний синтаксис, за винятком частин, де потрібні зміни.

JavaScript - це повністю динамічна мова, яка може робити багато речей, які ObjectiveC не може. І все-таки його творці не винайшли нового способу виклику методів та передачі параметрів лише для того, щоб відрізнятися від решти світу.

Visual Basic може передавати параметри не в порядку, як і ObjectiveC. Ви можете назвати параметри, але також можете передавати їх звичайним способом. Що б ви не використовували, це звичайний спосіб, відокремлений комами, який всі розуміють. Кома - це звичайний роздільник не лише в мовах програмування, але й у книгах, газетах та письмовій мові загалом.

Об’єкт Pascal має інший синтаксис, ніж C, але його синтаксис насправді легше читати програмісту (можливо, не комп’ютеру, але кому цікаво, що комп’ютер думає). Тож, можливо, вони відступили, але принаймні їх результат кращий.

Python має інший синтаксис, який навіть легше читати (для людей), ніж Pascal. Тож коли вони змінили це, зробивши його іншим, принаймні вони зробили це кращим для нас, програмістів.

І тоді ми маємо ObjectiveC. Додано деякі вдосконалення в C, але винайдено власний синтаксис інтерфейсу, виклик методу, передачу параметрів і ще ні. Цікаво, чому вони не поміняли місцями + і - так що плюс віднімає два числа. Це було б ще крутіше.

Стів Джобс зіпсувався, підтримавши ObjectiveC. Звичайно, він не може підтримати C #, що краще, але належить його найгіршому конкуренту. Тож це політичне рішення, а не практичне. Технологія завжди страждає, коли технічні рішення приймаються з політичних причин. Йому слід керувати компанією, що йому вдається, і залишити питання програмування справжнім експертам.

Я впевнений, що додатків для iPhone було б ще більше, якби він вирішив писати iOS і підтримувати бібліотеки будь-якою іншою мовою, крім ObjectiveC. Для всіх, крім завзятих шанувальників, незайманих програмістів та Стіва Джобса, ObjectiveC виглядає смішно, потворно і відразливо.

Одне, що мені подобається вцілі-c, це те, що система об'єктів базується на повідомленнях, це дозволяє робити дійсно приємні речі, яких ти не міг зробити в C # (принаймні, поки вони не підтримують динамічне ключове слово!).

Ще одна чудова річ щодо написання програм для какао - це Interface Builder, це набагато приємніше, ніж дизайнер форм у Visual Studio.

Що стосується obj-c, що мене дратує (як розробника C #), це той факт, що ви повинні керувати власною пам’яттю (є збір сміття, але це не працює на iPhone) і що це може бути дуже багатослівно через синтаксис селектора та всі [].

Як програміст, який тільки починає роботу з Objective-C для iPhone, виходячи з версії C # 4.0, мені не вистачає лямбда-виразів, зокрема Linq-to-XML. Ламбда-вирази є специфічними для C #, тоді як Linq-to-XML насправді є більш контрастним .NET проти какао. У прикладі програми, яку я писав, у мене був рядок XML. Я хотів проаналізувати елементи цього XML на колекцію об’єктів.

Щоб досягти цього в Objective-C / Cocoa, мені довелося використовувати клас 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, або просто з’ясувати, чи повернуті якісь елементи ... БАМ, все там же в тому ж рядку коду.

Є багато класів з відкритим кодом, які значно полегшують цю обробку в Objective-C, тому це робить більшу частину важкої роботи. Це просто не це вбудоване.

* ПРИМІТКА: Я насправді не компілював наведений вище код, він просто призначений як приклад, щоб проілюструвати відносну відсутність багатослівності, необхідної для C #.

Ймовірно, найголовніша відмінність - це управління пам’яттю. З C # ви отримуєте збір сміття, оскільки це мова, заснована на CLR. За допомогою Objective-C вам потрібно управляти пам’яттю самостійно.

Якщо ви походите з фону C # (або будь-якої іншої сучасної мови), перехід на мову без автоматичного управління пам’яттю буде дійсно болючим, оскільки ви витратите багато свого часу на кодування на належне управління пам’яттю (і налагодження як Ну).

Ось досить гарна стаття, що порівнює дві мови: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

Окрім різниці в парадигмі між двома мовами, різниці не дуже багато. Як би мені не хотілося це говорити, ви можете робити такі самі речі (мабуть, не так просто) з .NET та C #, як і з Objective-C та Cocoa. Починаючи з Leopard, Objective-C 2.0 має збирання сміття, тому вам не доведеться самостійно керувати пам’яттю, якщо ви цього не хочете (сумісність коду зі старими програмами Mac і iPhone - це дві причини для цього).

Що стосується структурованого, читабельного коду, велика частина тягаря лежить на програмісті, як і на будь-якій іншій мові. Однак я вважаю, що парадигма передачі повідомлень добре піддається читаному коду за умови, що ви належним чином називаєте свої функції / методи (знову ж таки, як і будь-яка інша мова).

Я першим визнаю, що я не дуже знайомий з C # або .NET. Але перелічені вище причини Квін - це чимало причин, через які я не хочу стати такою.

Виклики методів, що використовуються в obj-c, роблять для легко читаного коду, на мій погляд, набагато витонченіший, ніж c #, а obj-c побудований поверх c, тому весь код c повинен працювати нормально в obj-c. Однак для мене великим продавцем є те, що obj-c - це відкритий стандарт, тому ви можете знайти компілятори для будь-якої системи.