Protocol Oriented Programming

A medida que programamos, podemos tener la necesidad de tener varios UIViewController con la misma lógica, i.e cada vez que se pulse un botón del UINavigationController aparezca el menú de la aplicación, o, en cada UIViewController aparezca un modal para indicar al usuario que se registre en nuestra aplicación.

Lo lógico en estos casos sería crear una nueva clase CommonPatternViewController con todo este comportamiento y que herede de UIViewController, por lo tanto CommonPatternViewController sería una subclase de UIViewController y tendría todas sus propiedades y métodos.

Obviamente podemos tirar del polimorfismo y hacer un override de las funciones de la superclase para crear comportamientos específicos para cada subclase o crear funciones nuevas que en la superclase no existen.

Pero durante el desarrollo puede que necesitemos utilizar el mismo comportamiento en un UITableViewController o UICollectionViewController y por lo tanto no podemos utilizar nuestra nueva clase CommonPatternViewController (ya que hereda de UIViewController).

Lo que nos interesa es poder asignar comportamientos a tipos, es decir, definir métodos en la interfaz que indiquen qué pueden hacer.

La clave de esto, es que mientras la herencia no permite heredar de múltiples clases (para la mayoría de OOP, causa: the diamond problem), con los protocolos podemos asignar diferentes “comportamientos” a un objeto.

Los protocolos, nos definen interfaces comunes que pueden conformar otros tipos. Otra peculiaridad es que con Swift 2.0 podemos crear extensiones de protocolos (aunque no los hayamos creado nosotros). Gracias a las extensiones podemos crear comportamientos por defecto (más adelante veremos que se puede hacer un “override”).


Vamos al código

Creamos un protocolo llamado Developer, vamos a suponer que cada desarrollador tiene un lenguaje preferido y para ello vamos a crear un método en el protocolo, y una extensión para asignar por defecto un lenguaje favorito.

A continuación vamos a crear dos clases que cada una implementa el protocolo Developer.

El resultado por consola es el comentado anteriormente, la clase Moral, muestra por consola “iOS”, mientras que UncleBob muestra “Java”. Esto es debido a que Moral coge el comportamiento por defecto de programmingLanguage() mientras que UncleBob modifica su comportamiento.

Lo que mola de los protocolos, es que no dependen del objeto, podemos aplicar a cualquier clase o estructura

Vamos a crear otro protocolo para que Moral y UncleBob puedan utilizar su interfaz.

El protocolo Freak, al no tener una extensión detallando el comportamiento por defecto, nos obliga a que si en la clase Moral no añadimos la función isFreak() nos aparece el error de la siguiente captura.


Conclusión

Para solucionar el caso que comentábamos al principio:

cada vez que se pulse un botón del UINavigationController aparezca el menú de la aplicación, o, en cada UIViewController aparezca un modal para indicar al usuario que se registre en nuestra aplicación

Podemos crear un protocolo con los métodos necesarios del menú de nuestra aplicación, y así la clase o estructura que aplique este protocolo tendrá el comportamiento definido.

Referencias

Show your support

Clapping shows how much you appreciated Alberto Moral’s story.