ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.
A la hora de programar aplicaciones para el sistema operativo de Apple, iOS, y por lo tanto para crear apps para iPhone y iPad, debes utilizar el lenguaje Objective-C.
Este lenguaje extiende al clásico lenguaje de programación C, añadiéndole capacidades de programación orientada a objetos y sobre todo intentando atajar los problemas de reusabilidad que tenía éste. Su desarrollo se inició en 1981 (¡hace más de 30 años!) por parte de dos programadores entusiastas de la empresa ITT, que luego fundaron su propia empresa para comercializarlo. Se popularizó a finales de la década de los '80 cuando lo licenció un pequeña empresa llamada NEXT, fundada por Steve Jobs tras haber sido expulsado de Apple. Cuando Apple compró NEXT unos años después (en 1996) y Jobs volvió triunfante a su casa, sus sistemas formaron la base de la nueva Apple, y con ellos el lenguaje Objective-C, que nos persigue hasta hoy.
Objective-C es un lenguaje bastante árido y con muchas diferencias frente a lenguajes de propósito más general como C# o Java. Por eso muchos programadores que se meten en la programación para Mac o para iPhone/iPad encuentran su principal barrera en comprender bien y utilizar Objective-C.
Una de las primeras cosas que llaman la atención es que Objective-C es un lenguaje compilado. pero también es al mismo tiempo un lenguaje enlazado . Esto quiere decir básicamente
que el resultado del compilador no es el programa final sino que existe
una segunda fase que lleva a cabo el enlazador (linker en
inglés).
Relación entre compilador y enlazador
El enlazador es el responsable de recoger el código compilado y de
"juntarlo" con otro código compilado: el de las librerías que tu programa
utilice (sean de sistema o de terceros).
Este concepto te sorprenderá si
vienes de C# o Java. En estos lenguajes el concepto de enlazado no existe:
si quieres utilizar una librería (un assembly o
bien un fichero .jar) te limitas a "referenciarlo" desde tu
proyecto. Automáticamente, sin que tengas que hacer nada más, todas las
clases definidas en esta librería las tienes disponibles. En tiempo de
ejecución basta con que el ordenador de destino tenga las librerías
instaladas para que tu programa funcione. En estos lenguajes esto es
posible porque el código compilado (ya sean assemblies de .NET o
archivos .class de Java) expone metadatos que informan de qué
tipos existen, qué métodos tienen y en general todo lo que el compilador
necesita para poder compilar el código.
En Objective-C esto no funciona así. Cuando usas una librería (ya sea del
sistema o de terceros), el compilador no la necesita para nada. Tampoco
puede hacer nada con ella: el código compilado no expone metadatos que
permitan leerlo para saber qué tipos hay definidos y qué métodos tienen.
Así que para poder utilizar la librería se debe suministrar al compilador
uno, o varios, archivos de código fuente que definan la clase y todos sus
métodos (tan solo la firma de los métodos, no la implementación). Dichos
archivos reciben el nombre de archivos de cabecera o headers
(del inglés), tienen (o suelen tener) la extensión .h
y por supuesto, no los creas tú sino que los crea quien haya hecho la
librería.
Así que cuando uses una librería en Objective-C, tendrás el código
compilado y uno o varios archivos de cabecera que contienen la definición
de las clases y métodos de esa librería. El compilador tan solo utiliza la
información de los ficheros de cabecera y es el enlazador quien recoge el
código compilado generado por el compilador, los binarios de las librerías
y lo enlaza todo en el programa final.
No voy a entrar en detalles sobre cómo funciona el proceso exactamente, tan solo insistiré en los dos
puntos fundamentales:
- El compilador tan solo tiene en cuenta los archivos de cabecera. Por
lo tanto si una clase no está definida en los archivos de cabecera es
como si no existiese. No podrás usarla porque no existirá para el
compilador. Eso elimina la necesidad de tener una visibilidad para las
clases (como es el caso de internal class
en C#).
- El enlazador es un paso posterior al compilador. Eso significa que un
código puede compilar bien (es decir, que el código Objective-C es
válido y que todos los headers existen) pero tener errores del
enlazador (lo que significa que alguna de las librerías no se encuentra
o no contiene realmente las clases o métodos que define el archivo de cabecera).
Por lo tanto, por ejemplo, cuando creas una librería para ser utilizada por
terceros, debes suministrar además de los binarios, todos los archivos de
cabecera necesarios para quien use tu librería.
Existen muchas diferencias entre Objective-C y lenguajes "tradicionales". Esta es la primera y en sucesivos artículos veremos algunas más.
Fecha de publicación: