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

Je programme en C, C++ et C# depuis plus de 20 ans, commencé en 1990. Je viens de décider de jeter un oeil au développement de l'iPhone et Xcode et Objective-C. Oh mon Dieu... toutes les plaintes concernant Microsoft que je retire, je me rends compte maintenant à quel point le code des choses a été mauvais. Objective-C est plus complexe par rapport à ce que fait C#. J'ai été gâté avec C# et maintenant j'apprécie tout le travail dur que Microsoft a mis. Il suffit de lire Objective-C avec la méthode appelle est difficile lire. C# est élégant dans ce domaine. C'est juste mon avis, j'espérais que le langage de développement D'Apple était un bon que les produits Apple, mais cher moi, ils ont beaucoup à apprendre de Microsoft. Il n'y a pas de question C#.NET application je peux obtenir une application en cours d'exécution plusieurs fois plus rapide que Xcode Objective-C. Apple devrait certainement prendre une feuille sur le livre de Microsoft ici et nous aurions 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 tôt, et normalement, Je ne comprends pas cela avec la programmation de livres / langages.

Je suis heureux que nous ayons Mono pour Mac OS, parce que si j'avais dû compter sur Apple pour me donner un bon environnement de développement...

La gestion manuelle de la mémoire est quelque chose que les débutants à Objective-C semblent avoir le plus de problèmes, surtout parce qu'ils pensent que c'est plus complexe qu'il ne l'est.

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

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

• Chaque appel de alloc doit être mis en correspondance avec un release, au la fin de la portée actuelle.
• si la valeur de retour de votre méthode a été obtenue par alloc alors elle devrait être retournée par return [value autorelease]; au lieu d'être appariée par un release.
• 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é; seulement le propriétaire d'une instance d'objet devrait jamais libérer l'objet, Tout le monde autre ne devrait toujours rien faire. Cela signifie que dans 95% des tout le code que vous traitez Objective-C comme s'il était collecté.

Et les 5% restants? Vous avez trois méthodes à rechercher, toute instance d'objet reçue de cette méthode appartient à la portée de la méthode actuelle :

• alloc
• la méthode, qui commence avec le mot nouveaux, comme new ou newService.
• toute méthode contenant la copie de mot, telle que copy et mutableCopy.

La méthode a trois options possibles à partir de quoi à faire avec ses instances d'objet possédées avant sa sortie:

• relâchez-le en utilisant release s'il n'est plus nécessaire.
• donnez la propriété au champ a (variable d'instance) , ou à une variable globale en l'affectant simplement.
• renoncer à la propriété mais donner à quelqu'un d'autre une chance de prendre la propriété avant que l'instance disparaît en appelant autorelease.

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

• quand affectation de champs dans vos initialiseurs.
• lors de l'implémentation manuelle de la méthode setter.

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

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

C++ a ajouté beaucoup d'extras à C, mais il a changé la syntaxe d'origine seulement autant que nécessaire.

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

Java a changé beaucoup de choses, mais il a gardé 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 que 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 de la monde.

Visual Basic peut passer des paramètres hors service, tout comme ObjectiveC. Vous pouvez nommer les paramètres, mais vous pouvez également les transmettre de la façon habituelle. Quoi que vous utilisiez, c'est normal délimité par des virgules que tout le monde comprend. La virgule est le délimiteur habituel, pas seulement dans les langages de programmation, mais dans les livres, les journaux et le langage écrit 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 le ordinateur, mais qui se soucie de ce que l'ordinateur pense). Alors peut-être qu'ils ont digressé, mais au moins leur résultat est meilleur.

Python a une syntaxe différente, ce qui est encore plus facile à lire (pour les humains) que Pascal. Alors, quand ils l'ont changé, rendant différent, au moins ils ont fait de mieux pour nous les programmeurs.

Et puis nous avons ObjectiveC. Ajouter quelques améliorations à C, mais inventer sa propre syntaxe d'interface, l'appel de méthode, le passage de paramètre et ce qui ne l'est pas. Je me demande pourquoi n'ont-ils pas échangé + et - donc, plus soustrait deux nombres. Il aurait été encore plus frais.

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 pratique. La technologie souffre toujours lorsque les décisions technologiques sont prises pour des raisons politiques. Il devrait 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 a décidé d'écrire iOS et de soutenir les bibliothèques dans une autre langue que ObjectiveC. Pour tout le monde, sauf les fans purs et durs, les programmeurs virgin et Steve Jobs, ObjectiveC a l'air ridicule, laid et repoussant.

Une chose que j'aime à propos d'objective-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 jusqu'à ce qu'ils prennent en charge le mot-clé dynamique!).

Une autre grande chose à propos de l'écriture des applications cocoa est Interface Builder, il est beaucoup plus agréable que le concepteur de formulaires dans Visual Studio.

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

En tant que programmeur débutant avec Objective-C pour iPhone, provenant 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 le 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 y parvenir dans Objective-C / Cocoa, j'ai dû utiliser la classe NSXmlParser . Cette classe repose sur un autre objet qui implémente le protocole NSXMLParserDelegate avec des méthodes appelées (read: messages sent) lorsqu'une balise d'ouverture 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 garder une trace de l'analyse du statut et de l'état. Et honnêtement, je n'ai aucune idée de ce qui se passe si le XML est invalide. C'est génial pour arriver aux 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 seulement à ceux qui contiennent un attribut spécifique, ou si vous vouliez juste le premier 5, ou sauter le premier 1 et obtenir le suivant 3, ou simplement savoir si des éléments ont été retournés... BAM, tout juste là dans la même ligne de code.

Il existe de nombreuses classes open-source qui rendent ce traitement beaucoup plus facile dans Objective-C, de sorte que fait une grande partie du levage de charges lourdes. Il n'est tout simplement pas construit dans cette.

* NOTE: je n'ai pas compilé le code ci-dessus, c'est juste un exemple pour 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 la collecte des ordures, en raison du fait qu'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 n'importe quel langage moderne d'ailleurs), passer à un langage sans gestion automatique de la mémoire sera vraiment douloureux, car vous passerez beaucoup de votre temps de codage à gérer correctement la mémoire (et le débogage aussi).

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

Autre que 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 avec Objective-C et Cocoa. Depuis Leopard, Objective-C 2.0 a garbage collection, donc vous n'avez pas pour gérer vous-même la mémoire sauf si vous le souhaitez (la compatibilité du code avec les anciens Mac et les applications iPhone sont 2 raisons de vouloir).

Dans la mesure où structuré, lisible le code est concerné, une grande partie du fardeau incombe au programmeur, comme avec n'importe quelle autre langue. Cependant, je trouve que le paradigme de passage de message se prête bien au code lisible à condition que vous nommiez 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 énumérées ci-dessus sont quelques raisons pour lesquelles Je ne me soucie pas de le devenir.

Les appels de méthode utilisés dans obj-C permettent de lire facilement le code, à mon avis beaucoup plus élégant que c# et obj-c est construit sur 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 donc vous pouvez trouver des compilateurs pour n'importe