Как Objective C выдерживает сравнение с C#? [закрытый]

Технического обзора здесь нет, но я считаю 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)

Objective-C

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

Выглядит ужасно. Я даже пробовала читать по нему 2 книги, меня рано потеряли, и обычно я не получаю этого с книгами / языками по программированию.

Я рад, что у нас есть Mono для Mac OS, потому что, если бы мне пришлось полагаться на Apple чтобы дать мне хорошую среду разработки ...

Возможно, наиболее важным отличием является управление памятью. С C # вы получаете сборку мусора, так как это язык на основе CLR. С Objective-C вам нужно управлять памятью самостоятельно.

Если вы работаете с C # (или с любого другого современного языка в этом отношении), переход на язык без автоматического управления памятью будет очень болезненным, поскольку вы потратите у вас много времени на кодирование на правильное управление памятью (а также на отладку).

Одна вещь, которая мне нравится в объекте Objective-C, - это то, что объектная система основана на сообщениях, она позволяет вам делать действительно приятные вещи, которые вы не могли сделать в C # (по крайней мере, пока они не поддерживают ключевое слово dynamic!).

Еще одна замечательная вещь в написании приложений какао - это Interface Builder, он намного лучше, чем конструктор форм в Visual Studio.

В obj-c меня (как разработчика C #) раздражает то, что вам нужно управлять собственной памятью (есть сборка мусора, но это не так. работают на iPhone) и что он может быть очень подробным из-за синтаксиса селектора и всех [].

Кроме разницы парадигм между двумя языками, большой разницы нет. Как бы мне не хотелось это говорить, вы можете делать те же вещи (вероятно, не так легко) с .NET и C #, как с Objective-C и Cocoa. Что касается Leopard, Objective-C 2.0 имеет сборку мусора, поэтому у вас нет для самостоятельного управления памятью, если вы этого не хотите (совместимость кода со старыми приложениями Mac и iPhone - это две причины, по которым вы можете захотеть).

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

Я буду первым, кто признает, что я ' m не очень хорошо знаком с C # или .NET. Но перечисленные выше причины, по которым Куинн, - это довольно много причин, по которым я не хочу им становиться.

Вот довольно хорошая статья, в которой сравниваются два языка: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

Вызов методов, используемых в obj-c make для легкого чтения кода, на мой взгляд намного элегантнее, чем c #, и obj-c построен поверх c, поэтому весь код c должен нормально работать в obj-c. Но больше всего мне нравится то, что obj-c является открытым стандартом, поэтому вы можете найти компиляторы для любой системы.

Ручное управление памятью - это то, с чем новички в Objective-C, похоже, больше всего сталкиваются, в основном потому, что они думают, что это более сложно, чем есть на самом деле.

Objective-C и Какао по расширению полагаются о конвенциях по обеспечению соблюдения; знайте и следуйте очень небольшому набору правил, и вы получите много бесплатного взамен за счет динамической среды выполнения.

] alloc должен соответствовать выпуску в конце текущей области.

Далее следует более подробное объяснение.

Управление памятью основано на владении; только владелец экземпляра объекта должен когда-либо освобождать объект, все остальные всегда должны ничего не делать. Это означает, что в 95% всего кода вы относитесь к Objective-C как к сборщику мусора.

А что насчет остальных 5%? У вас есть три метода, на которые нужно обратить внимание: любой экземпляр объекта, полученный из этого метода, принадлежит текущей области метода :

• alloc
• Любой метод, начинающийся со слова new , например new или newService .
• Любой метод, содержащий слово copy, например copy и mutableCopy .

У метода есть три возможных варианта того, что делать с экземплярами принадлежащих ему объектов перед выходом:

• Освободите его, используя выпуск , если он больше не нужен.
• Передайте право собственности на поле a (переменная экземпляра) или глобальную переменную, просто назначив ее.
• Отказаться от владения, но дать кому-то другому возможность стать владельцем до того, как экземпляр исчезнет, ​​вызвав autorelease .

Итак, когда вам следует активно переходить на владение, позвонив сохранить ? Два случая:

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

Как программист, только начинающий работать с Objective-C для iPhone, начиная с C # 4.0, Мне не хватает лямбда-выражений и, в частности, Linq-to-XML. Лямбда-выражения специфичны для C #, в то время как Linq-to-XML на самом деле больше контрастирует между .NET и Cocoa. В примере приложения, которое я писал, у меня был 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 #.