Cursos

Swift 2 Lección 8, Protocolos

Compra "Aprendiendo Swift 3"

La presente lección está probada y certificada en su funcionamiento con la versión 7 o superior de Xcode y corresponde a la especificación 2 y 2.1 del lenguaje Swift.

Vimos como una de las novedades de Swift 2, el nuevo concepto de programación orientada a protocolos. Explicamos la teoría, pero antes de ver los ejemplos como tal es importante que sepamos y entendamos cuales son las partes que componen este nuevo concepto de abstracción a la hora de programar. En la anterior lección vimos los structs y ahora los protocolos, la otra parte esencial de esta importante parte de Swift 2.

Protocolos, plantillas de especificación

¿Qué es un protocolo? Es una plantilla a usar cuando queremos tener una especificación común a una serie de clases, structs o enumeraciones. Un protocolo nos permite indicar las cabeceras de funciones o propiedades que queramos se incluyan de manera obligada para cumplir con una especificación que, posteriormente, tendrá una implementación asociada (un código que le de funcionalidad).

El concepto básico es aplicar comportamientos comunes a diferentes objetos, aunque el código de cada uno sea diferente. Por ejemplo, en el caso de un juego podemos tener personajes y estos, según qué casos podrán morir o no. Por lo que podríamos crear un protocolo Mortal, que se puede aplicar a cualquier personaje de nuestro juego, sea cual sea su clase o struct de origen. Cualquier personaje que sea Mortal, podrá morir, aunque cada uno tendrá su propio código (su propia implementación) para hacer que esto sea posible.

Usamos la palabra clave protocol y luego podemos incluir funciones, indicando solo la cabecera que corresponde, o propiedades donde no podemos usar almacenadas si no solo propiedades calculadas que incluyan métodos get o set. En el caso expuesto solo usamos get, pero si tuviéramos la ocasión de usar también el set, simplemente ponemos { get set }.

Si tenemos esta clase, aquí no estamos poniendo protocolo alguno porque hablamos de una clase base que dará soporte a todos los personajes del juego. Pero ahora vamos a crear una subclase de Personaje, que sea un héroe y al que esta vez sí vamos a querer matarlo.

Cuando creamos la nueva clase, y especificamos que estamos creando una subclase de Personaje, seguido con coma ponemos el protocolo y eso nos obliga a incluir aquello que hemos hecho que forme parte del protocolo. Con esto, conseguimos lo que se denomina conformarse a un protocolo. Si quitáramos cualquiera de los dos componentes del protocolo, veríamos que obtenemos un error inmediato porque los protocolos en Swift son obligatorios.

Podemos entender que el héroe tiene un sonido de muerte y una animación, un enemigo que creemos que forme parte del juego (no a lo mejor un personaje secundario que simplemente sirve como “relleno” del mundo donde juguemos) también lo tendrá y de esta forma estamos dando un comportamiento común a diferentes clases obligando a la inclusión de la propiedad muerto y la función muere, pero cada una tendrá un código o implementación diferente.

En caso que quisiéramos que una función de un protocolo pudiera usarse en un struct y que modificara datos propios de dicha estructura, deberíamos incluir la palabra mutating antecediendo al nombre de la función. Si dicho protocolo lo usáramos en una clase, no indicamos mutating y funcionará igualmente. Solo hay que incluir esta cláusula si sabemos que el protocolo podrá ser usado en un struct donde la implementación necesite alterar los datos del propio struct en forma alguna.

Un protocolo, igualmente, nos permite clasificar estructuras por ellos como tipo de dato base, de forma que podríamos crear un array de tipo Mortal e incluir en él tantos objetos como queramos que usen dicho protocolo, structs o variables de una enumeración.

Plantillas

Y esto es básicamente un protocolo: una plantilla que queremos que se cumpla para diferentes tipos de estructuras de datos como clases, structs o enumeraciones. No tiene mayor complejidad y como podemos ver, solo pueden especificar las cabeceras de las funciones y de las propiedades que queramos usar.

Y además, en la versión 2, los protocolos también permiten algo que marca la diferencia a la hora de trabajar con la nueva orientación a estos: la posibilidad de incluir implementaciones por defecto para cualquiera de los componentes del protocolo o la posibilidad de usar elementos opcionales que no tienen por qué ser usados; que no formen parte del mismo protocolo pero que sí se especifiquen.

Pero eso lo veremos en la próxima guía práctica de la Programación Orientada a Protocolos. Hasta entonces, probad, codificar y, como siempre, Good Apple Coding.

Compra "Aprendiendo Swift 3"

Etiquetas

Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Artículos relacionados

Close
Close