Home » Swift » Swift 3, nuevo control de acceso
Swift 3 Control de Acceso

Swift 3, nuevo control de acceso

Swift 3 ya está entre nosotros, y si habéis trabajo con él os daréis cuenta que no son pocas las novedades. Sin duda, los primeros días el asistente de código será nuestro mejor amigo para indicarnos todos los cambios que debemos hacer en el código y cómo ha cambiado la sintaxis de muchas expresiones.

Pero una de las cosas más importantes que ha cambiado en Swift es el control de acceso, es decir, la facultad que tiene una entidad para restringir (o no) su acceso desde otros módulos, ficheros, entidades, etc… En Swift 2 teníamos tres tipos de control:

  • Público ( public): Cuando tanto fuera como dentro del proyecto se tenía acceso a los componentes así declarados (caso de frameworks que exponen propiedades o métodos en cualquier proyecto donde se use).
  • Interno ( internal) : El acceso por defecto cuando no lo especificamos, que permite acceder dentro de un mismo proyecto a todos los componentes, independientemente del fichero donde esté. Los elementos o módulos definidos así no son accesibles fuera del módulo o proyecto donde han sido definidos.
  • Privado ( private): El acceso privado permite a cualquier clase o método de un mismo fichero acceder a los elementos declarados con este tipo de acceso, pero no a aquellos elementos fuera del fichero donde se ha declarado.

Así es como funcionaba hasta ahora, pero ahora, con Swift 3 se ha modificado y ampliado, permitiendo más casos de uso, más concretos.

  • Abierto ( open): Es el acceso con menos restricciones. Permite que cualquier entidad pueda usar cualquier fichero de código del módulo así definido, así como en otros módulos que importen los módulos así definidos. Es el equivalente a public, aunque existe una diferencia importante: el acceso open permite sobrescribir cualquier módulo así definido desde cualquier otro lugar, fichero o módulo que importe, sin restricción alguna.
  • Público ( public): Es igual que el abierto, pero con la diferencia ya expuesta. Con este tipo de acceso podremos acceder a los módulos así definidos desde cualquier ámbito importado, pero no podremos sobrescribir (sobrecargar) ninguno de estos módulos, solo acceder a ellos y utilizarlos tal cual están definidos.
  • Interno ( internal): No varía con respecto a la definición en Swift 2. Sigue siendo el tipo de acceso por defecto y permite, dentro de un mismo proyecto o módulo, que todos los elementos sean accesibles desde cualquier fichero del mismo, pero no así fuera de este. Por lo tanto, si creamos un framework y lo importamos desde otro módulo, este otro no podrá acceder ni ver nada de lo que sea con tipo de acceso internal.
  • Fichero Privado ( fileprivate): Es el equivalente al anterior private. Restringe el uso de una entidad al fichero donde fue definido. De esta forma, fuera del fichero (aun dentro del mismo proyecto) no se mostrarán las entidades así definidas.
  • Acceso Privado ( privateaccess): Es el modo más restrictivo. Restringe el acceso a las entidades únicamente en el ámbito de la declaración. Si en un mismo fichero creamos un clase y dentro ponemos entidades de este tipo, ni siquiera en el mismo fichero (fuera de la clase) se podrá acceder o ver estas entidades.

La forma de usarlos es anteceder esta declaración antes del comando que lo define, como func, let o class, por ejemplo.

Como podemos ver, se ha mejorado bastante incorporando dos tipos nuevos: el open y el privateaccess, que permiten casos más específicos de acceso a elementos y nos permiten definir mejor cómo funciona.

La mejor forma de probarlos es trabajar con ellos, así que esperamos que hagáis buen uso de estos nuevos tipos de acceso directo y no vemos en el próximo artículo. Un saludo y Good Apple Coding.

Acerca de 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.

Otras recomendaciones

Swift 3.1 Hoja de Ruta

Swift 3.1, hoja de ruta hasta primavera de 2017

Swift 3.1 marca su hoja de ruta de aquí a primavera de 2017 con dos grandes retos: la compatibilidad de código con la versión 3.0 y potenciar el gestor de paquetes y la integración con servidor para conseguir aun más rendimiento en soluciones como Kitura, Vapor o Perfect (entre otros). Descubre los detalles en nuestra noticia y qué nos depara esta nueva versión menor del lenguaje.