c# objective-c

¿Cómo se compara Objective-C con C#?



(11)

Recientemente compré una Mac y la uso principalmente para el desarrollo de C # en VMWare Fusion. Con todas las lindas aplicaciones de Mac, he empezado a pensar que Xcode acecha a solo un clic de distancia de la instalación y aprende Objective-C.

La sintaxis entre los dos lenguajes se ve muy diferente, presumiblemente porque Objective-C tiene sus orígenes en C y C # tiene sus orígenes en Java / C ++. Pero se pueden aprender diferentes sintaxis, así que debería estar bien.

Mi principal preocupación es trabajar con el lenguaje y si esto ayudará a producir código bien estructurado, legible y elegante. Realmente disfruto de características como LINQ y var en C # y me pregunto si hay equivalentes o mejores / diferentes características en Objective-C.

¿Qué características del idioma extrañaré desarrollar con Objective-C? ¿Qué características obtendré?

Editar: Las comparaciones marco son útiles e interesantes, pero una comparación de lenguaje es lo que esta pregunta realmente está pidiendo (en parte es mi culpa por etiquetar originalmente con .net ). Es de suponer que tanto Cocoa como .NET son marcos muy ricos por derecho propio y ambos tienen su propósito, uno dirigido a Mac OS X y al otro Windows.

¡Gracias por los puntos de vista bien pensados ​​y razonablemente equilibrados hasta el momento!

Aparte de la diferencia de paradigma entre los 2 idiomas, no hay mucha diferencia. Por mucho que odie decirlo, puedes hacer el mismo tipo de cosas (probablemente no tan fácilmente) con .NET y C # como puedas con Objective-C y Cocoa. A partir de Leopard, Objective-C 2.0 tiene recolección de basura, por lo que no tiene que administrar la memoria usted mismo a menos que lo desee (la compatibilidad de los códigos con Mac más antiguas y las aplicaciones de iPhone son dos razones por las que desea hacerlo).

En lo que respecta al código estructurado y legible, gran parte de la carga recae en el programador, como en cualquier otro idioma. Sin embargo, considero que el paradigma de transmisión de mensajes se presta bien al código legible siempre que nombre adecuadamente sus funciones / métodos (nuevamente, como cualquier otro idioma).

Seré el primero en admitir que no estoy muy familiarizado con C # o .NET. Pero las razones que mencionó Quinn arriba son bastantes razones por las que no me importa serlo.

Claro, si todo lo que viste en tu vida es el Objetivo C, entonces su sintaxis parece la única posible. Podríamos llamarte una "virgen de programación".

Pero dado que se escribe mucho código en C, C ++, Java, JavaScript, Pascal y otros lenguajes, verá que ObjectiveC es diferente de todos ellos, pero no en el buen sentido. ¿Tenían una razón para esto? Veamos otros idiomas populares:

C ++ agregó muchos extras a C, pero cambió la sintaxis original solo en la medida necesaria.

C # agregó muchos extras en comparación con C ++, pero solo cambió cosas que eran feas en C ++ (como eliminar el "::" de la interfaz).

Java cambió muchas cosas, pero mantuvo la sintaxis familiar, excepto en las partes donde el cambio era necesario.

JavaScript es un lenguaje completamente dinámico que puede hacer muchas cosas que ObjectiveC no puede. Aún así, sus creadores no inventaron una nueva forma de llamar a métodos y pasar parámetros para ser diferentes del resto del mundo.

Visual Basic puede pasar parámetros fuera de servicio, al igual que ObjectiveC. Puede nombrar los parámetros, pero también puede pasarlos de la manera habitual. Lo que sea que uses, es una forma normal delimitada por comas que todos entienden. Comma es el delimitador habitual, no solo en los lenguajes de programación, sino también en los libros, periódicos y el lenguaje escrito en general.

Object Pascal tiene una sintaxis diferente a C, pero su sintaxis es realmente FÁCIL de leer para el programador (tal vez no para la computadora, pero a quién le importa qué equipo piensa). Así que tal vez se digresionaron, pero al menos su resultado es mejor.

