Simple : type Enumeration ?
Bonsoir à tous,
une question toute bête :
1/ j'ai décrit une énumération enum
2/ Je veux créer une variable simple qui contiendra plus tard mon énumération (ou une autre) et je ne sais pas quel type lui donner.
Merci
enum Actions : String, Codable {
case Lire = "Lire"
case Chanter = "Chanter"
case Jouer = "Jouer"
case Taper = "Taper"
static let allValues = [Lire, Chanter, Jouer, Taper]
}
enum Temps : String, Codable {
case TLJ = "TLJ"
case SuiteALaPrecedente = "Suite"
case j1 = "1j"
case j2 = "2j"
case j3 = "3j"
case j4 = "4j"
static let allValues = [TLJ, SuiteALaPrecedente, j1, j2, j3, j4]
}
Plus tard...
let itemsActions = Actions.allValues
let itemsTemps = Temps.allValues
(...)
var items : ??????!!!!!!
if (collectionView.restorationIdentifier == "Actions") {
items = itemsActions
} else if (collectionView.restorationIdentifier == "Temps"){
items = itemsTemps
}
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Bonsoir Machaon !
C'est très simple : une enum, c'est un type !
D'ailleurs, lorsque tu voudras déclarer ou modifier une variable dont le type est une enum, tu auras l'auto complétion dès que tu auras mis le point.
Merci pour ta réponse Luc-A.
Je comprends donc que je ne peux pas affecter à items soit l'un soit l'autre... c'est dommage, je vais devoir dupliquer plus de code dans mon if.
Je t'en prie !
Peux-tu être plus précis ?
Si tu dois utiliser une condition, tu devrais utiliser Switch plutôt que if !
Pour la case .none, c'est une nouveauté de Swift 4.
Je veux bien t'aider, mais il faut en dire plus !
Dommage c'est vite dis .. Swift est un langage très strict sur les types de données. On ne peut pas mélanger des données de nature différente, ce qui est une bonne chose pour la sécurité des applications.
Effectivement on ne peut pas faire certaines bidouilles comme d'autres langages plus anciens, ce qui élimine un risque de bugs par effet de bord. Ce n'est pas grave d'avoir quelques lignes de code en plus. Ce qui compte c'est la lisibilité du code, la facilité de maintenance (les modifications ultérieures), la réutilisation des objets et la sécurité.
enum Item {
case action (Action)
case temps (Temps)
}
var items = [Item.action(.Chanter), Item.temps(.j1)]
P.S.: Quand une enum hérite de String, il n'est pas nécessaire de définir les chaà®nes:
enum Action : String {
P.S. 2: Les canons de codage en Swift recommandent que les cases commencent par une minuscule.case Lire
case Chanter
case Jouer
case Taper
}
Dans le même type d'idée, il serait possible de créer une enum ?
Par exemple :
et l'utiliser de cette façon :
Il suffit d'utiliser une struct.
J'ai écrit n'importe quoi, je reprends.
On pourrait faire quelque chose similaire avec l'utilisation d'un protocol ?
Mais ensuite, on n'est pas très avancé. On se retrouve avec un array d'Items qui ne savent rien faire, puisque le protocole Item est vide.
Okay, mais si on fait ça ? Ca ne fonctionne pas ? (j'ai pas de playground sous la main)
Oui exact ! La proposition ci-dessous devrait fonctionner.
Et pourquoi pas :
C'est plus simple et fonctionne très bien. Je viens de tester.
Pas besoin de créer un protocol, ni de définir une propriété description.
Oui oui oui. J'aime bien utiliser les protocol pour "normaliser" le code. Je suis assez fana de la programmation par contrat. Mais effectivement tu peux t'en passer. Et ta solution est plutôt intéressante.
Ce code avec tous les switch est bien moche.
Bah heu.... ça dépend de ce qu'on a envie de faire...
Dans ton cas tu es obligé de déclarer instrusction1 et instruction2 dans tes deux énums même si elle servent à rien. Je ne dis pas que ça ne fonctionne pas (quoi que...) mais je ne crois pas que ce soit forcément une meilleur idée que la proposition de Draken.
D'ailleur, si pour l'enum Actions.lire tu dois appeler uniquement l'instruction 2 et pour Temps.j1 uniquement l'instruction 1, ça fonctionne ? Bah non.
Les switch sont toujours moches :-*
Normalement, en ajoutant plusieurs objets dans un liste, on pourrait vouloir faire la même chose avec tous, n'importe quoi le type.
À la place d'un protocol vide, on peux l'utiliser pour tenir la/les méthode(s) commune(s). Mon exemple n'était qu'un exemple ; on n'est pas obligé d'avoir deux méthodes.
Et on peut avoir plusieurs protocols pour grouper les comportements.
Non mais ma remarque était pour pinailler !
Tu as quoi contre les switchs ? Pour les énums je les trouve plutôt pratiques.
::)
Dans un enum, peut-être mais ailleurs, je préfère d'utiliser l'équivalent du "Visitor Pattern" i.e. en Swift, les méthodes d'un protocol implémentée dans une extension.
Fais nous une petite présentation de ce design pattern !
L'idée derrière le "Visitor Pattern" est que l'on puisse ajouter des fonctionnalités à une hiérarchie de types sans devant modifier les types originaux.
Typiquement, avec la plupart des langages POO, à part de Swift, on trouverait :
Mais, avec Swift et ses Protocols et ses Extensions, on n'est plus obligé de créer les hiérarchies de classes ; on peut ajouter les fonctionnalités plus facilement :
Dans le premier cas, nous avons dû toucher les classes pour déclarer qu'ils sont Visitable et, dans chaque méthode "accept", nous également dû écrire du code pour déterminer le type du Visitor et quelle méthode à appeler. Mais, le code qui implémente le comportement est toujours dans le Visitor.
Avec Swift, il n'est plus nécessaire de définir les protools Visitor et Visitable, on peut tout simplement ajouter le comportement dans une extension de chaque type dont nous avons besoin.
Les extensions c'est le Bien !