Hace poco encontré en San Francisco una academia de Inglés que se dedica a algo muy concreto y peculiar: eliminar acentos extranjeros.
En los próximos artículos haré algo similar: vamos a eliminar tu acento Objective C de Swift. El objetivo es que hables Swift como un nativo, sin que se te note de donde vienes.
Ni que decir que esta serie de artículos también sirve para aquellos que vienen directamente a Swift sin haber pasado por Objective C previamente. Si antes programabas en Java, o en C#, ésta también es tu clínica: ¡eliminaremos tu acento de pueblo! 😉
¿Qué encontrarás en este post?
ToggleCódigo Swiftero
¿En qué consiste el código Swiftero? Escribir bien en un lenguaje consiste básicamente en no llevarle la contraria. Todo lenguaje viene pensado para que lo uses de una determinada forma, y no hay error más pernicioso e innecesario que ir a contrapelo del lenguaje. Este es uno de los principios fundamentales de la Ingeniería de Software:Don’t fight the framework (or the language)!Veamos cuales serían las características de Swift, tal y como fue creado, y antes que le dijesen a Lattner: “¡Esto tiene que funcionar con Cocoa!”.
- Lenguaje funcional, pero sin extremismos puristas. Uséase, más pragmático que Haskell (el Khomeini de los lenguajes funcionales).
- Poco o nada orientado a objeto.
- Tipado estático.
- No hay objeto nulo (nil).
Programación Funcional
La primera parte es fácil y divertida de aprender. La programación funcional, aunque algo oculta por la morralla sintáctica y el tipado estricto, es fascinante y algo que todo desarrollador debería de aprender. Claro está que es más fácil con un lenguaje dinámico y con sintaxis casi inexistente de tan sencilla como Scheme o Lisp, pero aun así Swift es mucho más llevadero que Haskell.No orientado a objetos
La segunda parte es donde nos vamos a estrellar un poco, ya que la mayoría venimos ya entrenados para pensar en forma de objetos que envían y reciben mensajes. Por si fuera poco, hubo que modificar y adaptar el núcleo de Swift para que interactuase bien con Cocoa y Objective C. Estos últimos son profundamente orientados a objetos y la convivencia no es siempre muy fácil. Esto está cambiando y se está reescribiendo al menos Foundation para que se adapte mejor a Swift.Tipado estático
El tercer punto, el tipado estático será más difícil si eras un desarrollador senior de Objective C, ya que es una forma totalmente opuesta de trabajar. Aquí la clave es relajarse y disfrutar. Nada de pelearse con el sistema de tipos, al contrario, vamos a hacer que trabaje para nosotros. Esta parte probablemente será lo que más tiempo te lleve, sobre todo si vienes de Objective C en vez de Haskell u OCaml.Ni nil ni hostias
La cuarta parte llama mucho la atención, pero es de ínfima importancia: en vez de un nil seguro como teníamos en Objective C, tenemos un Optional seguro. En el fondo, es el mismo perro con distinto collar.Las 7 cosas que tienes que saber para escribir código Swiftero
Los puntos claves que vamos a tocar a lo largo de esta serie son los siguientes:- NO uses Opcionales a no ser que sea absolutamente indispensable. Este es el error más común, en gran parte porque Xcode lo incentiva. Los Opcionales son una forma de gestionar una situación excepcional: cuando no tenemos valor para una variable. Por lo tanto, no podemos usarlos de forma generalizada, son la excepción.
- NO quiero ver un solo ! en tu código (salvo contadísimas excepciones). Una vez más Xcode es el culpable.
- NO crees jamás un init? en tus clases. El init? es una chapuza inventada para salir al paso de clases de Cocoa como NSURL que devuelven nil en caso de fallo.
- No uses for si un map o flatmap te sirve.
- Saca todo el provecho a las Enums.
- Pon el sistema de tipos a trabajar para ti, no al revés.
- Usa structs y protocolos en vez de clases y herencia (Protocol Oriented Programming que se dice ahora).