Python tiene una sintaxis diferente, que es incluso más fácil de leer (para los humanos) que Pascal. Entonces, cuando lo cambiaron, lo hicieron diferente, al menos lo hicieron mejor para nosotros los programadores.

Y luego tenemos ObjectiveC. Añadiendo algunas mejoras a C, pero inventando su propia sintaxis de interfaz, llamada de método, paso de parámetros y lo que no. Me pregunto por qué no intercambiaron + y - entonces ese más resta dos números. Hubiera sido incluso más genial.

Steve Jobs se equivocó al apoyar a ObjectiveC. Por supuesto que no puede soportar C #, que es mejor, pero pertenece a su peor competidor. Entonces esta es una decisión política, no práctica. La tecnología siempre sufre cuando las decisiones tecnológicas se toman por razones políticas. Debería dirigir la empresa, lo cual hace bien, y dejar los asuntos de programación a expertos reales.

Estoy seguro de que habrá aún más aplicaciones para iPhone si decide escribir iOS y bibliotecas de soporte en cualquier otro idioma que no sea ObjectiveC. Para todos, excepto para fanáticos acérrimos, programadores vírgenes y Steve Jobs, ObjectiveC parece ridículo, feo y repulsivo.

Como programador que acaba de comenzar con Objective-C para iPhone, viniendo de C # 4.0, me faltan expresiones lambda, y en particular, Linq-to-XML. Las expresiones lambda son específicas de C #, mientras que Linq-to-XML es realmente más un contraste .NET vs. Cocoa. En una aplicación de muestra que estaba escribiendo, tenía algo de XML en una cadena. Quería analizar los elementos de ese XML en una colección de objetos.

Para lograr esto en Objective-C / Cocoa, tuve que usar la clase NSXmlParser . Esta clase se basa en otro objeto que implementa el protocolo NSXMLParserDelegate con métodos que se llaman (leer: mensajes enviados) cuando se lee una etiqueta de elemento abierto, cuando se leen algunos datos (generalmente dentro del elemento) y cuando se lee alguna etiqueta de fin de elemento . Debe hacer un seguimiento del estado y el estado del análisis. Y honestamente no tengo idea de qué pasa si el XML no es válido. Es genial para profundizar en los detalles y optimizar el rendimiento, pero, ¡ay !, eso es un montón de código.

Por el contrario, aquí está el código en C #:

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

Y eso es todo, tienes una colección de objetos personalizados extraídos de XML. Si desea filtrar esos elementos por valor, o solo a aquellos que contienen un atributo específico, o si solo quiere los primeros 5, o saltee los primeros 1 y obtenga los 3 siguientes, o simplemente descubra si se devolvieron algunos elementos ... BAM, todo está allí en la misma línea de código.

Hay muchas clases de código abierto que hacen que este procesamiento sea mucho más fácil en Objective-C, por lo que hace gran parte del trabajo pesado. Simplemente no está integrado.

* NOTA: en realidad no compilé el código anterior, solo se trata de un ejemplo para ilustrar la falta relativa de verbosidad requerida por C #.

He estado programando en C, C ++ y C # ahora durante más de 20 años, comencé en 1990. Acabo de decidir echar un vistazo al desarrollo de iPhone y Xcode y Objective-C. Oh, Dios mío ... todas las quejas sobre Microsoft que recupero, ahora me doy cuenta de lo mal que ha sido el código. Objective-C es complejo en comparación con lo que C # hace. Me han echado a perder C # y ahora aprecio todo el arduo trabajo que Microsoft ha realizado. Solo leer Objective-C con invocaciones de métodos es difícil de leer. C # es elegante en esto. Esa es solo mi opinión, esperaba que el lenguaje de desarrollo de Apple fuera tan bueno como los productos de Apple, pero cariño, tienen mucho que aprender de Microsoft. No hay duda de la aplicación C .NET. Puedo ejecutar una aplicación muchas veces más rápido que XCode Objective-C. Apple debería tomar una hoja del libro de Microsoft aquí y luego tendríamos el ambiente perfecto. :-)

