La nature des informations que l’on peut stocker dans une variable dépend de son type : des chaines pour une String, des nombres complexes dans un flottant, une information binaire (oui/non, true/false) dans une BOOL, etc …
L’opérateur enum (comme énumération) permet de créer un type de variable spécialisée ne pouvant contenir qu’un petit nombre d’informations.
C’est très pratique pour mémoriser l’état d’un système ou d’un objet. Exemple pour un objet voiture pouvant prendre 3 états différents :
enum EtatVoiture {
case auGarage
case enPanne
case surLaRoute
}
Il suffit de créer une variable de type EtatVoiture pour stocker l’information.
var etatVehiculePapa:EtatVoiture = .auGarage
Cela permet d’écrire un code très lisible, comme :
if etatVehiculePapa == .enPanne {
}
On peut aussi utiliser des entiers pour mémoriser l’état d’un système, mais c’est loin d’être aussi lisible.
// La signification de ce test ne saute pas aux yeux
// à la différence du précédent
if etatVehiculePapa == 1 {
}
De plus, les types de variables personnalisés sont sécurisés, toujours la même obsession des créateurs de Swift. On ne peut y écrire dedans que les valeurs prévues à l’origine, à la différence des entiers qui peuvent contenir n’importe quoi.
Pour en revenir au Sac à questions, j’ai créé un type de variable pour décrire son état.
enum EtatSacQuestions {
case vide
case plein
}
Je trouve ça plus parlant qu’un true/false classique.
func etatDuSac() -> EtatSacQuestions {
if tableau.count == 0 {
return .vide
}
return .plein
}
La fonction etatDuSac() retourne la valeur .vide si le Sac est vide, et .plein s’il reste encore des questions.
En fait, l’écriture .vide est une abréviation de EtatDuSac.vide. Les premières versions de Swift nécessitaient d’écrire TypeDeVariable.valeur en entier. Heureusement, on peut maintenant se contenter de .valeur, Xcode analysant le contexte pour déterminer le type à prendre en compte.
.
