Comment Objective-C se compare-t-il à C #? [fermé]

J'ai récemment acheté un Mac et je l'utilise principalement pour le développement C # sous VMWare Fusion. Avec toutes les belles applications Mac, j'ai commencé à penser à Xcode qui se cache à un clic d'installation et à apprendre Objective-C.

La syntaxe entre les deux langages est très différente, probablement parce que Objective-C a ses origines en C et C # a ses origines en Java / C ++. Mais différentes syntaxes peuvent être apprises, ce qui devrait être correct.

Ma principale préoccupation est de travailler avec le langage et de savoir si cela aidera à produire du code bien structuré, lisible et élégant. J'apprécie vraiment les fonctionnalités telles que LINQ et var en C # et je me demande s'il existe des équivalents ou des fonctionnalités meilleures / différentes dans Objective-C.

Quelles fonctionnalités du langage me manqueront-elles en développant avec Objective-C? Quelles fonctionnalités vais-je gagner?

Edit: Les comparaisons de cadres sont utiles et intéressantes, mais une comparaison de langue est ce que cette question pose vraiment (en partie ma faute pour le tag initial avec.net ). On peut supposer que Cocoa et .NET sont des frameworks très riches à part entière et ont tous deux leur objectif, l'un ciblant Mac OS X et l'autre Windows.

Merci pour les points de vue bien pensés et raisonnablement équilibrés jusqu'à présent!

Aucun langage n'est parfait pour toutes les tâches, et Objective-C ne fait pas exception, mais il existe des subtilités très spécifiques. Comme utiliserLINQ and var(pour lequel je ne suis pas au courant d'un remplacement direct), certains d'entre eux sont strictement liés au langage, et d'autres sont liés au cadre.

( REMARQUE: tout comme C # est étroitement couplé avec .NET, Objective-C est étroitement couplé avec Cocoa. Par conséquent, certains de mes points peuvent sembler sans rapport avec Objective-C, mais Objective-C sans Cocoa s'apparente à C # sans .NET / WPF / LINQ, fonctionnant sous Mono, etc. Ce n'est tout simplement pas la façon dont les choses se font habituellement.)

Je ne prétendrai pas expliquer complètement les différences, les avantages et les inconvénients, mais en voici quelques-uns qui me viennent à l'esprit.

• L'une des meilleures parties d'Objective-C est la nature dynamique - plutôt que d'appeler des méthodes, vous envoyez des messages, que le runtime achemine dynamiquement. Combiné (judicieusement) avec le typage dynamique, cela peut rendre de nombreux modèles puissants plus simples ou même triviaux à implémenter.

• En tant que sur-ensemble strict de C, Objective-C croit que vous savez ce que vous faites. Contrairement à l'approche gérée et / ou sécurisée de langages comme C # et Java, Objective-C vous permet de faire ce que vous voulez et d'en ressentir les conséquences. Évidemment, cela peut parfois être dangereux, mais le fait que la langue ne vous empêche pas activement de faire la plupart des choses est assez puissant. ( EDIT: Je dois préciser que C # a également des fonctionnalités et des fonctionnalités "non sécurisées", mais le comportement par défaut est le code géré, que vous devez explicitement désactiver. Par comparaison, Java uniquement permet, et jamais pour typesafe le code expose des pointeurs premières en comme le font C et d'autres.)

• Les catégories (ajouter / modifier des méthodes sur une classe sans sous-classer ou avoir accès aux sources) est une épée à double tranchant impressionnante. Cela peut considérablement simplifier les hiérarchies d'héritage et éliminer le code, mais si vous faites quelque chose d'étrange, les résultats peuvent parfois être déconcertants.

• Cocoa rend la création d'applications GUI beaucoup plus simple à bien des égards, mais vous devez comprendre le paradigme. La conception MVC est omniprésente dans Cocoa et les modèles tels que les délégués, les notifications et les applications d'interface graphique multithread sont bien adaptés à Objective-C.

• Les liaisons Cocoa et l'observation des valeurs clés peuvent éliminer des tonnes de code glue, et les frameworks Cocoa en tirent largement parti. La répartition dynamique d'Objective-C fonctionne de pair avec cela, de sorte que le type de l'objet n'a pas d'importance tant qu'il est conforme à la valeur clé.

• Vous manquerez probablement des génériques et des espaces de noms, et ils ont leurs avantages, mais dans l'état d'esprit et le paradigme Objective-C, ce seraient des subtilités plutôt que des nécessités. (Les génériques sont tous une question de sécurité de type et d'éviter la conversion, mais le typage dynamique en Objective-C en fait essentiellement un non-problème. Les espaces de noms seraient bien s'ils étaient bien faits, mais c'est assez simple pour éviter les conflits que le coût dépasse sans doute les avantages, en particulier pour le code hérité.)

• Pour la concurrence, les blocs (une nouvelle fonctionnalité de langage de Snow Leopard et implémentée dans de nombreuses API Cocoa) sont extrêmement utiles. Quelques lignes (fréquemment couplées à Grand Central Dispatch, qui fait partie de libsystem sur 10.6) peuvent éliminer un passe-partout important de fonctions de rappel, de contexte, etc. (les blocs peuvent également être utilisés en C et C ++, et pourraient certainement être ajoutés à C #, Ce serait génial.) NSOperationQueue est également un moyen très pratique d'ajouter la concurrence à votre propre code, en distribuant soit des sous-classes NSOperation personnalisées, soit des blocs anonymes que GCD exécute automatiquement sur un ou plusieurs threads différents pour vous.

Je programme en C, C ++ et C # maintenant depuis plus de 20 ans, commencé en 1990. Je viens de décider de jeter un œil au développement iPhone et Xcode et Objective-C. Oh mon Dieu ... toutes les plaintes concernant Microsoft que je reprends, je me rends compte maintenant à quel point le code a été mauvais. Objective-C est trop complexe par rapport à ce que fait C #. J'ai été gâté avec C # et maintenant j'apprécie tout le travail acharné de Microsoft. Il est difficile de lire simplement Objective-C avec la méthode invoque. C # est élégant dans ce domaine. C'est juste mon avis, j'espérais que le langage de développement Apple était aussi bon que les produits Apple, mais cher moi, ils ont beaucoup à apprendre de Microsoft. Il n'y a aucune question d'application C # .NET Je peux obtenir une application opérationnelle plusieurs fois plus rapidement que XCode Objective-C. Apple devrait certainement prendre une feuille du livre de Microsoft ici et nous aurions alors l'environnement parfait. :-)

Pas de revue technique ici, mais je trouve juste Objective-C beaucoup moins lisible. Compte tenu de l'exemple que Cinder6 vous a donné:

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)

Objectif c

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

Ça a l'air horrible. J'ai même essayé de lire 2 livres dessus, ils m'ont perdu très tôt, et normalement je ne comprends pas ça avec les livres / langages de programmation.

Je suis content que nous ayons Mono pour Mac OS, car si je devais compter sur Apple pour me donner un bon environnement de développement ...

La gestion manuelle de la mémoire est quelque chose avec laquelle les débutants d'Objective-C semblent avoir le plus de problèmes, principalement parce qu'ils pensent qu'elle est plus complexe qu'elle ne l'est.

Objective-C et Cocoa par extension s'appuient sur des conventions de mise en application; connaître et suivre un très petit ensemble de règles et vous en obtenez beaucoup gratuitement grâce à l'exécution dynamique en retour.

La règle pas 100% vraie, mais assez bonne pour tous les jours est:

• Chaque appel à allocdoit être associé à unrelease à la fin de la portée actuelle.
• Si la valeur de retour de votre méthode a été obtenue d'ici alloclà, elle doit être renvoyée par return [value autorelease];au lieu d'être mise en correspondance par unrelease .
• Utilisez les propriétés et il n'y a pas de règle trois.

L'explication plus longue suit.

La gestion de la mémoire est basée sur la propriété; seul le propriétaire d'une instance d'objet devrait jamais libérer l'objet, tout le monde ne devrait toujours rien faire. Cela signifie que dans 95% de tout le code, vous traitez Objective-C comme s'il s'agissait d'un ramasse-miettes.

Alors qu'en est-il des 5% restants? Vous avez trois méthodes à rechercher, toute instance d'objet reçue de ces méthodes appartient à la portée de la méthode actuelle :

• alloc
• Toute méthode commençant par le mot nouveau , comme newou newService.
• Toute méthode contenant le mot copie, telle que copyet mutableCopy.

La méthode a trois options possibles quant à ce qu'il faut faire avec ses instances d'objet possédées avant sa fermeture:

• Relâchez-le en utilisant releases'il n'est plus nécessaire.
• Donner la propriété du champ a (variable d'instance) ou à une variable globale en l'attribuant simplement.
• Renoncez à la propriété, mais donnez à quelqu'un d'autre une chance de devenir propriétaire avant que l'instance ne disparaisse en appelant autorelease.

Alors, quand devriez-vous vous approprier pro-activement en appelant retain? Deux cas:

• Lors de l'affectation de champs dans vos initialiseurs.
• Lors de la mise en œuvre manuelle de la méthode setter.

Bien sûr, si tout ce que vous avez vu dans votre vie est l'Objectif C, alors sa syntaxe ressemble à la seule possible. Nous pourrions vous appeler une "vierge de la programmation".

Mais comme beaucoup de code est écrit en C, C ++, Java, JavaScript, Pascal et d'autres langages, vous verrez qu'ObjectiveC est différent de tous, mais pas dans le bon sens. Avaient-ils une raison à cela? Voyons d'autres langues populaires:

C ++ a ajouté de nombreux extras à C, mais il n'a changé la syntaxe d'origine que dans la mesure nécessaire.

C # a ajouté beaucoup d'extras par rapport au C ++, mais il n'a changé que des choses qui étaient laides en C ++ (comme supprimer le "::" de l'interface).

Java a changé beaucoup de choses, mais il a conservé la syntaxe familière sauf dans les parties où le changement était nécessaire.

JavaScript est un langage complètement dynamique qui peut faire beaucoup de choses qu'ObjectiveC ne peut pas faire. Pourtant, ses créateurs n'ont pas inventé une nouvelle façon d'appeler des méthodes et de passer des paramètres juste pour être différents du reste du monde.

Visual Basic peut passer des paramètres dans le désordre, tout comme ObjectiveC. Vous pouvez nommer les paramètres, mais vous pouvez également les transmettre de la manière habituelle. Quoi que vous utilisiez, c'est une manière normale délimitée par des virgules que tout le monde comprend. La virgule est le délimiteur habituel, non seulement dans les langages de programmation, mais dans les livres, les journaux et la langue écrite en général.

Object Pascal a une syntaxe différente de C, mais sa syntaxe est en fait PLUS FACILE à lire pour le programmeur (peut-être pas pour l'ordinateur, mais qui se soucie de ce que pense l'ordinateur). Alors peut-être qu'ils ont digressé, mais au moins leur résultat est meilleur.

Python a une syntaxe différente, qui est encore plus facile à lire (pour les humains) que Pascal. Donc, quand ils l'ont changé, le rendant différent, au moins ils l'ont amélioré pour nous, les programmeurs.

Et puis nous avons ObjectiveC. Ajout de quelques améliorations à C, mais inventant sa propre syntaxe d'interface, appel de méthode, passage de paramètres et autres. Je me demande pourquoi n'ont-ils pas échangé + et - de sorte que plus soustrait deux nombres. Ça aurait été encore plus cool.

Steve Jobs a foiré en soutenant ObjectiveC. Bien sûr, il ne peut pas supporter C #, ce qui est mieux, mais appartient à son pire concurrent. C'est donc une décision politique, pas une décision pratique. La technologie souffre toujours lorsque les décisions technologiques sont prises pour des raisons politiques. Il doit diriger l'entreprise, ce qu'il fait bien, et laisser les questions de programmation à de vrais experts.

Je suis sûr qu'il y aurait encore plus d'applications pour iPhone s'il décidait d'écrire iOS et de prendre en charge les bibliothèques dans un autre langage que ObjectiveC. Pour tout le monde, sauf les fans inconditionnels, les programmeurs vierges et Steve Jobs, ObjectiveC semble ridicule, laid et répugnant.

Une chose que j'aime à propos d'objectif-c est que le système d'objets est basé sur des messages, il vous permet de faire de très belles choses que vous ne pourriez pas faire en C # (du moins pas tant qu'ils ne supportent pas le mot-clé dynamic!).

Interface Builder est un autre avantage de l'écriture d'applications cacao, c'est beaucoup plus agréable que le concepteur de formulaires de Visual Studio.

Les choses à propos d'obj-c qui me gênent (en tant que développeur C #) sont le fait que vous devez gérer votre propre mémoire (il y a le ramasse-miettes, mais cela ne fonctionne pas sur l'iPhone) et que cela peut être très verbeux à cause de la syntaxe du sélecteur et tous les [].

En tant que programmeur débutant avec Objective-C pour iPhone, issu de C # 4.0, il me manque des expressions lambda, et en particulier Linq-to-XML. Les expressions lambda sont spécifiques à C #, tandis que Linq-to-XML est vraiment plus un contraste .NET vs Cocoa. Dans un exemple d'application que j'écrivais, j'avais du XML dans une chaîne. Je voulais analyser les éléments de ce XML dans une collection d'objets.

Pour accomplir cela dans Objective-C / Cocoa, j'ai dû utiliser la classe NSXmlParser . Cette classe s'appuie sur un autre objet qui implémente le protocole NSXMLParserDelegate avec des méthodes qui sont appelées (read: messages envoyés) lorsqu'une balise ouverte d'élément est lue, lorsque certaines données sont lues (généralement à l'intérieur de l'élément), et lorsqu'une balise de fin d'élément est lue . Vous devez suivre l'état et l'état de l'analyse. Et honnêtement, je n'ai aucune idée de ce qui se passe si le XML est invalide. C'est génial pour aller dans les détails et optimiser les performances, mais oh mec, c'est beaucoup de code.

En revanche, voici le code en C #:

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

Et c'est tout, vous avez une collection d'objets personnalisés tirés de XML. Si vous vouliez filtrer ces éléments par valeur, ou uniquement ceux qui contiennent un attribut spécifique, ou si vous vouliez simplement les 5 premiers, ou sauter le premier 1 et obtenir les 3 suivants, ou simplement savoir si des éléments ont été renvoyés ... BAM, tout est là dans la même ligne de code.

Il existe de nombreuses classes open-source qui rendent ce traitement beaucoup plus facile en Objective-C, ce qui fait une grande partie du gros du travail. Ce n'est tout simplement pas intégré.

* REMARQUE: je n'ai pas compilé le code ci-dessus, il est simplement destiné à illustrer le manque relatif de verbosité requis par C #.

La différence la plus importante est probablement la gestion de la mémoire. Avec C #, vous obtenez un garbage collection, car il s'agit d'un langage basé sur CLR. Avec Objective-C, vous devez gérer vous-même la mémoire.

Si vous venez d'un arrière-plan C # (ou de tout autre langage moderne d'ailleurs), passer à un langage sans gestion automatique de la mémoire sera vraiment douloureux, car vous passerez beaucoup de temps à coder à bien gérer la mémoire (et à déboguer en tant que bien).

Voici un très bon article comparant les deux langues: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

Hormis la différence de paradigme entre les 2 langues, il n'y a pas beaucoup de différence. Autant que je déteste le dire, vous pouvez faire le même genre de choses (probablement pas aussi facilement) avec .NET et C # que vous pouvez le faire avec Objective-C et Cocoa. A partir de Leopard, Objective-C 2.0 a la collecte des ordures, de sorte que vous ne devez gérer vous - même la mémoire sauf si vous voulez ( la compatibilité du code avec les anciens Mac et les applications iPhone sont 2 raisons de vouloir).

En ce qui concerne le code structuré et lisible, une grande partie du fardeau incombe au programmeur, comme à tout autre langage. Cependant, je trouve que le paradigme de passage de message se prête bien au code lisible à condition que vous nommez vos fonctions / méthodes de manière appropriée (encore une fois, comme n'importe quel autre langage).

Je serai le premier à admettre que je ne suis pas très familier avec C # ou .NET. Mais les raisons que Quinn a énumérées ci-dessus sont plusieurs raisons pour lesquelles je ne veux pas le devenir.

Les appels de méthode utilisés dans obj-c facilitent la lecture du code, à mon avis beaucoup plus élégant que c # et obj-c est construit au-dessus de c donc tout le code c devrait fonctionner correctement dans obj-c. Le gros vendeur pour moi est que obj-c est un standard ouvert, vous pouvez donc trouver des compilateurs pour n'importe quel système.