Get real time updates directly on you device, subscribe now.
En este Tutorial Swift aprenderemos acerca de los protocolos con tipos asociados (associatedtype), un tema que da seguimiento al artículo sobre código genérico. Para entender cuan importante son los tipos asociados o los associated types primero necesitamos hacer una introducción, ponernos en contexto.
[anuncio_b30 id=1]
Cuando definimos un protocolo y tenemos que declarar la firma de un método genérico nos encontramos ante un problema. Como ya sabemos en el caso de los métodos genéricos no sabemos con antelación que tipo de dato este manejará, entonces ¿cómo especificamos esto dentro de la declaración del protocolo teniendo en cuenta de que no podemos usar T?
AssociatedType
La solución al problema anterior reside en el uso de tipos asociados como parte de la propia definición del protocolo, siendo esta la vía de hacer referencia a este valor a priori del tipo de dato final.
Mejor veamos un ejemplo de un tipo asociado en acción:
protocol Container {
associatedtype ItemType
mutating func append(item: ItemType)
var count: Int { get }
subscript(i: Int) -> ItemType { get }
} // Container …el tipo asociado (associatedtype) de nombre ItemType enmascara un tipo de dato que aún no se conoce y es evidente que así sea, ya que nosotros desconocemos quien implementará el protocolo y por ende el tipo de dato que usará. Dicho esto, nos damos cuenta de la similitud, ItemType funge como un comodín y esto nos recuerda el artículo sobre código genérico, nos recuerda a T.
[anuncio_b30 id=2]
El protocolo Container define tres requerimientos que todo aquel que lo adopte tiene que cumplir:
- Tiene que permitir agregar un elemento nuevo al contenedor haciendo uso del método append(_:).
- Tiene que permitir el acceso al número de elementos que forman parte del contenedor a través de la propiedad count.
- Tiene que permitir obtener cada elemento del contenedor con un subscript que reciba como parámetro el índice del valor.
Como podemos constatar este protocolo no especifica como se almacenarán los elementos en el contenedor o de que tipo de dato estos debieran de ser, solamente se declaran las tres funcionalidades que tienen que ser implementadas para que pueda ser adoptado satisfactoriamente.
Veamos un ejemplo de este protocolo en uso:
protocol Container {
associatedtype ItemType
mutating func append(item: ItemType)
var count: Int { get }
subscript(i: Int) -> ItemType { get }
} // Container
struct IntStack: Container {
var items = [Int]()
typealias ItemType = Int
mutating func push(item: Int) {
items.append(item)
} // push
mutating func pop() -> Int {
return items.removeLast()
} // pop
mutating func append(item: Int) {
self.push(item)
} // append
var count: Int {
return items.count
} // count
subscript(i: Int) -> Int {
return items[i]
} // subscript
} // IntStack A partir de la línea 29 vemos las características asociadas al protocolo, y de hecho también en esta misma línea igualamos ItemType al tipo de dato numérico Int. Por razones más que evidentes en este punto ya conocemos que la Pila IntStack, como su propio nombre lo indica, trabaja solamente con el tipo Int, por ende en esta línea estamos informando al compilador de manera explicita de que el tipo ItemType ya no es desconocido.
[anuncio_b30 id=3]
En honor a la verdad la línea 29 es completamente para fines de estudio, de claridad, en pos de transmitir mejor lo que intento explicar. Sí, digo esto último ya que aunque no está mal, no es necesaria, pues el compilador de Swift infiere a través de la implementación de la estructura IntStack que el tipo al que sustituirá ItemType será Int.
Si te estás preguntando si esto que hemos hecho se pudiera aplicar a un código genérico, pues sí, veamos este ejemplo de la versión genérica de nuestra Pila:
struct Stack<T> {
var items = [T]()
mutating func push(newItem: T) {
items.append(newItem)
} // push
mutating func pop() ->T? {
guard !items.isEmpty else {
return nil
} // guard
return items.removeLast()
} // pop
mutating func append(item: T) {
self.push(item)
} // append
var count: Int {
return items.count
} // count
subscript(i: Int) -> T {
return items[i]
} // subscript
} // Stack
var stringStack = Stack<String>()
stringStack.append("Hola")
stringStack.append("Mundo")
print()
print("Número de elementos en la Pila: \(stringStack.count)")
print()
print(stringStack.pop())
print(stringStack.pop())
print()
print("Número de elementos en la Pila: \(stringStack.count)")
print() …la salida en pantalla sería:
Número de elementos en la Pila: 2
Optional("Mundo")
Optional("Hola")
Número de elementos en la Pila: 0 Como era de esperar funciona perfectamente, y trabajamos con T como nuestro comodín y como ven no ha habido necesidad de hacer referencia a ItemType ya que como he comentado anteriormente el tipo de dato es inferido por el compilador de Swift.
Restringiendo la Extensión de Protocolos
Los protocolos también pueden ser extendidos y en estas ocasiones quizás nos resulte útil filtrar ciertos comportamientos, es decir que la extensión de código se encuentre disponible solamente bajo ciertos eventos como pudiera ser que el tipo de dato comodín sea igual a String. Veamos un ejemplo de esto:
protocol Animal {
associatedtype Food
func eat(food: Food)
} // Animal
struct Cow: Animal {
typealias Food = String
func eat(food: Food) {
print("Soy una vaca y mi comida puede ser cualquier String!!! Pero actualmente estoy comiendo: \(food)")
} // eat
} // Cow
let cow = Cow()
cow.eat("Hierba")
print()
struct Dog: Animal {
typealias Food = [String]
func eat(food: Food) {
food.forEach {
print("Soy un perro y me estoy comiendo un Array de comida, la siguiente: \($0)")
} // Array.forEach
} // eat
} // Dog
let dog = Dog()
dog.eat(["Pastel", "Batata", "Hueso"]) …la salida en pantalla:
Soy una vaca y mi comida puede ser cualquier String!!! Pero actualmente estoy comiendo: Hierba Soy un perro y me estoy comiendo un Array de comida, la siguiente: Pastel Soy un perro y me estoy comiendo un Array de comida, la siguiente: Batata Soy un perro y me estoy comiendo un Array de comida, la siguiente: Hueso
Hasta aquí todo bien, nada nuevo. Imaginemos ahora que necesita una implementación por defecto del método eat para todos aquellos que lo adopten, para lograr esto hacemos uso de las extensiones, de la siguiente forma:
protocol Animal {
associatedtype Food
func eat(food: Food)
} // Animal
extension Animal where Food: StringLiteralConvertible {
func eat(food: Food) {
print("Soy una vaca y mi comida puede ser cualquier String!!! Pero actualmente estoy comiendo: \(food)")
} // eat
} // Animal extension
struct Cow: Animal {
typealias Food = String
} // Cow
let cow = Cow()
cow.eat("Hierba")
print()
struct Cat: Animal {
typealias Food = String
} // Cow
let cat = Cat()
cat.eat("Pescado") …la salida en pantalla sería la siguiente:
Soy una vaca y mi comida puede ser cualquier String!!! Pero actualmente estoy comiendo: Hierba Soy una vaca y mi comida puede ser cualquier String!!! Pero actualmente estoy comiendo: Pescado
De la línea 9 a la 17 extendemos el protocolo Animal con una implementación por defecto del método eat y donde especificamos (haciendo uso de la sentencia where), que esta extensión solamente estará disponible para aquellos usuarios donde el comodín Food sea igual al tipo de dato String.
Si seguimos analizando el código vemos que hemos omitido el método eat en la estructura Cow dejando solamente la declaración explicita de que Food es de tipo String. Proseguimos creando una instancia de Cow y hacemos uso del método eat sin problemas. Lo siguiente es otra declaración, en este caso de una estructura de nombre Cat pero a la que no le definimos el método eat y que al igual que la anterior, Food también es de tipo String.
Los tipos asociados son de gran utilidad cuando trabajamos con protocolos y queremos definir funciones o método genéricos. Pero también tenemos que ser cuidadosos, como podemos ver en la salida en pantalla del último código, el descuido que hemos cometido nos han creado un gato con problemas de identidad, el gato se cree una vaca y aun así come pescado :-).
Falta aún mucho por aprender en nuestro camino a convertirnos en iOS Developer. Suscríbete a nuestra lista de correo mediante el formulario en el panel derecho y síguenos en nuestras redes sociales. Mantente así al tanto de todas nuestras publicaciones futuras.
Espero que todo cuanto se ha dicho aquí, de una forma u otra le haya servido de aprendizaje, de referencia, que haya valido su preciado tiempo.
Este artículo, al igual que el resto, será revisado con cierta frecuencia en pos de mantener un contenido de calidad y actualizado.
Cualquier sugerencia, ya sea errores a corregir, información o ejemplos a añadir será, más que bienvenida, necesaria!
