Open, Public, Internal, File-private, Private

Aneddoto (potete saltare)

Swift è il mio primo linguaggio di programmazione, oltre ad essere il mio primo amore da nerd. Un po’ di mesi fa ho preso una D al test di Fisica. Da studente di Ingegneria chimica, ho prestato più attenzione a Swift che alla Termodinamica. Per non dire che non ricordo assolutamente nulla di quanto studiato.

Abbandonare gli studi è stata la decisione migliore della mia vita. A proposito, in Inglese avevo una A-, giusto per far sapere ai miei lettori che sono perfettamente in grado di scrivere in maniera formale. Nonostante ciò, preferisco rendere i miei articoli leggeri e magari far sorridere i lettori per qualche secondo. Inoltre, voglio mettere fine agli stereotipi secondo cui i developer e gli hacker lavorano dietro una scrivania e non sono in grado di comunicare in modo efficace.

In ogni caso, tre mesi più tardi disponevo di maggiore familiarità con Swift, e così decisi di dare uno sguardo ai progetti open source su Github: credevo di capirne abbastanza… ma si trattava solo di una visione distorta, perché in realtà sapevo poco.

Back to Reality

Rimasi spaesato quando notai queste strane keyword: open, public, internal, file-private, private. Si trovavano davanti a class, struct, func, var e… ovunque.

Lo studio di Swift non risulta troppo complicato. A proposito, se le mie parole vi confondono, non preoccupatevi: una volta giunti alla fine dell’articolo tutto avrà un senso. Almeno spero.

Iniziamo

Prima di parlare delle keyword menzionate prima, dovete capire una sola cosa: il modulo. Immaginate un modulo come un bundle di codice. Il progetto/framework/bundle Xcode è considerato un singolo modulo.

Anche UIKit è considerato un modulo. Ad esempio, quando si prova ad interagire con UIComponents come UITableView, UIButton, UIViewController e via di seguito, dovrete importare la libreria/modulo UIKit.

Ora state usando codice scritto in UIKit. Il progetto Xcode non contiene nativamente tutti quei file Swift o Objective-C, quindi devono essere importati. Non so nella vostra cartella Xcode dove si trovi UIKit, ma senza dubbio esiste.

Gli ingegneri Apple non dicono ai developer iOS come è strutturato internamente UIKit. Solo Swift è open source.

Dunque, quando volete importare il codice di qualcuno – ad esempio una qualunque library da Github – è possibile trascinare la libreria/cartella sulla parte sinistra del pannello Xcode, dove si trovano tutti i file:

Se ancora non vi è chiaro il concetto di modulo, Apple dice:

Un modulo è una singola unità di distribuzione del codice — un framework o applicazione sviluppata e inviata come unità singola e che può essere importata da un altro modulo con la keyword import di Swift.

Quindi?

Bene, avete fatto strada. Alcune volte, però, non potrete agire attivamente su quanto importato. Ad esempio, gli ingegneri UIKit presso Apple non vogliono che i developer iOS tocchino o modifichino alcune delle sue classi, metodi, variabili e funzioni. Ciò vuol dire che possiamo implementare le strutture con, ad esempio, UICollectionView attraverso un override o una subclass, ma non possiamo toccare il design strutturale che ci consente di usare UICollectionView senza scrivere codice manualmente.

Immaginate di essere padri o madri e di aver dato a vostro figlio di 5 anni un computer da usare. Vostro figlio, invece di usarlo semplicemente, vuole aprirlo per customizzarlo all’interno. Ecco un’analogia per capire il rapporto tra gli ingegneri Apple e i developer di app iOS su questo particolare argomento.

Quindi gli ingegneri hanno realizzato una sorta di barriera / entry level per impedire l’accesso al loro codice e alla loro libreria. Ed ecco perché si chiama Access Control.

In Swift 3 ce ne sono 5 tipi. Sembrano molti, ma cercherò di spiegarvi in modo semplice e conciso ognuna delle tipologie.

Open (Least Control)

Diamo un’occhiata al codice che gli ingegneri hanno dato al framework UIKit. Ad esempio, creiamo una subclass in UICollectionView:

Fantastico, ma come si può creare una subclass? Per conoscere la risposta, Option e click sulla classe UICollectionView.

open suggerisce che abbiamo accesso dal modulo UIKit. Si può impostare una subclass come mostrato da myCollectionView, anche se UIKit è un modulo differente dal proprio bundle App.

Public

Il tipo public è indentico all’open eccetto per una cosa: si ha accesso ad un altro modulo. Per esempio, dal proprio bundle / progetto Xcode si ha accesso alla classe UICollectionView. Ora diamo un’occhiata a UICollectionViewDelegate:

Non preoccupatevi se non avete familiarità con il protocollo o il delegate. Il punto è che non possiamo creare subclass UICollectionViewDelegate.

L’override può essere effettuato solo dalle sottoclassi all’interno del modulo dove vengono definite. Dal momento che UIKit è nascosto – e noi developer non ne abbiamo idea.

Internal (Default)

La ragione per cui non vediamo spesso questa tipologia è perché… è la tipologia di default. In questo caso possono essere usati solo all’interno dei source files dal loro modulo – non all’esterno di quel modulo.

Gli sviluppatori iOS non hanno accesso alle funzioni internal, anche importando UIKit.

Anche se importiamo UIKit, diversamente da UIViewController e molte altre funzioni public/open e classi, non vi è modo di usare useMelfYouCan.

File-private

fileprivate serve quando vogliamo che funzioni/classi/variabili vengano usate solo all’interno di un unico file Swift, ad esempio:

Non c’è modo di usare quella funzione/classe in un file diverso, anche se siamo all’interno dello stesso modulo.

Private (Most Control)

Infine quello più semplice. Gli sviluppatori possono avere accesso al di fuori di classi, funzioni e metodi.

Ecco tutto

***

Bob Lee è l’autore di questo articolo.

Articolo originale:The Complete Understanding of Access Control in Swift 3

 

NO COMMENTS

LEAVE A REPLY