La administración manual de la memoria es algo que los principiantes de Objective-C parecen tener más problemas, sobre todo porque piensan que es más complejo de lo que es.

Objective-C y Cocoa por extensión se basan en convenciones sobre la aplicación; conozca y siga un conjunto de reglas muy pequeño y obtendrá mucho gratis a cambio del tiempo de ejecución dinámico.

La regla no es 100% verdadera, pero lo suficientemente buena para todos los días es:

  • Cada llamada a alloc debe coincidir con una release al final del alcance actual.
  • Si el valor de retorno para su método ha sido obtenido por alloc entonces debe devolverse mediante return [value autorelease]; en lugar de ser igualado por un release .
  • Use propiedades, y no hay regla tres.

La explicación más larga sigue.

La administración de la memoria se basa en la propiedad; solo el propietario de una instancia de objeto debe liberar el objeto, todos los demás siempre deben hacer nada. Esto significa que en el 95% de todo el código trata a Objective-C como si fuera basura.

Entonces, ¿qué pasa con el otro 5%? Tiene tres métodos para tener en cuenta, cualquier instancia de objeto recibida de este método pertenece al alcance del método actual:

  • alloc
  • Cualquier método que comience con la palabra nueva , como new o newService .
  • Cualquier método que contenga la palabra copiar, como copy y mutableCopy .

El método tiene tres opciones posibles sobre qué hacer con sus instancias de objetos propiedad antes de que se cierre:

  • Suelte usando release si ya no es necesario.
  • Asigne propiedad al campo a (variable de instancia) o a una variable global simplemente asignándola.
  • Renuncie a la propiedad pero dé a otra persona la oportunidad de tomar posesión antes de que la instancia desaparezca llamando a la autorelease .

Entonces, ¿cuándo debería tomar la propiedad proactivamente llamando a retain ? Dos casos:

  • Al asignar campos en sus inicializadores.
  • Al implementar manualmente el método setter.

Las llamadas a métodos usadas en obj-c hacen que el código sea fácil de leer, en mi opinión mucho más elegante que c # y obj-c está construido sobre c, por lo que todo c código debería funcionar bien en obj-c. Sin embargo, el gran éxito para mí es que obj-c es un estándar abierto para que pueda encontrar compiladores para cualquier sistema.

Ningún lenguaje es perfecto para todas las tareas, y Objective-C no es una excepción, pero hay algunas sutilezas muy específicas. Como usar LINQ y var (para los cuales no tengo conocimiento de un reemplazo directo), algunos de estos están estrictamente relacionados con el lenguaje, y otros están relacionados con el marco.

( NOTA: Así como C # está estrechamente relacionado con .NET, Objective-C está estrechamente relacionado con Cocoa. Por lo tanto, algunos de mis puntos pueden parecer ajenos a Objective-C, pero Objective-C sin Cocoa es similar a C # sin .NET / WPF / LINQ, ejecutándose bajo Mono, etc. Simplemente no es la forma en que normalmente se hacen las cosas).

No voy a pretender elaborar completamente las diferencias, los pros y los contras, pero aquí hay algunos que me vienen a la mente.

  • Una de las mejores partes de Objective-C es la naturaleza dinámica: en lugar de llamar a los métodos, envía mensajes, que el tiempo de ejecución se enruta de forma dinámica. Combinado (juiciosamente) con tipeo dinámico, esto puede hacer que muchos patrones potentes sean más simples o incluso triviales de implementar.

  • Como superconjunto estricto de C, Objective-C confía en que sabes lo que estás haciendo. A diferencia del enfoque administrado y / o de tipo seguro de idiomas como C # y Java, Objective-C te permite hacer lo que quieras y experimentar las consecuencias. Obviamente, esto puede ser peligroso a veces, pero el hecho de que el lenguaje no le impida activamente hacer la mayoría de las cosas es bastante poderoso. ( EDITAR: Debería aclarar que C # también tiene características y funcionalidades "inseguras", pero su comportamiento predeterminado es el código administrado, que debe excluirse explícitamente. En comparación, Java solo permite código de seguridad, y nunca expone punteros crudos en la forma en que C y otros lo hacen).

  • Categorías (agregar / modificar métodos en una clase sin subclases o tener acceso a la fuente) es una increíble espada de doble filo. Puede simplificar enormemente las jerarquías de herencia y eliminar el código, pero si haces algo extraño, los resultados a veces pueden ser desconcertantes.

  • Cocoa hace que la creación de aplicaciones de GUI sea mucho más simple de muchas maneras, pero usted tiene que entender el paradigma. El diseño de MVC es omnipresente en Cocoa, y los patrones como los delegados, las notificaciones y las aplicaciones de GUI de subprocesos múltiples son adecuados para Objective-C.

  • Las consolidaciones de cacao y la observación de valores clave pueden eliminar toneladas de código de pegamento, y los marcos de Cocoa aprovechan esto extensamente. El despacho dinámico de Objective-C trabaja mano a mano con esto, por lo que el tipo de objeto no es importante siempre y cuando cumpla con los valores clave.

  • Es probable que te pierdas genéricos y espacios de nombres, y tienen sus beneficios, pero en la mentalidad y el paradigma de Objective-C, serían sutilezas en lugar de necesidades. (Los genéricos tratan sobre la seguridad del tipo y evitan el casting, pero el tipado dinámico en Objective-C hace que esto no sea un problema. Los espacios de nombres serían buenos si se hacen bien, pero es lo suficientemente simple para evitar conflictos que el costo supera los beneficios, especialmente para el código heredado)

  • Para concurrencia, Blocks (una nueva función de idioma en Snow Leopard, e implementada en puntuaciones de Cocoa API) es extremadamente útil. Algunas líneas (frecuentemente acopladas con Grand Central Dispatch, que es parte de libsystem en 10.6) pueden eliminar un repetitivo significativo de funciones de devolución de llamada, contexto, etc. (Los bloques también se pueden usar en C y C ++, y ciertamente podrían agregarse a C #, lo cual sería increíble.) NSOperationQueue también es una forma muy conveniente de agregar concurrencia a su propio código, mediante el envío de subclases NSOperation personalizadas o bloques anónimos que GCD ejecuta automáticamente en uno o más subprocesos diferentes para usted.

No hay revisión técnica aquí, pero me parece que Objective-C es mucho menos legible. Dado el ejemplo, Cinder6 te dio:

DO#

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 objetivo

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

Se ve horrible. Incluso traté de leer dos libros, me perdieron desde el principio y normalmente no entiendo eso con libros / idiomas de programación.

Me alegra que tengamos Mono para Mac OS, porque si tuviera que confiar en Apple para darme un buen entorno de desarrollo ...

Probablemente la diferencia más importante es la gestión de la memoria. Con C # obtienes recolección de basura, en virtud de que es un lenguaje basado en CLR. Con Objective-C necesita administrar la memoria usted mismo.

Si vienes de un fondo de C # (o de cualquier lenguaje moderno para el caso), pasar a un lenguaje sin administración de memoria automática será realmente doloroso, ya que pasarás mucho tiempo de codificación administrando adecuadamente la memoria (y depurando como bien).

Una de las cosas que me encanta de object-c es que el sistema de objetos se basa en mensajes, te permite hacer cosas realmente lindas que no podrías hacer en C # (al menos no hasta que sean compatibles con la palabra clave dinámica).

Otra gran cosa sobre la escritura de aplicaciones de cacao es Interface Builder, es mucho más agradable que el diseñador de formularios en Visual Studio.

Las cosas sobre obj-c que me molestan (como desarrollador de C #) son el hecho de que tienes que administrar tu propia memoria (hay recolección de basura, pero eso no funciona en el iPhone) y que puede ser muy detallado debido a la sintaxis del selector y todo el [].